Solution Physical Diagrams
The third of three (3 of 3) diagrams in the Architectural Diagrams & Solution Components series depicts platforms which host the Solution's physical Components. Specifically, these diagrams depict the platforms upon which each Solution Environment operates, along with the basic configuration of each.
For the most part, the Physical Diagrams depict the platforms that host the Logical Components of each Environment used to build, test, and operate the Solution. The diagrams segment the platforms by infrastructure Tier in which each operates, and by the operating Environment(s) each supports within a given Domain.
Unlike the other Architectural Diagrams, which depict and summarize much of what is otherwise written within the Solution Strategy and Solution Approach, the Physical Diagrams help guide the source definition for each platform, considering the physical Components each platform expects to support.
Begin Template
Solution Diagrams (3 of 3): Physical Perspective
The Solution Physical Diagrams depict the platforms that support the physical Components which comprise the individual instances of the Solution. In other words, the physical Components that enable each Environment.
Whereas the Logical Diagram depicts the logical Components for any one Environment, Physical Diagrams consider the platforms necessary to host all physical Components required to enable all Environments. In short, these diagrams combine platform information from the Operations Strategy, with desired Environments from the Operations Approach, to define the platforms upon which the physical Components enabling each Environment will operate.
Basically, these diagrams convey relevant configurations of the platforms upon which the Solution's Components - as described by the Solution's Logical Diagram - operate for each Environment in each Domain.
Diagram Organization
The organization of the Physical Diagrams begins with infrastructure Domain. The reason for this is that Domains often impose certain restrictions which limit the use of any specific Environment. For instance, a Production Domain is often much more tightly controlled, and hence less flexible, than a Development Domain. Similarly, a Quality Assurance (QA) Domain falls somewhere in between. Hence, group Environments which can operate with similar constraints in the same Domain. Likewise, they should appear on the same page, if possible.
The organization of Physical Diagrams next considers Environments, which may also impose constraints or otherwise segment work efforts. Each Environment is a column which segments the Domain. Most Solutions typically require multiple Environments in which certain user groups can accomplish certain tasks without creating havoc for one another. For instance, the most basic implementation may have a Development (DEV) Environment and a Production (PRD) Environment. In truth, an enterprise-scale implementation may warrant a dozen or more Environments to move things along efficiently and effectively.
Thirdly, organization of Physical Diagrams also conveys the Infrastructure Tier in which the physical Component(s) each platform hosts belong. Rows across the page represent individual tiers spanning relevant Environments. For the most part, these should correspond to the Technology Tiers which the Logical Diagram depicts. Although, the Logical Diagram likely also implies platforms beyond the physical Components of this Solution, such as User Devices and Related Solutions.
The Technology and Infrastructure Tier names may differ between Domains. To explain, like logical Components, the Technology Tiers are general. Whereas, like the platforms and physical Components, Infrastructure Tiers represent actual values defined by the organization which hosts the Domain. Accordingly, tier names could differ if different entities host different Domains.
Generally, each Domain page depicts the platforms to enable all Environments which operate in that Domain, segmented by applicable Infrastructure Tiers. In other words, each Domain has a single diagram page. Although, if the depiction of any one Domain becomes too cluttered, the Domain may split across multiple pages. Conversely, every attempt is made to not split the platforms supporting the physical Components of any single Environment across multiple pages.
Solution Platforms
A Solution's Operations Strategy typically defines up to three (3) Domains. For the most part, these are determined by the organization within which the Solution operates, independent of the Solution itself. Although, external hosts or service providers may also define one or more additional Domains. Basically, each Domain represents a separation from other Domains for things like levels of security and access, or formality of enterprise Change Control. Accordingly, each Physical Diagram defines the platforms the Solution will use to support the physical Components of each Environment within the given Domain.
The SW & HW requirements which apply to logical Components dictate which physical Component(s) may reside on which platform(s). Likewise, they may also prohibit the co-hosting of some physical Components with others.
In many cases, it is easier and less costly have fewer platforms with larger configurations (more memory, or CPUs) rather than many more platforms with smaller footprints. Although, in addition to SW & HW requirements, such decisions must also consider vendor or host pricing, redundancy and availability, as well as existing IT and/or Host provider policies and conventions.
As shown in the diagrams, the primary information which the Physical Diagrams provide, include:
- Icons for each platform upon which to install and configure the various physical Solution Components.
- Placement of the platform icon in the column corresponding to the Environment(s) the physical Component(s) support.
- Placement of the platform icon in the row corresponding to Infrastructure Tier of the physical Component(s) it hosts.
- Basic information on each platform's configuration, such as naming, address, size, etc.
Physical Components
The term "physical" should not be misleading. In general, it implies 'tangible' more so than 'touchable'. Even in a Cloud-based Domain, the configuration of platforms provides various types of servers, services, etc.  Each platform has attributes which distinguish it from others, such as a Name, IP Address, and other configuration values. Those values define the platform's "physical" attributes.
Likewise, each logical Component corresponds to a physical Component once its configuration aligns the Component to a given Environment. For instance, a general concept of a Web Server becomes a physical Web Server when configured to support a Development Environment. Likewise, a general Database Server becomes a physical Database Server when configured to support the Production Environment.
Like the platforms, it is the configuration values which distinguish the DEV Web Server(s) from those which support the Test, Production, and other Environments. Indeed, most logical Components have corresponding physical Components. Moreover, each has a distinct configuration based upon their 'physical' attributes, or configuration values, allowing them to support a specific Environment.
Defining basic configurations begins with a map of which physical Component(s) each platform will host. To explain, the diagrams map physical Components by aligning platforms with Environments. At this point, there is no further need to define the physical Components the diagrams imply. Thereafter, SW & HW requirements of relevant Components guide each platform's basic configuration, such as the number of CPUs or amount or RAM each has.
Defining Configurations
The purpose of the Physical Diagrams is to describe the platforms that will support the Solution's physical Components. In other words, to identify the platforms required, and to define a basic configuration for each. Thereafter, this basic information provides the necessary inputs to determine infrastructure costs and other resource requirements. Of course, there are often trade-offs between the platforms desired and the budget for them. Accordingly, that balance is struck here.
Note that Physical Diagrams are not the long-term definition for any platform's configuration. Rather, they provide guidelines to support planning (timing, availability) and budgeting (cost estimates). Those installing and configuring the platforms and physical Components will capture the actual values during Feature Planning and Story Analysis of the Features and Stories that establish each Environment. Refer to the Operations Approach for more information on setting up each Environment.
Aligning Physical Components to Solution Platforms
It is unusual for most platforms to span multiple Domains. For instance, a platform for a Database Server is unlikely to support Environments in both the Development (DEVL) and Production (PROD) Domains. Although, it is common for such platforms to support more than one Environment within a Domain. For example, one platform might support the Development (DEV) and Test (TST) Database Servers for the Build, Candidate, and Production Releases. That is, one platform supports all six (6) physical Database Servers needed to support those Environments in the Development Domain.
Alternatively, it may be better to place the DEV and TST Database Server Components on three separate platforms, one for the Build Release, one for the Candidate Release, and a third for the Production Release. Or, to host the three DEV Environments on one platform and the three TST Environments on another. Likewise, perhaps there are reasons not to co-host Database Servers on the same platform as their corresponding Web Servers. Of course, there may be good reasons to ensure multiple platforms host similar Components for high-availability and/or performance.
Indeed, there are many ways to organize, size, and configure most platforms. The challenge is in determining the most cost-effective configurations to support the desired physical Components for each Environment. In short, this is what the Physical Diagrams define.
End Template /
Optionally, include the following Checks & Balances.
Checks & Balances - Alignment to Other ITM Artifacts
This section is available in many Solution Strategy & Architecture artifacts, to help those who create, and use, this information see the "bigger picture".
Checks & Balances highlight where similar information appears in multiple locations. The reason to display info more than once is to help ensure alignment and consistency across all stakeholders. Each appearance offers a different perspective for a different audience. The more widely available such information becomes, the more likely it is to drive common understanding. As a result, this helps initiatives to progress more quickly and with fewer impediments.
Physical Diagrams
The pages within the Physical Diagrams should correspond to the Domains which appear in Table SS8.1: Infrastructure Domains of the Operations Strategy. For each Domain which appears in the table, there should be one Physical Diagram page.
Likewise, the platforms which appear on the Physical Diagram pages should correspond to those which Table SS8.2: Infrastructure Platforms lists in the Operations Strategy. However, the table does not define any particular configuration for those Components.
To determine the basic configuration for any platform, stakeholders must consider the physical Component(s) each platform is to support. Accordingly, they most consider Software and Hardware requirements from Table SC1.5: Software Requirements and Table SC1.6: Hardware Requirements in the Solution Components.
Of course, the Environments which the Physical Diagrams depict within each Domain must correspond to those which Table SA8.1: Solution Operations Environments lists within the Operations Approach. It is common for the definition of Physical Diagrams to drive conversations about Environments, sometimes leading to their addition or removal.
Finally, the basic configurations of the Production Environment platforms must consider the Cumulative Users defined in Table(s) SS1.4: Solution Phase - [Phase Name] of the Application Strategy. Preferably, the Cumulative Users should account for all known or potential Phases rather than just the pending Phase.
Diagram Development & Use
Depending upon whether the Solution is a Product, System or Service, the corresponding Product Architect, System Architect or Service Architect creates or updates the Solution's Logical Diagram. In cases where these roles are not staffed, a Solution Architect may produce this diagram until the other role is filled. Regardless, the Architect produces the diagram in collaboration with the Solution Manager and appropriate IT representatives, and/or representatives familiar with the designated hosting platforms.
To create the initial version, begin with a Physical Diagram Template that provides standardized page layout and icons to use. Otherwise, create a diagram based on the sample above. Afterwards, to update the Physical Diagrams for a subsequent Phase, use the most recent version from a preceding Phase.  Thereafter, follow the steps below to create or update a Solution Physical Diagram. Regardless of which Phase the artifact is for, initial development of the current version can begin after making Environment decisions and the Logical Diagram exists. However, it must conclude prior to Phase Inception.
As a result, the Physical Diagram depicts authorized platforms upon which to install Solution Components. Furthermore, it also depicts the platforms supporting each Environment, as well as the Domain in which each Environment belongs. In short, the diagram depicts the locations to which DevSecOps should install and enable components for each Solution Environment.
Solution Definition
In most cases, it is best to start with the physical Component design of the Production Environment. For almost all Solutions, this Environment represents the largest environment the Solution will have. Thereafter, a Pre-Production or QA Environment which seeks to emulate Production may use the same design. Otherwise, most other Solution Environments may use a scaled down version of the Production-level design.
In some cases, an initiative may make use of a temporary Environment until the proper, longer-term Environments are available for use. Generally, Physical Diagrams do not depict or describe any interim Environment.
Not the Place to Discuss Environments
As a reminder, this is not the artifact nor stakeholders with which to determine Environments. Indeed, those discussions should correspond with production of the Operations Approach. Of course, there must be alignment between the Physical Diagrams and the desired Environments, so some cart-before-horse may occur. In other words, things like costs and resources requirements can impact Environment preferences. Accordingly, use draft Physical Diagrams to help guide Environment discussions.
To emphasize, there is rarely a need for Teams to have their own Environment. Many argue they need to work in isolation to prevent the work of others from interfering with their efforts. They may claim that working in a shared Environment will slow their progress or cause potential conflicts. However, it does not save anyone time to have development occur in a vacuum only to encounter problems and conflicts later, once changes from different Environments merge into common Environments.
At the end, all changes are destined for a single Environment - Production. Accordingly, the sooner those changes can co-exist in the same Environment, the more time is available to test them together. Similarly, if there are conflicts between changes, they will appear earlier in the Build cycle, allowing for more time to correct, and less time spent testing changes that require later modification. Accordingly, with a few exceptions, it is best for most Teams to work in the same Development and Test Environments.
A few exceptions occur when significant changes to the operational or transactional data occur. For instance, any group developing Data Migrations. Their testing of data loads will require frequent loading and clearing of data values, which may negatively impact both development and testing of other changes. In short, it is always possible that efforts to define the Physical Diagrams highlight the need for further Environment discussions which must involve the proper stakeholders.
Step 1: Page Setup
To begin, the first step in producing Physical Diagrams is to prepare the pages upon which the diagrams appear.
If the diagram file contains just the Physical Diagrams, then name the file '[Solution Name] - Physical Diagrams'. Otherwise, if it contains all Architectural Diagrams, then add these diagrams to, or create an initial version of, the file named '[Solution Name] - Architectural Diagrams'.
If placing multiple Architectural diagrams in the same file, then name this page / tab 'Physical - [Domain ID]', where Domain ID corresponds to those Table SS8.1 of the Operations Strategy defines. In either case, review and update Physical Diagram pages for any new Phase in which the diagram changes from a prior Phase.
Ideally, the Physical Diagrams depict just a single page for each Domain. Indeed, as another depiction of Solution scope, clarity is important. Asking consumers to look over multiple pages reduces clarity. However, for larger, more complex Solutions a page may become crowded. If the page contents seem too crowded, then try consolidating platforms to display a count indicating each type.
Prepare for Placement of Physical Components
Before placing physical Components on the diagrams, add this information:
- In the page Title Bar show the 'Solution Name - [Domain ID]', where the ID corresponds to one from the Operations Strategy.
- Add a column for each Environment the Domain will support.
- Label the top heading of each column container with an Environment ID that corresponds to one the Operations Approach defines.
- Add a container row for each applicable Infrastructure Tier in which Solution Components exist. In general, these align to the Technology Tiers in the Logical Diagram. Although, use the host's terminology for each tier, which may differ across multiple hosts.
- Label the page left heading of each container row with the Host's tier name.
Step 2: Work Domain by Domain
To begin, start with the Domain information from Table SS8.1: Infrastructure Domains in the Operations Strategy. The table lists the Domains, and hence Physical Diagram pages upon which to place platforms. Start with whichever Domain in which the Production Environment exists. The reason to do so is that this Environment, above all others, should have the most desirable platform configurations. Moreover, it is likely to be the only Domain with a single Environment.
Thereafter, decisions made for this Domain may affect decisions for other Domains. For instance, say those preparing the Physical Diagrams decide to co-host some set of physical Components on a certain platform type. In general, it would likewise be best to co-host the same physical Components on the same type of platform in other Domains. However, the basic configuration of each platform - CPUs, RAM, etc. - can be quite different.
Whether the basic configuration must consider performance concerns (Production) or the support of multiple Environments (Development), the reason for consistency across Domains this is that having these similar configurations provides several opportunities to install and configure the relevant physical Components. Accordingly, this provides lessons learned as well as ongoing testing and management of each physical Component on each given platform.
To clarify, Production is one of the last Environments to set up. After conducting similar setups, and monitoring operations for non-production Environments, DevSecOps is in a much better position to properly install and configure the Production Environment's physical Components than they were when installing and configuring prior Environments. In short, consistency across Domains reduces complexity and improves stability.
After completing the tasks for this Domain, move on to the next Domain from Table SS8.1: Infrastructure Domains and redo each step below. Repeat for each Domain in which a Solution Environment will exist.
Step 3: Work Environment by Environment
After selecting a Domain, look to Table SS8.2 in the Operations Strategy. The table lists the general platforms and their related components selected for use with this Solution for each Domain. At this point, the objective is to validate the use of each platform, and to then determine its basic configuration - number of CPUs, amount of RAM, storage, and so on.
When Table SS82. was compiled, there was no thought given to the number of Environments nor to opportunities for co-hosting physical Components on shared platforms. Likewise, there was no consideration given to things like performance, scalability and high-availability. Indeed, those considerations occur now.
Co-Hosting Physical Components
Of course, many platforms can support multiple physical Components. Basically, the co-hosting of physical Components can occur in any of three ways:
- Different physical Components supporting the same Environment. For example, an App Server and Web Server supporting the Dev Environment on the same platform.
- The same physical Components supporting multiple Environments. For instance, Web Servers for the DEV and TST Environments on the same platform; or
- Multiple physical Components supporting multiple Environments, in any combination which the Software & Hardware requirements permit.
In effect, starting with the Production Environment eliminates ways 2 and 3. That is, for Production, there should be no configuration which considers supporting multiple Environments. Although, there are considerations for way 1. Of course, that is not to say that any platform must co-host physical Components. Merely that co-hosting may be possible.
Moreover, as described above, for consistency, any such decision made to co-host physical Components for the Production Environment should likewise apply to the same physical Components for non-Production Environments. Furthermore, outside of Production, it is possible (indeed, probable) for some platforms to support multiple Environments.
To depict a platform supporting multiple Environments, expand the platform icon or its container to extend across the Environments which it will support. That is, to extend across multiple Environment columns on the Physical Diagrams page. Although less likely to occur, follow a similar convention to depict a platform supporting physical Components across Infrastructure Tiers.
Respecting Domain Boundaries
Ideally, each platform, as well as the attributes which belong to it, should appear only once across all pages. In other words, avoid multiple depictions of the same platform on more than one page.
To explain, each platform may include defining attributes, such as a server name, IP address, and/or count of CPUs. If the same platform appears more than once, then so do its defining attributes. As a result, this introduces a potential for conflicting information to appear in different locations. Avoiding such a scenario makes life easier for everyone. Accordingly, when seeking opportunities to co-host physical Components, look to group those Components such that any one platform only supports Environments within a single Domain.
Step 4: Work Platform by Platform
At this point, the exercise is to place each planned platform into its proper Domain, Environment, and Infrastructure Tier. There is no one best way to accomplish this. Although, following the steps above can make this effort easier.  To continue, for the given Domain, select the Environment whose platform(s) this Physical Diagrams page will depict.
For each Environment, work through the logical Components the Environment requires. Generally, it is easiest to work from major to minor Components. For instance, major Components include servers - Database, Application, Web, and so on - which typically have both SW & HW requirements as well as performance, scalability and/or high-availability considerations.
The SW & HW requirements will provide minimum guidelines. In other words, what are the least amounts of basic configurations needed to operate one physical Component on that platform. These minimums tend to increase as performance and co-hosting factor in determining the basic configuration of individual platforms.
Production Environment Platforms
For the Production Environment, look to Table SS1.4 in the Application Strategy. The table lists the Cumulative Users the Environment is to support. Additionally, check with the Solution vendor to see if they publish, or can provide, any guidelines for platform sizing. Each of these provides valuable insights for determining the basic configurations for platforms supporting the Production Environment.
The minimum number of users to consider is the total Cumulative Users by Phase end. Although, it is better to consider the total number of future users for all Phases. To be sure, infrastructure components, or a lack thereof, can become impediments to progress.
In general, it is best to have a 'do it once, do it right' approach to platforms. Having to come back later to add or update basic configurations can become problematic. Although, it is easier when dealing with virtual platforms. When not dealing with virtual platforms, then it is better to size each platform for its long-term use.
High-Availability and Scaleability
Before defining the basic configuration of any one platform, consider a few factors which may affect basic configuration decisions.
For example, from one perspective it may seem equitable to have either four (4) x 2 CPU platforms or one (1) x 8 CPU platform. From just the CPU perspective, that may be true. However, what happens if one of the 2 CPU platforms goes down? Well, three remain which can hopefully pick up the load of the (temporarily) missing platform. Alternatively, what happens when the single 8 CPU platform goes down? Well, in this case, the Solution may become unusable by anyone.
As another example, perhaps one class of platform allows for 1 - 8 CPUs in their configuration, while another class allows for 4 - 32 CPUs. If the guidelines indicate a requirement of 16 CPUs, is it better to max out 2 of the smaller platforms, or to choose one (or more) of the larger ones to allow for growth? Questions regarding high-availability, scalability, and other performance considerations are subjective. That is, there are no definitive right or wrong answers.
In most cases, answers to these subjective questions depend on three basic factors:
- The fundamental architecture of the Solution. That is, the vendor's design. What type of flexibility does it permit? Which components can or cannot scale, and how?
- Capacity and performance requirements. The larger the user base, or the greater the volumes of processing expected, the more performance and availability become relevant.
- Availability requirements. Many Solutions support operations for which any stoppage can cause significant problems, or incur significant costs, whether from lost operations, fines and penalties, or other regulatory actions.
Availability, scalability, and performance are all attainable, but at a cost.  In some cases, a very large cost. If these considerations are relevant to this Solution, then now is the time to make these decisions. Basically, to weigh the pros, cons, and costs related to each. The answers to these subjective questions will affect the objective configuration of related platforms.
Basic Configurations
After dealing with the major Components, look to the remaining minor Components. These include things like job schedulers, integration points, and other Related Components. In most cases, these do not drive sizing and performance considerations. As a result, look for opportunities to co-host these Components rather than incurring additional costs for additional platforms.
After considering all the above, place platform icons in the appropriate Domain, Environment, and Infrastructure Tier. If a platform co-hosts physical Components that belong to multiple tiers, then place the icon in the tier to which the most major Component aligns. Thereafter, be consistent in aligning similar platforms co-hosting similar physical Components for other Environments.
At this point, either define the platform's planned basic configuration for platforms which are not yet available or convey the platform's actual basic configuration for platforms which are available. As a result, the Physical Diagrams transition from their use as a planning tool during Solution Definition, to becoming a reference tool during Solution Delivery.
Pre-Production Environment Platforms
Once Architects determine the basic configurations for the Production platforms, they and other platform stakeholders can derive platforms for the remaining Environments, relative to the Production platforms.
Of the non-Production Environments, one is different than the others. Indeed, the Environment through which all changes pass immediately prior to their Production deployment (i.e., pre-Production) should very closely resemble Production itself. That is, any choices for co-hosting, high-availability, and so on, which exist in Production, should also exist in this Environment. Otherwise, there are aspects in Production which testers cannot replicate or validate beforehand.
That said, this Environment's platforms need not be a mirror image of Production. For example, if the Production Environment requires ten (10) Web Server platforms because of the anticipated volume of users, then the pre-Production Environment may use just two (2) or three (3). In other words, it should use at least the minimum number required to enable and validate similar physical Component configurations. Likewise, unless required for NFR testing, then other platforms may also be smaller, such as a Database Server using 4 CPUs rather than 8 (as in Production).
Although, consider NFR Testing as well as where and when it should occur. In some cases, it is best to conduct NFR testing using the Production platforms, prior to the initial Production Release. In other cases, perhaps a Disaster Recovery site which mirrors the Production configuration is available. Alternatively, and most commonly, this pre-Production Environment is the location in which to conduct ongoing NFR testing. If the latter is the case for this Solution, then ensure platform configurations allow for results comparable to Production platforms.
Other Environment Platforms
Aside from Production and pre-Production (typically the QA Environment), all other Environments can be much smaller and less complex. Generally, platforms which offer the minimum configurations to support ongoing development and testing are sufficient. Although, that depends upon the co-hosting of physical Components and the number of Environments each platform will support.
In most cases, the number of Team members using any given Environment, at any given time, to produce and validate changes is significantly smaller than the user community that will eventually consume those changes. Accordingly, the platforms on which the physical Components for those Environments operate can be quite different than their Production counterparts.
In some cases, there may be more platforms using minimal configurations. In others, there may be fewer platforms using heftier configurations, because they are expected to support more than one physical Component and/or Environment. Regardless, the choices here generally reflect trade-offs between costs, flexibility, and other resources. There are no right answers. But there are better and worse.
For instance, consider a Development Domain (DEVL) may include both Development (DEV) & Test (TST) Environments. Moreover, it might include DEV and TST Environments for the:
- Build Release (BLD-DEV, BLD-TST) for ongoing development
- Candidate Release (CDT-DEV, CDT-TST) for defect resolution; and
- Production Release (PRD-DEV, PRD-TST) for break fix work.
This is appropriate because this Domain has the least amount of security and rules around change control.
Basically, Environments which share common attributes often belong in the same Domain. And any Environment(s) within a Domain may have opportunities to share platforms. That is not to say this is always a good idea. Doing so will depend a great deal upon the Solution itself, and the work needed to make it available within the organization. Furthermore, policies of the hosting provider may also affect which platforms are able to do what.
Setting / Updating Platform Values
To conclude, for each platform placed into a Physical Diagram, add its relevant basic configuration info. In most cases, these are values which help define each instance of the given platform. Of course, this info differs depending upon what each platform represents. For example...
Servers / Compute Platforms:
- Label (main physical Component)
- Count of multiple platforms
- Number of CPUs
- Amount of RAM (memory)
- Amount of Disk (storage)
- Host Name and/or IP address
Load Balancers / Firewalls:
- Label (physical Component)
- DNS
- IP