Business Domain Architecture (from technology point of view)

Business Domain Architecture

Business Domain Architecture (BDA) is a combination of Departments/ORG Charts and Traffic/Data Flow diagrams

BDA always helps me to understand how the Business works but, most importantly, allow me to simplify designs and decisions

Note: BDA is different from Business Application, Data and Security Architecture, but in my opinion, you can not provide that architecture without DBA

I will create a BDA Diagram for this post, so it is entirely made-up Business instead of using one of my actual diagrams, but it demonstrates the points
let’s say the company is called ParsCorp, and it has IT, HR, Finance, Marketing, customer service, CEO/Bord, Risk and Factory
ParsCorp assembles TV and Monitors and has 2 physical locations, HQ and Factory

the first step is to create a diagram that shows different departments in the company and if they have any teams inside them

visual representation of ORG chart plus more

in this case, I focused on the IT department and created a complete subitems category
this could help to identify the capability map related to each department or domain
now let’s focus on the IT domain and find out what functionality IT need to provide for this company to run (we could create a diagram that shows current capabilities or minimum capabilities)
Diagram 1 shows the power of an IT department for a small company, and Diagram 2 offers a larger company with could footprint

Domains plus allowed traffic flow

Datacentre Design

Datacenter Network Design

In this post, I will try to show the power of a clear and straightforward diagram for building and troubleshooting a complex datacentre

This project was for one of the most significant IT projects in Australasia, but here I want to talk about a small piece of the project which is the physical Networking for one of the datacentres.

Note: This project is almost eight years old, and all the names and configs in these diagrams are replaced

Technical Requirements

  • The solution MUST support IPV6
  • The solution MUST support a multitenant environment
  • The solution MUST support SDWAN
  • The solution MUST provide tenant and customer separation
  • The solution MUST support SDN
  • The solution MUST support scale-up and scale-out

Solution

  • Any one of the big brands would support IPV6
  • v-Routers, v-Firewalls and vLAN will be used
  • Any one of big brands would support SDWAN
  • Managed to and Managed from design
  • Any one of the big brands would support SDN
  • any clustering will provide the solution

Physical Connectivity

DC1 Cloud A – Physical Network Diagram

In this diagram, you have all the physical locations (e.g. rack number), name of the device, functionality and IP address to connect to the device
since it is not a rack design, so you do not have the exact location in the rack, but instead, you have all the physical connectivity, speeds and identical port number, including connectivity to other infrastructures
having the port numbers in this diagram was handy as I could request a configuration on the exact port without searching a spreadsheet for the correct port number

DC1 Cloud B – Physical Network Diagram
Managed to inter DC Connectivity

The logical diagram presents a multi-tenanted multi-datacentre solution.
Building Block Architecture (BBA) patterns are everywhere in this design for instance; every tenant has the same component LB/Router, the same connectivity to the tools and internet, which would help for automation and simplify the troubleshooting

Managed From Inter DC connectivity

at this stage, we could imagine a new customer and see how this pattern could be applied to the solution