Application Architecture

(Redirected from Applications Architecture)

Definition of Application Architecture[1]

Application Architecture is the process of defining the framework of an organization’s application solutions against business requirements. It involves the definition of the application landscape, aiming to optimize this landscape against the ideal blueprint. The Open Group’s architectural framework, TOGAF, defines the objective of application architecture as “defining the major kinds of application systems necessary to process the data and support the business”.

Application Architecture Layers[2]

Layers are the logical groupings of the software components that make up the application or service. They help to differentiate between the different kinds of tasks performed by the components, making it easier to create a design that supports the reusability of components. Each logical layer contains a number of discrete component types grouped into sublayers, with each sublayer performing a specific type of task. By identifying the generic types of components that exist in most solutions, you can construct a meaningful map of an application or service, and then use this map as a blueprint for your design. Splitting an application into separate layers that have distinct roles and functionalities helps you to maximize the maintainability of the code, optimize the way that the application works when deployed in different ways, and provide a clear delineation between locations where certain technology or design decisions must be made. At the highest and most abstract level, the logical architecture view of any system can be considered to be a set of cooperating services grouped into the following layers, as shown in Figure 1. below.

Layers of Application Architecture
Figure 1. source: Guidance Share

Sections and Components of Application Architecture

The sections of the application design shown in Figure 1. above can be thought of as three basic sets of services:

  • Presentation services. These are the user-oriented services responsible for managing user interaction with the system and generally consist of components located within the presentation layer. They provide a common bridge into the core business logic encapsulated in the business services.
  • Business services. These services implement the core functionality of the system and encapsulate the relevant business logic. They generally consist of components located within the business layer, which may expose service interfaces that other callers can use.
  • Data services. These services provide access to data that is hosted within the boundaries of the system, and data exposed by other back-end systems; perhaps accessed through services. The data layer exposes data to the business layer through generic interfaces designed to be convenient for use by business services.

Each layer of an application will contain a series of components that implement the functionality for that layer (see Figure 2.). These components should be cohesive and loosely coupled to simplify reuse and maintenance.

  • Presentation Layer Components: Presentation layer components implement the functionality required to allow users to interact with the application. The following types of components are commonly found in the presentation layer:
    • User interface (UI) components. These components provide a mechanism for users to interact with the application, format data and render it for display, and acquire and validate data entered by users.
    • UI process components. To help synchronize and orchestrate user interactions, it can be useful to drive the process using separate **UI process components. This prevents the process flow and state management logic from being hard-coded into the UI elements themselves and allows you to reuse the same basic user interaction patterns in other user interfaces.
  • Business Layer Components: Business layer components implement the core functionality of the system, and encapsulate the relevant business logic. The following types of components are commonly found in the business layer:
    • Application façade. This is an optional feature that you can use to combine multiple business operations into single messaged-based operations. This feature is useful when you locate the presentation layer components on a separate physical tier from the business layer components, allowing you to optimize the use of the communication method that connects them.
    • Business components. These components implement the business logic of the application. Regardless of whether a business process consists of a single step or an orchestrated workflow, your application is likely to require components that implement business rules and perform business tasks.
    • Business workflows. After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order and may interact with each other through an orchestration. Business workflow components define and coordinate long-running, multi-step business processes, and can be implemented using business process management tools.
    • Business entity components. Business entities are used to pass data between components. The data represents real-world business entities, such as products or orders. The business entities that the application uses internally are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities that your application will handle.
  • Data Layer Components: Data layer components provide access to data that is hosted within the boundaries of the system, and data exposed by other back-end systems. The following types of components are commonly found in the data layer:
    • Data access components. These components abstract the logic required to access the underlying data stores. Doing so centralizes data access functionality and makes the application easier to configure and maintain.
    • Data helper and utility components. Most data access tasks require common logic that can be extracted and implemented in separate reusable helper components. This helps to reduce the complexity of the data access components and centralizes the logic, which simplifies maintenance. Other tasks that are common across data layer components, and not specific to any set of components, may be implemented as separate utility components. Both helper and utility components can often be reused in other applications.
    • Service agents. When a business component must use functionality provided by an external service, you might need to implement code to manage the semantics of communicating with that particular service. Service agents isolate the idiosyncrasies of calling diverse services from your application, and can provide additional services such as basic mapping between the format of the data exposed by the service and the format your application requires.
  • Cross-Cutting Components: Many tasks carried out by the code of an application are required in more than one layer. Cross-cutting components implement specific types of functionality that can be accessed from components in any layer. The following are common types of cross-cutting components:
    • Components for implementing security. These may include components that perform authentication, authorization, and validation.
    • Components for implementing operational management tasks. These may include components that implement exception-handling policies, logging, performance counters, configuration, and tracing.
    • Components for implementing communication. These may include components that communicate with other services and applications.

