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

Infrastructure Design Considerations

Level 9

In my previous post, I reviewed the 5 Infrastructure Characteristics that will be included as a part of a good design. The framework is layed out in the great work IT Architect: Foundations in the Art of Infrastructure Design. In this post, I’m going to continue that theme by outlining the 4 Considerations that will also be a part of that design.

While the Characteristics could also be called “qualities” and can be understood as a list of ways by which the design can be measured or described, Considerations could be viewed as the box that defines the boundaries of the design. Considerations set things like the limits and scope of the design, as well as explain what the architect or design team will need to be true of the environment in order to complete the design.

Design Considerations

I like to think of the four considerations as the four walls that create the box that the design lives in. When I accurately define the four different walls, the design to go inside of it is much easier to construct. There are less “unknowns” and I leave myself less exposed to faults or holes in the design.

Requirements – Although they’re all very important, I would venture to say that Requirements is the most important consideration. “Requirements”is  a list - either identified directly by the customer/business or teased out by the architect – of things that must be true about the delivered infrastructure. Some examples listed in the book are a particular Service Level Agreement metric that must be met (like uptime or performance) or governance or regulatory compliance requirements. Other examples I’ve seen could be usability/manageability requirements dictating how the system(s) will be interfaced with or a requirement that a certain level of redundancy must be maintained. For example, the configuration must allow for N+1, even during maintenance.

Constraints – Constraints are the considerations that determine how much liberty the architect has during the design process. Some projects have very little in the way of constraints, while others are extremely narrow in scope once all of the constraints have been accounted for. Examples of constraints from the book include budgetary constraints or the political/strategic choice to use a certain vendor regardless of other technically possible options. More examples that I’ve seen in the field include environmental considerations like “the environment is frequently dusty and the hardware must be able to tolerate poor environmentals” and human resource constraints like “it must be able to be managed by a staff of two.”

Risks – Risks are the architect’s tool for vetting a design ahead of time and showing the customer/business the potential technical shortcomings of the design imposed by the constraints. It also allows the architect to show the impact of certain possibilities outside the control of either the architect or the business. A technical risk could be that N+1 redundancy actually cannot be maintained during maintenance due to budgetary constraints. In this case, the risk is that a node fails during maintenance and puts the system into a degraded (and vulnerable) state. A risk that is less technical might be something like that the business is located within a few hundred yards of a river and flooding could cause a complete loss of the primary data center. When risks are purposely not mitigated in the design, listing them shows that the architect thought through the scenario, but due to cost, complexity, or some other business justification, the choice has been made to accept the risk.

Assumptions – For lack of a better term, an assumption is a C.Y.A. statement. Listing assumptions in a design shows the customer/business that the architect has identified a certain component of the big picture that will come into play but is not specifically addressed in the design (or is not technical in nature). A fantastic example listed in the book is an assumption that DNS infrastructure is available and functioning. I’m not sure if you’ve tried to do a VMware deployment recently, but pretty much everything beyond ESXi will fail miserably if DNS isn’t properly functioning. Although a design may not include specifications for building a functioning DNS infrastructure, it will certainly be necessary for many deployments. Calling it out here ensures that it is taken care of in advance (or in the worst case, the architect doesn’t look like a goofball when it isn’t available during the install!).

If you work these four Considerations (and the 5 Characteristics I detailed in my previous post) into any design documentation you’re putting together, you’re sure to have a much more impressive design. Also, if you’re interested in working toward design-focused certifications, many of these topics will come into play. Specifically, if VMware certification is of interest to you, VCIX/VCDX work will absolutely involve learning these factors well. Good luck on your future designs!

18 Comments

Speaking as one who is forced to support poor designs, I agree that Requirements is #1. 

But it's something that must be looked at from multiple perspectives.  Fill the customers' needs, but do so by following the requirements for the best practice support models.  Don't build for YOUR test environment, build something that will scale to an Enterprise.

And never waste everyone's time by reinventing the wheel.

I run into health care applications that vendors push on our medical staff, which were designed in a vacuum.  The pretty cosmetics and the slick salespeople convince our staff that this is the right product for their needs.  If they buy it without checking with IS, we may discover that the app won't run in a VM environment.  Or that the app is not L3-aware, which means we can't have workstations in a hospital talking to servers in a remote data center, since the custom workstation or application has no knowledge of routing, no place in which to configure a gateway for the NIC.

