Architecture Design Guide

1 Software Architecture & Design

1.1 Definition:

“The software architecture of a program or computing system is the structure or

Structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them”

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

 

1.2 The Principles of Architecture Design

Consider the following key principles when designing your architecture:

Identify the areas which need to undergo change and which are hard to change: Consider the areas where the Architecture requirements are not clear vs. the areas where the requirements are very clear, separate these two areas in the initial Architecture blue print so that change areas are very clear.

Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.

Model to analyze and reduce risk. Use design tools, modeling systems (like UML) to analyse and identify the risks early in Architecture.

Communciate and Colloborate the Visualisation: Efficient communication of the design, the decisions you make, and ongoing changes to the design, is critical to good architecture. Communicate the model in the early lifecyle of the project, convey the decisions to the Stakeholders and get the buy-in.

Identify key engineering decisions. Identify the areas in Architecture which needs engineering decisions (like deployment decisions. Use of framework etc) and convey the decisions to stakeholders. 

 

2 Key Design Principles

When getting started with your design, keep in mind the key principles that will

help you to create an architecture that adheres to proven principles, minimizes costs and maintenance requirements, and promotes usability and extendibility.

The key principles are:

Separation of Layers/Tiers: Separate the different main layers in the application, the components in each layer. Also, decide about which Tiers the components should run in deployment. This is to achieve low coupling and high cohesion in the same layer.

Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.

Principle of Least Knowledge (also known as the Law of Demeter or LoD). A

component or object should not know about internal details of other components

or objects.

Don't repeat yourself (DRY). You should only need to specify intent in one place. For example, in terms of application design, specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.

Minimize upfront design. Only design what is necessary. In some cases, you may require upfront comprehensive design and testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront (BDUF). If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. 

 

2.1 Design Steps for a Layered Structure

When starting to design an application, your first task is to focus on the highest level of abstraction and start by grouping functionality into layers.

A typical series of design steps is defined in the following ladder network.

Step 1 – Choose Your Layering Strategy

Step 2 – Determine the Layers You Require

Step 3 – Decide How to Distribute Layers

Step 4 – Determine if you need to Collapse Layers

Step 5 – Determine Rules of Interaction between

Step 6 – Identify Cross Cutting Concerns

Step 9 – Choose Communication Protocols

Step 8 – Choose Deployment Strategy

Step 7 – Define Interface between layers

 

Step 1 – Choose Your Layering/Tier Strategy

This is the first critical step.

• Logical separation of Application components:- First decide on how many layers/Tiers the application will require. Tier means running the layering components on separate deployment (physical machines).Normally application is minimum split in to 3 layers (Presentation, Business and Data Access Layer. For more scalability and Tier we can prefer an n-tier approach as required for a specific application context).

• For Layers which has run on Tiers, the communication protocol across tiers is very important as it tends to slow down the performance due network latency  

• Too low layering/Too high Layering leads to complexity.

 

Note:- At the end of Step1, it will decide Layers and the 3 Tier/n-Tier approach. 

 

Step 2 – Determine the Layers You Require

• Group the functionality in to different layers. Classical example: Three basic Layers Presentation (GUI), Business (Business logic) and Data Layer (Data Access components).

• Consider Crosscutting Layers: Example we can have layers for common services like Logging, Caching, Reporting, Exception Management, Reporting.

• If the application does not require any services to be expose, no need for a Service Layers all can be in layer components.

 

Step 3 – Decide How to Distribute Layers and Components

• Distributing Layer/components to Physical tiers. Example: If the application requires presentation to call business logic synchronously, consider both Presentation and Business on the same Physical box.

• Any services need to be exposed, consider it on a separate physical box.

• In Rich client, The UI predominantly process on Desktop’s so Business layer can be separated.

 

Step 4 – Determine If You Need to Collapse Layers

Some times it makes sense to collapse layers,

• For example, if the application has very less business rules, it is mainly validation, we can club both Presentation and Business in to one layer.

• For example if the application requires the presentation to access a Web Service to pull data and display, both the layers can be clubbed in to one.

 

Step 5 – Determine Rules for Interaction Between Layers

We need to define how the layers will interact with each other

Rule 1:-Top-down interaction. In this the Higher level layers can interact with layers below, but a lower level layer should never interact with layers above. This rule will help you to avoid circular dependencies and also dependencies between layers.

Rule 2: -Strict interaction. Each layer must interact with only the layer directly below.

The benefit of this rule is that modifications to the interface of the layer will only affect the layer directly above. Consider using this approach if you are designing an application that will be modified over time (or) if the application has to be distributed across physical tiers.