Service Layer of Application Architecture

When an application will act as the provider of services to other applications, as well as implement features to support clients directly, a common approach is to use a services layer that exposes the functionality of the application, as shown in Figure 2.

Application Architecture Layers and Components
Figure 2. source: Guidance Share

  • Services Layer Components: Services layer components provide other clients and applications with a way to access business logic in the application, and make use of the functionality of the application by passing messages to and from it over a communication channel. The following types of components are commonly found in the services layer:
  • Service interfaces. Services expose a service interface to which all inbound messages are sent. The definition of the set of messages that must be exchanged with a service in order for the service to perform a specific business task constitutes a contract. You can think of a service interface as a façade that exposes the business logic implemented in the service to potential consumers.
  • Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. For example, you might have a Command message, a Document message, or another type of message. These message types are the “message contracts” for communication between service consumers and providers.

Application Architecture - Physical Tiers and Deployment[3]

Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. By considering the possible deployment scenarios for your application as part of the design process, you prevent a situation where the application cannot be deployed successfully, or fails to perform to its design requirements because of technical infrastructure limitations. Choosing a deployment strategy requires design tradeoffs. For example, there might be protocol or port restrictions, or specific deployment topologies not supported in your target environment. When creating your deployment strategy, first determine if you will use a distributed or a non-distributed deployment model. If you are building a simple intranet application for your organization, which will be accessed by a finite set of users, consider nondistributed deployment. If you are building a more complex application, which you must optimize for scalability and maintainability, consider a distributed deployment.

  • Nondistributed Deployment: In a nondistributed deployment, all of the functionality and layers reside on a single server except for data storage functionality, as shown in the example in Figure 3.

Application Architecture Non-Distributed Deployment
Figure 3. source: Microsoft

This approach has the advantage of simplicity and minimizes the number of physical servers required. It also minimizes the performance impact inherent when communication between layers must cross physical boundaries between servers or server clusters. Keep in mind that by using a single server, even though you minimize communication performance overhead, you can hamper performance in other ways. Because all of your layers share resources, one layer can negatively affect all of the other layers when it is under heavy utilization. In addition, the servers must be generically configured and designed around the strictest of operational requirements and must support the peak usage of the largest consumers of system resources. The use of a single tier reduces your overall scalability and maintainability because all the layers share the same physical hardware.

  • Distributed Deployment: In a distributed deployment, the layers of the application reside on separate physical tiers. Tiered distribution organizes the system infrastructure into a set of physical tiers to provide specific server environments optimized for specific operational requirements and system resource usage. It allows you to separate the layers of an application on different physical tiers, as shown in the example in Figure 4.

Application Architecture Distributed Deployment
Figure 4. source: Microsoft

A distributed approach allows you to configure the application servers that host the various layers in order to best meet the requirements of each layer. However, because the primary driver for optimizing component deployment is to match a component's resource consumption profile to an appropriate server, this implies that a direct mapping of layers to tiers is often not the ideal distribution strategy. Multiple tiers enable multiple environments. You can optimize each environment for a specific set of operational requirements and system resource usage. You can then deploy components onto the tier that most closely matches their resource needs to maximize operational performance and behavior. The more tiers you use, the more deployment options you have for each component. Distributed deployment provides a more flexible environment where you can more easily scale out or scale up each physical tier as performance limitations arise, and when processing demands increase. However, keep in mind that adding more tiers adds complexity, deployment effort, and cost. Another reason for adding tiers is to apply specific security policies. Distributed deployment allows you to apply more stringent security to the application servers; for example, by adding a firewall between the Web server and the application servers, and by using different authentication and authorization options.

Distributed Deployment Patterns

Several common patterns represent application deployment structures found in most solutions. When it comes to determining the best deployment solution for your application, it helps to first identify the common patterns. Once you have a good understanding of the different patterns, you then consider scenarios, requirements, and security constraints to choose the most appropriate pattern.

  • Client-Server Deployment: This pattern represents a basic structure with two main components: a client and a server. In this scenario, the client and server will usually be located on two separate tiers. Figure 3 represents a common Web application scenario where the client interacts with a Web server. Consider the client/server pattern if you are developing a client that will access an application server or a stand-alone client that will access a separate database server.

