Physical Architecture

In continuation with our series on empowering seasoned developers to be a successful & informed software architect, this blog’s focus is on creating effective physical architecture diagram. 

Read our earlier blog on creating effective logical architecture here.

Physical architecture (also known as deployment architecture in UML) gets created as an artifact as part of Software Architecture Document and defined as:

Physical Architecture defines the layout of components & system elements (as deployable units) in the context of system architecture along with depiction of real products & hardware appliances.

An effective physical diagram is important as it serves the purpose of communicating system under consideration’s infrastructure to various stakeholders (such as enterprise architect, infrastructure/cloud architect, data architect, security architect, vendors etc.). 

Our experts have grouped together 5 key tips to make sure you create an effective physical architecture:

Tip#1 – Cloud vs. On-premises for underlying Infrastructure/Platform

With the rise of cloud, the foremost decision needs to be made by senior stakeholders that whether cloud or on-premises or hybrid approach will be leveraged. This impacts on how you want to represent various components/elements & hence this decision is primary input to create physical architecture.

Cloud vs. On-premises
Cloud vs. On-premises

Tip#2 – Align Physical Architecture with components from Logical Architecture 

In our previous blog, we talked about purpose of logical architecture and both physical and logical architecture should be in sync so that any stakeholder can understand mapping between the same. A disjointed physical architecture has the risk of missing components/elements, which can lead to bigger problems at later stage.

Tip#3 –  Validate with capacity modeling to ensure any gap in meeting requirements

Capacity modeling is an in-depth analysis of non-functional requirements and required infrastructure. Even though cloud offers flexibility in providing on-demand capacity management, it is an important activity as it determines the cost & configuration required. For example, if you don’t specify peak-load, then your system gets overloaded because of high demand, your finances can go north if not controlled carefully.

Here is an example of finding out required JVM memory for a typical Cache Server:

Step 1- Calculate Total Heap Memory Requirement

Total Heap Memory Size = 2 * (Number_of_Sessions) * (Average_Number_of_Cached_Objects per Session) * (Average_Number_of_Bytes per Cached_Object)

So, if there are 200 concurrent sessions having 200 objects of size 50KB per user session, Total Heap Memory Size = 2 x 200 x 200 x 50KB = 4000 MB (approx.) Multiplier of 2 is used to indicate 1 primary & 1 backup for cache. If there are more backup nodes needed for higher availability, it needs to be adjusted.

Step 2- Calculate Available Heap Size

If you consider 1GB as Maximum Heap Size for each node, you can’t leverage 100% of Heap considering the assumption that 60% of Heap is being used for storage.

Available Heap Size = (Maximum Heap Size) * 60%
(Note that 60% can be a variable factor and based on assumption.)

In current example, Available Heap Size = (1024 MB) * 60% = 614 MB (600 MB approx.)

Final Step – Calculate Number of Cache Servers

Number of Cache Servers = (Total Heap Memory Size / Available Heap Size)

So, in current example, we will need:

Number of Cache Servers = 4000 / 600 = 6 nodes

Tip#4 – Take acceptance from multiple stakeholders – infrastructure, data, security, enterprise & application architects

A physical architecture is not one man’s job and you require input from various subject-matter experts (such as data, security) to make sure all relevant areas have been covered. Don’t forget to get formal acceptance/sign-off from these stakeholders to avoid any surprises.

Tip#5 – Validate it with multiple vendors (subject matter experts)

As each cloud or hardware vendor has underlying interest, you can leverage their expertise to validate finalized approach. As subject-matter expertise in their field, they can offer valuable insights to make sure you have covered all aspects.

That’s it!! These simple tips can help you in coming up with an important architectural artifact, which is usually part of software architecture document. Don’t forget the overall objective is to make sure business objects (functional & non-functional) are met with what you have come up with!!

Here is a simple physical architecture diagram you can refer to:

Physical Architecture
Physical Architecture

 

Additional logical architecture sample using Amazon AWS Components 
(2-tier scalable logical application architecture)

AWS Physical Architecture Diagram
AWS Physical Architecture Diagram

 

Leave a Comment