Showing results for 
Search instead for 
Did you mean: 
Create Post

Infrastructure Design Characteristics

Level 9

IT infrastructure design is a challenging topic. Experience in the industry is an irreplaceable asset to an architect, but closely following that in terms of importance is a solid framework around which to base a design. In my world, this is made clear by looking at design methodology from organizations like VMware. In the VCAP-DCD and VCDX certification path, VMware takes care to instill a methodology in certification candidates, not just the ability to pass an exam.

Three VCDX certification holders (including John Arrasjid who holds the coveted VCDX-001 certificate) recently released a book called IT Architect: Foundation in the Art of Infrastructure Design which serves exactly the same purpose: to give the reader a framework for doing high quality design.

In this post, I’m going to recap the design characteristics that the authors present. This model closely aligns with (not surprisingly) the model found in VMware design material. Nonetheless, I believe it’s applicable to a broader segment of the data center design space than just VMware-centric designs. In a follow-up post, I will also discuss Design Considerations, which relate very closely to the characteristics that follow.

Design Characteristics

Design characteristics are a set of qualities that can help the architect address the different components of a good design. The design characteristics are directly tied to the design considerations which I’ll discuss in the future. By focusing on solutions that can be mapped directly to one (or more) of these five design characteristics and one (or more) of the four considerations that will follow, an architect can be sure that there’s actually a purpose and a justification for a design decision.

It’s dreadfully easy – especially on a large design – to make decisions just because it makes sense at first blush. Unfortunately, things happen in practice that cause design decisions to have to be justified after the fact. And if they’re doing things correctly, an organization will require all design decisions to be justified before doing any work, so this bit is critical.

Here’s the 5 design characteristics proposed by the authors of the book:

Availability – Every business has a certain set of uptime requirements. One of the challenges an architect faces is accurately teasing these out. Once availability requirements are defined, design decisions can be directly mapped to this characteristic.

For example, “We chose such and such storage configuration because in the event of a loss of power to a single rack, the infrastructure will remain online thus meeting the availability requirements.”

Manageability – This characteristic weighs the operational impacts that a design decision will have. A fancy architecture is one thing, but being able to manage it from a day-to-day perspective is another entirely. By mapping design decisions to Manageability, the architect ensures that the system(s) can be sustainably managed with the resources and expertise available to the organization post-implementation.

For example, “We chose X Monitoring Tool over another option Y because we’ll be able to monitor and correlate data from a larger number of systems using Tool X. This creates an operational efficiency as opposed to using Y + Z to accomplish the same thing.”

Performance – As with availability, all systems have performance requirements, whether they’re explicit or implicit. Once the architect has teased out the performance requirements, design decisions can be mapped to supporting these requirements. Here’s a useful quote from the book regarding performance: “Performance measures the amount of useful work accomplished within a specified time with the available resources.”

For example, “We chose an all-flash configuration as opposed to a hybrid configuration because the performance requirements mandate that response time must be less than X milliseconds. Based on our testing and research, we believe an all-flash configuration will be required to achieve this.”

Recoverability – Failure is a given in the data center. Therefore, all good designs take into account the ease and promptness with which the status quo will be restored. How much data loss can be tolerated is also a part of the equation.

For example, “Although a 50 Mbps circuit is sufficient for our replication needs, we’ve chosen to turn up a 100 Mbps circuit so that the additional bandwidth will be available in the event of a failover or restore. This will allow the operation to complete within the timeframe set forth by the Recoverability requirements.”

Security – Lastly - but certainly one of the most relevant today - is Security. Design decisions must be weighed against the impact they’ll have on security requirements. This can often be a tricky balance; while a decision might help improve results with respect to Manageability, it could negatively impact Security.

For example, “We have decided that all users will be required to use two-factor authentication to access their desktops. Although Manageability is impacted by adding this authentication infrastructure, the Security requirements can’t be satisfied without 2FA.”


I believe that although infrastructure design is much an art as it is a science – as the name of the book I’m referencing suggests – leveraging a solid framework or lens through which to evaluate your design can help make sure there aren’t any gaps. What infrastructure design tools have you leveraged to ensure a high quality product?


All good points but I believe it is missing one very important design characteristic - Scalability.

If you can't scale due to growth and support the other 5 characteristics then it all fails.

In fact they all have to support each other. 

It is like the old fire tetrahedron.

You have Oxygen, fuel, heat, and a fourth item the chemical reaction.

In order for this all to work they have to be present in the proper amounts in order to generate a self sustaining reaction.

In todays world, while those 5 design characteristics are valid, it must also be able to scale efficiently.

There are so many excellent thoughts brought forth here--this should be required reading for anyone considering an IT deployment.  And they should be required to be fluent in the topics at least a year before starting any purchases.

But while I won't hold my breath for THAT to happen, I would like to emphasis even more strongly how important it is to integrate security into design WELL before any purchases are made.

ISE and ACI and FireSIGHT are tools that integrate data centers with Access layers, resulting in more secure flows, more granular security access, and the ability to track malicious traffic flows in history through leveraging NetFlow.

It's the future, and it's here now.

Boy, THERE'S the voice of experience talking, and I hope everyone listens to it.

Far too many times have I seen products purchased and dropped on the network, with corporate understanding that they are solely POC, only to discover corporate believes (and expects) these LAN-based L2 solutions will scale to an Enterprise level across WAN's.

Getting rid of them becomes impossible because the focus group that advocated for them has become dependent on them, and no other solution could possibly work--therefore the bad products are grandfathered into the network, bypassing policy and security best practices.

Oh, the humanity!

Level 14

Well said. 

Level 14

Excellent write up.  Me thinks that book would be a worth while purchase.

Touche` Jfrazier​. I noticed that right off the bat. Scalability is as a basic component as all these others.

Scalability & Security... however Security can certainly fall under Manageability right now, are also two very important tenants to Infrastructure Design Characteristics, especially in this day and age of SDN and DevOps. Scalability introduces flexibility which allows for growth and demand. Flexibility in Infra Design, as well as Infra Design mindset, is the impetus to this.

Level 20

I've done some artish design... such as having cable trays above suspended from the ceiling and mounting patch panels on the side... using different colored cables for different networks that are color coded to the patch panel ports.  That's kinda artsy!  Everything was from above to closest patch panel... power, networks, and even air for tools etc.

Level 21

All good points made!  With all of that being said one thing I still like to see is simplicity, as much as can be possible while still meeting all of the other items that have been discussed.  I say that because as technical people sometimes we get carried away with the design and add in unnecessary complexity which always comes back to haunt you down the road.