Application Architecture Client Server Pattern
Figure 5. source: Microsoft

  • n-Tier Deployment: The n-tier pattern represents a general distribution pattern where components of the application are separated across one or more servers. Commonly, you will choose a 2-tier, 3-tier, or 4-tier pattern as described in the following sections. While you will often locate all of the components of a layer on the same tier, this is not always the case. Layers do not have to be confined to a single tier—you can partition workloads across multiple servers if required. For example, you may decide to have side-by-side tiers that contain different aspects of your business logic.

    • 2-Tier Deployment: Effectively this is the same physical layout as the client/server pattern. It differs mainly in the ways that the components on the tiers communicate. In some cases, as shown in Figure 6, all of the application code is located on the client, and the database is located on a separate server. The client makes use of stored procedures or minimal data access functionality on the database server. Consider the 2-tier pattern if you are developing a client that will access an application server or a stand-alone client that will access a separate database server.

Application Architecture 2 tier
Figure 6. source: Microsoft

    • 3-Tier Deployment: In a 3-tier design, the client interacts with application software deployed on a separate server, and the application server interacts with a database that is located on another server, as shown in Figure 7. This is a very common pattern for most Web applications and Web services, and sufficient for most general scenarios. You might implement a firewall between the client and the Web/App tier, and another firewall between the Web/App tier and the database tier. Consider the 3-tier pattern if you are developing an Intranet-based application where all servers are located within the private network or an Internet-based application and security requirements do not prevent you from implementing business logic on the public-facing Web or application server.

Application Architecture 3 tier
Figure 7. source: Microsoft

    • 4-Tier Deployment: In this scenario, shown in Figure 8, the Web server is physically separated from the application server. This is often done for security reasons, where the Web server is deployed into a perimeter network and accesses the application server located on a different subnet. In this scenario, you might implement a firewall between the client and the Web tier, and another firewall between the Web tier and the application or business logic tier. Consider the 4-tier pattern if security requirements dictate that business logic cannot be deployed to the perimeter network, or you have application code that makes heavy use of resources on the server and you want to offload that functionality to another server.

Application Architecture 4 tier
Figure 8. source: Microsoft

Application Architecture Archetypes[4]

Application architecture whether it is for mobile, server, or desktop applications can be broken into 3 major archetypes - standalone, connected, and occasionally connected.

  • Stand alone Applications: Standalone applications are exactly an application that can run on the device without any other requirements or resources. The classic example would be a "Hello World" application. In the early days of network technology to enable this standalone application access to network resources, OS developers made network resources look local. So early versions of Microsoft Word could save to the network because the shared network location looked like a local drive. So while Word at that point is technically no longer standalone, it is not exactly network or connected aware. With the .Net and Compact Framework, you can build standalone applications. These applications can be as simple or complex as you like.
    • The benefit
      • Can run anywhere and anytime by its user as long as the device can operate.
      • The application can be written with little regard to its environment i.e. it can assume that it is the only thing running, and does not need to manage fragile network connections.
      • Rich user interface.
      • Over time the application can approach near zero defect since the application is self-contained. In addition, the most probable source of error is a combination of user input or a sequence of interactions that developers had not been foreseen.
    • The negatives
      • Self contained the user has limited interaction with network resources. A good example is Car Navigation systems. To update the map or show newer locations require an update of its map which can be complex for example my wife's navigation is about 6 years out of date and requires the dealer to replace the DVD since it is not easily accessible. This typically means that data is stale to some degree.
      • To update the application requires user intervention or some other process.
      • A rich user interface can approach a near-infinite combination of interactions and input which makes it impossible to test every combination.
  • Connected Applications: The first connected application basically put the application layers on different physical computers. So for example moving the data layer to a separate server or pushing out the presentation to the user's computer. This first version was called client/server since the application was broken into two parts - client and server. A classic example is the Web - it is composed of a browser which is the client and a web server. Depending on what ran the client you had a so-called fat or thin client.

A thin client is typically a web page delivered to the browser. Then any application logic is done back at the web server or more sophisticated clients use a web service or REST. The latter is known by the acronym AJAX. With the .Net Framework, ASP.Net, and the Mobile Internet Control Toolkit you can build thin client applications. These applications can be as simple or complex as you like.

    • The benefit
      • Can support many different devices not just Windows Mobile
      • No deployment to the device
      • Scale is achieved by increasing central systems
      • Web-based applications tend to be robust since user interactions are limited (note: not AJAX)
      • Overtime the application can approach near zero defect since the application is a web page with known user interactions and sequences
    • The negatives
      • Always requires a connection and so no airplane mode
      • Scaling requires greater back-end infrastructure and server management becomes very important
      • User interface is typically not as rich since HTML has limited controls this includes AJAX
      • Browser functionality is not consistent across all devices