This results in moving servers out of the data center and into network rooms--not appropriate, or installing dedicated dark fiber and spanning data center VLAN's out of the data center and into medical facilities--again, inappropriate.

Worse, the customers expect to be able to grow this application across our Enterprise in multiple states.  There's no spanning VLAN's that way, and they aren't happy with the product they purchased.

It's one thing to learn the Requirements of the individual customer.  It's another to do the right thing and make the app Enterprise and Layer 3 compatible.

This extends into needs and limitations for VM and database and multicast and routing and memory and CPU . . .

Don't be that developer whose product people will point out as an example of what NOT to purchase.

MVP
MVP

Agreed requirements are key....reasonable requirements that is.

At some point the requirements need to be scrubbed for what is realistic and what can be accommodated with future enhancements.

Then the final requirements can be approved otherwise they will always come back and say we needed this and you didn't provide it when something goes awry.

Level 17

Requirements are essential... setting a standard, implementing a process to achieve said standard and creating an inspection/review process to ensure that all deliverable's are met.

Nice Read !

Level 14

Agreed that requirements are number one.  Great job verbalizing my thought process when taking on a new project.

pastedImage_0.png

MVP
MVP

Hmm..seems I just recently saw that shirt....

MVP
MVP

Good article.

The tricky thing about requirements is when you get too many people that have in input on what is needed.  For example, you may have federal requirements and state requirements that don't always play nicely with each other.  By abiding with one you may not be compliant with the other.  Then you still have to meet the requirements of the organization which could have probably been met easier if you didn't have the other entities to worry about.

Level 11

Always plan for growth!

Level 13

I have run into this multiple times in the education environment as well.  Faculty and Staff come back from conferences or demos of one sort or another and say we have to have this!  But we run into exactly the things you mention.  Sometimes support is spotty.  Also there is no consideration for training of IT staff on the new product or support of it (manpower, hardware, $$, etc)  Often, we are told to "just give them what they want", even though that is not really a good idea.  In recent years, the upper management didn't want to hear from people that IT was a barrier in any way, even though our interest was in providing what we could with reasonable security and with proper support.

One application a staff department bought without consulting us turned out to be an authentication nightmare, and it put non-public data in an un-certified server in the cloud in what we believed was an un-encrypted format.  But we were not allowed to voice that.

Level 20

I just had two NetApp filers fill up... I wish for once they would buy enough storage to last more than a year or two.

MVP
MVP

Hmmm, sizing requirements, capacity planning, trending..

Level 20

Yeah it's bad news...

MVP
MVP

Sizing is an art and a science.

Part math and part WAG (Wise A** Guess) aka educated or informed estimation.  Temper it with trending analysis and you may stay on top of it.

You can't EVER plan well enough for explosive growth...You may know it is coming but until things start populating you can't ever get a real gauge of it and likely it is

like looking at an iceberg.  Most of it is hidden and  won't make its presence known until an inopportune time.

Level 14

I want one!!!!

In my experiences I have found that Requirements evolve and morph over the life of a project. Gaps widen when there Is no built-in flexibility for expectations during the Design & Development phases. Nonsense like this drove me away from being a PM. While I am not technical like most on here I am a self-admitted control freak and I have my vision of the way things ought to be. To me, a project isn't about deadlines and budgets (I see no PMP in my future), it is about delivering a valuable service to the user community. Terms like: scope, requirements, deadlines, etc. introduce rigidity but do help manage expectations. I seek for the happy medium.

Level 21

ecklerwr1​ don't you have the tools necessary to show the growth and anticipated fill date to the folks with the $$$ so they are purchasing storage in advance?  Also I am sure when things fill up and cause problems there is an unnecessary cost associated with that you could show to help them understand they are saving money by having the proper amount of storage in advance.

You are correct that is is both art and science, we struggle with this as well.  My manager is actually looking at getting us SolarWinds SRM to help with this now that is supports Pure Storage.

Level 20

You're exactly right byrona!  Trying to nickel and dime all the time ends up costing you as Trump would say... "Biggly" in the future!  I'm pricing SRM too right now to also fill in the last bottom layer of the appstack... I will say this though... next to NCM SRM gets pricy fast as you pay by the disk.

Awesome shirt.