A constraint is something you cannot influence nor change in the data center. Since it is non-changeable it should be documented as a constraint to explain why you might have chosen the design you did. Constraints can be various things, they do not need to be only technical, also processes or people can be a constraint. Since a constraint will massively influence the chosen path of installation and configuration, they should all be documented in a table at the beginning of the design.

Here is a sample constraint table:

This is just an example, there can be various other things and those depend on the organization's processes and operation structures. However, if there is a chance to eliminate a constraint it should be done. Since every constraint might limit your SDDC capabilities.

The documentation of constraints also often helps to get aware of them. Sometimes one might think, that is how it is, or my favorite quote, it has always been like that. Think out of these patterns to identify if some of the constraints are still valid. While eliminating a constraint can sometimes be very difficult (politics, people, processes) it can also be a key factor in making the SDDC successful. So the second part of documenting constraints is, find those which can be eliminated.

Too many constraints can put the whole SDDC at risk since it might end in a non-functioning or non-beneficial state. The third step of getting aware of your constraints is making sure they are not preventing any major SDDC functionality. Data center automation means change and change mean that many tasks or processes need to be revisited if they still make sense in an SDDC environment.

Once all the constraints have been identified let's move on to the next topic.

A limit can be physical or logical and describes a circumstance which can't be simply changed. Limits are often technical, but can also be organizational or process related. An organization which has only one data center has this as a limit. It cannot easily stand up a second data center. While this is a somewhat extreme example, there are many limits which sound easy to solve but are as difficult to resolve as the data center example.

The process for the limits is the same as for the constraints. However, limits and constraints can be related to each other. A constraint can create a limit and vice versa, a limit can be present due to a constraint.

A simple example for that is:

The project has a fixed budget, which is a cost limit and cannot easily overcome.

This creates a constraint describing additional costs cannot be covered. The impact would be to keep the design simple and remove some of the planned integration work.

Here is a sample limits table:

In this table, you will notice that C005: No VM template deployment is actually related to L002: PXE limit on simultaneous OS installs. This is an example how constraints and limits might impact each other. If the constraint would move away, the limit would also be gone at once. This would actually make the platform more comprehensive and capable.

Limits are normally quite hard or impossible to eliminate, except they are related to constraints. Therefore a good design has to acknowledge them and trying to work around them. It is important to have a full understanding of all limits before you start your design, otherwise, you might plan for features and then notice that they cannot be used. It is always easier to be well prepared and aware to create your design around that, than trying to improvise later on without jeopardizing the whole integrity and functionality of the SDDC.

Documenting the limits opens up the same opportunity as documenting constraints. They can be re-visited, discussed and maybe there is already a solution to overcome them in the data center. As with the constraints, the important factor is that based on the documented limits it is much easier to follow up than if there is nothing but guessing.

Even the best and well-prepared design team or SDDC architect needs to be educated guessing sometimes. It is just impossible to be aware of every aspect and every requirement before you create your design. Therefore, as well as with the other two, document your assumptions and their impact. Assumptions can be re-visited any time and corrected whenever possible. However, some of them will only reveal once the data center automation has been set up, or once the first couple of services are running. Therefore, assumptions should not lead to absolute design decisions. They should give you a direction and an idea what might be required. Creating a non-reversible configuration which might limit your later use of the platform should be prevented.

However, assumptions are an important part of the design since they will underline why certain things in the system might be configured as they are. It is important to relate them to design decisions since they will help the reader of your design to understand why you took certain decisions. This makes it much easier to form a sound design and also to defend the configuration if required.

Assumptions can cover all sorts of things, beginning from technical assumptions to process based assumptions or application/service based assumptions. Often assumptions are already a big part of any data center. In a bigger organization, the admin sometimes does not know what will be installed on a VM, so they create those VMs based on assumptions and best practices.

In an automated data center there is a lot which can be assumed: Growth, deployments per day, portal users, services, service requirements, service scalability, resource availability, resource constraints, and so on.

This list could get very long. In order to relate that to a design, it is important to list only relevant assumptions which also have a measurable impact on the design and setup of the SDDC.

Here is a sample assumptions table

While some of these assumptions might sound obvious to you, it is important to understand that in huge projects there is always a chance of misunderstandings. So assumptions can also be used to document soft requirements. If you look at A002, it states that only one department might be using the portal. The design decision, therefore, is to create only one tenant. This saves effort and project time. Also, the decision of creating one tenant is tied to the assumption, which makes it quite easy to understand. Sometimes people change their mind in the middle of a project. This often leads to missed milestones and deadlines. Often there can be a discussion that this change hasn't had any impact on the design. If all the assumptions and therefore the scope is well defined in the beginning, those discussions do not need to happen.

So assumptions are good to keep track with design decisions and also to deliver a valid point why this decision has been taken. Besides of that, they help to guess what impact a change of this assumptions might have on the SDDC implementation/configuration.

Also, all assumptions in this table are linked to specific settings. Those settings can be changed anytime. However, the impact might be configuration/project time as well as costs, but the system is not limited to these configurations. Try always to keep the limiting factor of assumptions and its linked decisions as low as possible. Since assumptions can change rather quickly you might need to re-visit the configuration and adapt it to the new requirements.

While these are some worst-case examples, they are all from real SDDC implementations. A good design is keeping track of these aspects. It is also a good practice to create an ID for each design decision and map it to any of these three descriptions. It will improve the readability and understandability of your design if all decision can be tracked back to a constraint, limit or assumption.