Rule 3: -Loose interaction. In this higher level layers can bypass layers to interact with lower level layers directly. This can improve performance, but will also increase dependencies.Consider using this approach if you are designing an application that you know will not be distributed across physical tiers (for example, a stand-alone rich client application)

 

Note:- Rule 1 & Rule 2 are the preferred rules for Design.

 

Step 6 – Identify Cross Cutting Concerns

• Group the functionality which is common to all the layers as Cross cutting layer/Concerns.

• Example: Logging, Caching, Authentication, exception management.

• Explore different methods like AOP(Aspect Oriented Techniques) to implement the same.

 

Step 7 – Define the Interfaces between Layers

• Primary goal is to enforce loose coupling between layers. Layers should not expose

 

Internal details to another layer. This will reduce dependency.

Design Approaches:

Abstract interface. Create an Abstract Interface at layer level so that all consumers use this interface to interact with the layer. This improves testability.

Common design type. Use common Design Data Type pattern to provide abstraction to access the data. Example: Use of a Common DAO object for communication hiding the developer not to worry about how to write the SQL.

Dependency inversion. Two layers depend on a common interface instead of one layer depending on another. In this pattern, the dependency between layers are exposed through A configurable setting indicating which component will call which one and how.

This provides high flexibility and testability.

Message-based. Instead of directly interacting with components in another layer through method calls (or) invoking objects, we can use a message based communication between layers through a common message format and protocol. This provides flexibility in deploying components to tiers, improves scale for the application and component can interact across physical boundaries. Sometimes, consider message based approach if you want the layers to be invoked asynchronously and not synchronously.

Ex: Web Service, MQ Communication etc.

 

Step 8 – Choose Your Deployment Strategy

• Choose the appropriate Deployment model (Like Presentation, Business and Data Layer in separate boxes etc)

 

Step 9 – Choose Communication Protocols

• For communication across layers particularly across tiers, use a proper communication protocol. This will play a major role in performance, scale & Security.

 