A fat client on the other hand has a more complex client that might include application logic as well as data. The only portion that might be on the server would be the database. In the mobile world, fat clients consist of Compact Framework applications communicating to a web service or REST. The basic architecture would look similar to a thin client however the client-side application now takes on more of the stand-alone architecture on the client. The standalone architecture is augmented by network connectivity-based services.

    • The benefit
      • Rich user interface.
      • Can run with limited functionality anywhere and anytime
    • The negatives
      • To update the application requires user intervention or some other process.
      • A rich user interface can approach a near-infinite combination of interactions and input which makes it impossible to test every combination. In addition, fragile connectivity and many device types make it impossible to approach zero defects.
  • Occasionally Connected Applications: The occasionally connected application is similar to the fat client application. The difference is the application is designed to work even without a connection. A good example is Outlook. Outlook can work even when no connection is available. For most applications, this means creating some mechanism to retrieve and cache data from network data storage. This can be done using web services or some kind of sync service like SQL Server Merge Replication. In addition, data can be pushed to the clients. With the new .Net framework 3.5 it can be accomplished using Exchange and the store and forward communication mechanism of WCF. This allows for pushing information or signaling the application to perform an action. This adds additional services to the device-side client.
    • The benefit
      • Rich user interface.
      • Can run with full functionality anywhere and anytime
      • Connectivity code isolated and thus easier to manage and build solid error handling
    • The negatives
      • To update the application requires user intervention or some other process.
      • A rich user interface can approach a near-infinite combination of interactions and input which makes it impossible to test every combination. In addition, many device types make it impossible to approach zero defects.

Application Architect<ref>Application Architect

The Application architect is a lead or technical manager in the computer programming team who is specialized in the application built and the technologies used.

  • Knowledge domains
    • Application modeling: Employs modeling as a framework for the development of new or enhanced applications, uses modeling to find problems, reduce risk, improve predictability, reduce cost and time-to-market, tests various product scenarios, incorporating clients' needs/requirements, adds test design decisions to the development process as necessary, evaluates product design problems.
    • Competitive intelligence, business modeling, strategic analysis: Understanding of the global marketplace, consumers, industries, and competition, and how global business models, strategies, finances, operations, and structures interrelate. Understanding of the competitive environment, including the current trend in the market, industry, competition, and regulatory environment, as well as an understanding of how the components of a business model (i.e. strategy, finances, operations) interrelate to make an organization competitive in the marketplace. Understanding of the organization's business processes, systems, tools, regulations, and structure and how they interrelate to provide products and services that create value for customers, consumers, and key stakeholders. Understanding of how the value created for customers, consumers, and key stakeholders aligns with the organization's vision, business, culture, value proposition, brand promise, and strategic imperatives. Understanding of the organization's past and present achievements and shortcomings to assess strengths, weaknesses, opportunities, and risks in relation to the competitive environment.
    • Technology: Understanding of IT Strategy, development lifecycle, and application/infrastructure maintenance; Understanding of IT service and support processes to promote competitive advantage, create efficiencies and add value to the business.
    • Technology standards: Demonstrates a thorough understanding of the key technologies which form the infrastructure necessary to effectively support existing and future business requirements, ensures that all hardware and software comply with baseline requirements and standards before being integrated into the business environment, understands and is able to develop technical standards and procedures to facilitate the use of new technologies, develops useful guidelines for using and applying new technologies.
  • Tasks: An applications architect is a master of everything application-specific in an organization. An applications architect provides strategic guidelines to the applications maintenance teams by understanding all the applications from the following perspectives:
    • Interoperability capability
    • Performance and scalability
    • Reliability and availability
    • Application lifecycle stage
    • Technological risks
    • Number of instances

The above analysis will point out applications that need a range of changes – from a change in deployment strategy for fragmented applications to a total replacement for applications at the end of their technology or functionality lifecycle.

  • Functionality footprint: Understand the system process flow of the primary business processes. It gives a clear picture of the functionality map and the applications footprint of various applications across the map. Many organizations do not have documentation discipline and hence lack detailed business process flows and system process flows. One may have to start an initiative to put those in place first.
  • Create solution architecture guidelines: Every organization has a core set of applications that are used across multiple divisions either as a single instance or a different instance per division. Create a solution architecture template for all the core applications so that all the projects have a common starting ground for designing implementations.

See Also

Software Architecture
Application Development
Application Infrastructure
Application Infrastructure Suite (AIS)
Application Integration
Application Lifecycle Management (ALM)
Applications Portfolio Analysis (APA)
Application Portfolio Management (APM)
Enterprise Architecture
Business Architecture


Further Reading