Ex: Web Service (XML/SOAP, REST/http, TCP/IP, MQ protocols.

 

3 Logical & Component view – Typical Layered System

Logical Architecture View


 

Logical Components View

 

 

4 Presentation Layer Guidelines

The presentation Layer components are normally divided in to 2 Components:

User interface (UI) components: User interface components provide a way for users to interact with the application. They render and format data for users. They also acquire and validate data input by the user.

User process components: User process components synchronize and orchestrate user

interactions. They provide the base level validations.

Design Approach

Strategy for Communication with Layers

Business Logic Strategy

Data Validation Strategy

How to Present Data

Identify Client Type 

 

4.1 Design Considerations

Choose the appropriate UI technology: - Determine if you will implement a rich (smart) Client, a Web client, or a rich Internet application (RIA). This should be abased on operational constraints and infrastructure requirements.

Use the relevant patterns: Review the presentation layer patterns for proven solutions to common presentation problems like MVC, MVP.

Design for separation of concerns.: Use dedicated UI components that focus on rendering and display. Use dedicated presentation entities to manage the data required to present your views. Use dedicated UI process components to manage the processing of user interaction.

Consider human interface guidelines: Review your organization’s guidelines for UI design. Review established UI guidelines based on the client type and technologies that you have Chosen. Localization and usability to be considered.

Adhere to user-driven design principles: Before designing your presentation layer, understand your customer. Use surveys, usability studies, and interviews to determine the best presentation design to meet your customer’s requirements.

 

4.2 Presentation Layer – The Key HotSpot areas

The key hotspot mistake areas in presentation layer can be classified as follows:

• Caching

• Communication

• Composition

• Exception Management

• Navigation

• User Experience

• User Interface

• Validation

 

4.3 Presentation Layer – Design Guidelines Category	Guidelines
Application type	• Rich Smart Client/Web Client/ RIA Client • Consider Application environment, Infrastructure constraints.
Choose UI Technology	• Choose appropriate UI for the client (like Mobile applications, RIA, Web Clients) – Ex: Java FX, Silverlight, AJAX
Presentation Pattern	• Choose the pattern (MVC, MVP, MVVM).
Separation of Concerns	• Use Dedicated Presentation components. This should separate it from Business and other layers. • Consider Use of Dedicated Presentation controls.
UI Guidelines	• Use the appropriate UI organization standard (Ex: UX Studio) • Supporting localization & Globalisation
User Driven Principles	• Customer knowledge • Customer Survey • Use Scenarios
Performance	• Consider the input format validation in UI layer itself- Improves performance, avoids round trips • Consider asynchronous communication between UI & Business to improve performance. Reduces latency. • Consider Caching for historical/static/unchanged UI data • Consider the input format validation in UI layer itself- Improves performance, avoids round trips

 

4.4 Presentation Layer – The Key HotSpot stack frame Category	Common Issues
Caching	• Caching volatile data. • Caching unencrypted sensitive data. • Incorrect choice of caching store. • Assuming that data will still be available in the cache – it may have expired and been removed
Composition	• Failing to consider use of patterns and libraries that support dynamic layout and injection of views and presentation at runtime. • Using presentation components that have dependencies on support classes and services instead of considering patterns that support run-time dependency injection. • Failing to use the Publish/Subscribe pattern to support events between components. • Failing to properly decouple the application as separate modules that can be added easily.
Exception Management	• Failing to catch unhandled exceptions. • Failing to clean up resources and state after an exception occurs. • Revealing sensitive information to the end user. • Using exceptions to control application flow. • Catching exceptions you do not handle. • Using custom exceptions when not necessary.
Input	• Failing to design for intuitive use, or implementing overly complex interfaces. • Failing to design for accessibility. • Failing to design for different screen sizes and resolutions. • Failing to design for different device and input types, such as mobile devices, touch-screen, and pen and ink– enabled devices.
Layout	• Using an inappropriate layout style for Web pages. • Implementing an overly complex layout. • Failing to choose appropriate layout components and technologies. • Failing to adhere to accessibility and usability guidelines and standards. • Implementing an inappropriate workflow interface. • Failing to support localization and globalization.
Navigation	• Inconsistent navigation. • Duplication of logic to handle navigation events. • Using hard-coded navigation. • Failing to manage state with wizard navigation.

 

5 Cross cutting concerns- Key Design Aspects

The following sections list the key Cross cutting Design areas in Cross cutting to consider as you develop your architecture, and contain guidelines to help you avoid the common issues in each area:

• Authentication

• Authorization

• Caching

• Communication

• Configuration Management

• Exception Management

• Logging and Instrumentation

• State Management

• Validation

Category	Guidelines	SCB Considérations(if any)
Authentication	• Identify the trust boundaries. • Identify Authenticated calls from the client, server and to other Services. • Enforce use strong passwords • Do not store passwords as plain text in DB (or) File. Use Hash based password • If multiple applications /multiple systems within the same domain with user credentials. Consider Single-sign on.	• Use of LDAP as per organization standards. • Password rules as per GIS policy & Standards
Authorisation	• Identify the trust boundaries • Identify the callers by identity, groups and roles. • Use role based identity for Business Decisions. • Use Resource based authorization for system auditing. • Use Claim based Authentication when you are going through a Service.	• LDAP based credentials • Web Service authentication. • Claim based Authentication for Internet enabled clients.
Caching	• Consider Caching for Static data, near Static Data. • Do not cache Volatile data/Sensitive data. • Decide Caching store (in memory/disk). • Instead of custom developed Cache strategy, Use a standard Caching framework. • For Web Applications involving more parallel servers, Use Standard Caching mechanism. •Design applications to handle Cache failures •In Multi thread environment, ensure Cache	• Use of ORM, EJB, Hibernate • .NET projects, Enterprise Cache Library. • WAS Level Caching.

 

6 Non Functional Requirements - Design Guidelines

The following list the key Non fuctional requirements (or) the Quality attributes which plays a major role in the Architecture & Design of applications. The section will cover the guidelines related to each of these areas.

• Availability

• Conceptual Integrity

• Interoperability

• Maintainability

• Manageability

• Performance

• Reliability

• Reusability

• Scalability

• Security

Category	Guidelines	SCB Considérations(if any)
Availability	• Identify the failure points like DB Server, App Server. • Identify Systemic Failure points like Network, Disk Failures. • Identify Denial of Service Attacks (DoS) areas. • Identify Long running resources. • Identify Bug/Fault areas in Application • Identify Trust boundaries in the application.	• Use of Load Balancers Like Alteon • Use of Clustered Servers like WAS ND • Release of long running resources like DB Connnections using Connection Pools. • Using Connection less client access to get over network failures. • Planning for Systemic Upgrade to System Software and Application Software • Use of NFR to capture the HA Requirements from the Business (i.e. weather it is 24*7 etc).

 

7 Business Layer – General Design Guidelines

The following general guidelines for Business Layer are mentioned as below Criteria	Guidelines
Decision for Business layer	• Good to have this layer in most cases as it improves maintainability • If the application does not have much of Business Validation and more of Data Validation, We can club this layer with Presentation.
Identify Responsibilities	• Identify the Business rules, Validations, Complex Logic • If you layer is going to be used by Presentation Layer and also external interface, consider making this layer as Service.
Avoid mixing Components	• Avoid Business Validation at Presentation and DB layers. • Total separation will ensure proper testability of this layer without much dependency.
Reduce Round trips	• If this Business Layer is going to be deployed on separate Physical Tier, Consider a Façade to take care of the Fine grained operations to avoid round trips. • Use of Data Transfer Objects for Coarse grained operations.
Avoid Tight Coupling	• Use more abstraction for accessing the Business Layer components. • If it is Web, Use more of messaging to communicate with Business Layer.
Deployment Guidelines	• Consider deploying the business layer on the same physical tier as the presentation layer in order to maximize application performance, unless you must use a separate tier due to scalability or security concerns. • If you must support a remote business layer, consider using the TCP protocol to improve application performance. • Consider using Internet Protocol Security (IPSec) to protect data passed between physical tiers. • Consider using Secure Sockets Layer (SSL) encryption to protect calls from business layer components to remote Web services.

7.1 Business Layer – Design Steps

The following steps serve as Guidelines for Designing the Business Layer. Step	Guidelines
Create High Level Design	• Identify the consumers of the Layer (like Presentation, Service etc). • Identify how to expose the Business Layer (ex: Service/Components)
Design Business Components	• Identify the Business Logic Components, Utility components, helper components. • Location: Decide on the location (Client Side/Separate Layer, if it is to support multiple UI’s/Devices). • Coupling: Tight Coupling (or) loose coupling • Interaction: If Business components are in the same Tier as Presentation, Try to use events, methods interaction to improve performance.
Design Business Entities	• Use Business Entity modeling of data. • Use of access methods and properties to access the Data.
Design Workflow Components	• If there is stepped process based on some order, consider workflow process in Design. • For Human Workflow Scenarios, Like Maker/Checker and approver, workflow design to be considered.
Design Rule Components	• If Business Logic is so dynamic, then consider rule engines. • Rule Engines are performance heavy, If Business is modeled using Process Orchestration, consider rule engines. (ex: iLog(J2EE),Drools(J2EE), WWF (.NET)

 

8 Data Layer – General Design Guidelines

The following general guidelines for Data Layer are mentioned as below Criteria	Guidelines
Choose Data Access Technology	• Depends on the type of Data the application is likely to handle. (ORM/Normal DAO objects) Ex:(Hibernate, ADO.NET, JDBC, JPA, LINQ)
Loose Coupling	• Use Abstraction for loose coupling to access the data layer. Business rules, Validations, Complex Logic • Ensure the Business Layer (the one layer above) calls the Data Access Layer.
Encapsulate Data Access	• To hide the physical Data Source Access. • Consumers to call only abstract interfaces through Custom objects/Entities. • Hide Internal details of the Data Access Layer like tables etc.
Mapping Application Entities	• ORM Mapping • Identify the strategy for Data Mapping with the Data Source and presenting to Business Layer.
Consolidating Data Structures	• Consolidating Data and relationships through DTO Objects. (Object Consolidation). • Use Facades to expose the DTO’s for Coarse grained operations.
Connection Management	• Use of Connection pools. • Releasing Connections early (or) unknown events. • Optimum use of physical connections. • Exception Handling of Connection issues.
Exception Management	• Capture all CRUD Exceptions • Capture timeout errors
Security	• Consider DB provider security for the Data • User Account privilege to manage data • Parameterized Queries (Avoid SQL Injection) • Avoid String Concatenation for Dynamic queries.
Reduce Round trips	• Consider batching commands
Performance & Scalability	• SIMD (or) Multiple Databases • DB Locking Strategy • DB Clustering, Partitioning • DB Volumes (Non Functional Requirements

 

 

 8.1 Data Access Layer – Design Steps

The following steps serve as Guidelines for Designing the Data Access Layer. Step	Guidelines
Create High Level Design	• Identify the Schemas, Tables, Objects, Access controls. • ERM Modelling. • Identify whether multiple source applications accessing/modifying the data.
Design Entities	• Identify the business entities using classes. • Entity model vs. Actual data abstraction.
Choose Data Access Technology	• ORM mapping • Choice of Technology like Hibernate, ADO.NET, LINQ etc.
Design Data Access Components	• Use of Properties, Access methods for Data Objects. • Use of Patterns like Command Object pattern for CRUD Operations.
Design Service agents	• Design Data Access as Service for multilayer access. • Choose the proper Service methodology (Web Service, REST) for the Data Services.