Creating a Design Resource Library

Building a design on the shoulders of giants.

When creating a large-scale design, it is important to simplify everything into parts. Parts can be managed, swapped, polished, removed, troubleshooted and analyzed to death. In their most simplistic form, they are like small Lego kits that are easy to build. If the Lego person looks odd, maybe the legs are on backwards, or the head is a replaced with something else. It’s simple to figure out the issue and resolve it.

LEGO-head-explosion-500x352

The difficult part is when you have hundreds of pieces that need to work in tandem and you have to make sure that everything is built in the most reliable and tested way possible. One poorly constructed part could have global ramifications with your project. What may have been a small oversight in a switch config, may cause a major QoS issue later on in deployment. Troubleshooting after the fact is always more difficult and impactful to an environment.

Now what if you had a means to ensure that you are building everything in a “proven practice”, vetted by people that have done it before and know the pitfalls of various configurations. This would surely be the way to reduce build time ensure consistency.

This can be done by means of a Design Resource Library. By first identifying all the various components required for a logical design, you can then start mapping them to a physical design from a catalog that you have created. This catalog could be things such as [Webserver:NginX], [Webserver:Apache], or [NFS-SAN:NetApp-FAS2240], [NFS-SAN:Tintri-T540]. You take the logical component and then you map it to the physical solution.

However, when your building out the solution there are dozens of various configs and possible “right ways” to do it. What you need to do is get a “reference architecture” for that solution and then inventory and classify it. This allows you to ensure that the solution you are designing will work as expected and documented.

When a solution is being categorized, this is how I like to do it. Define the following metadata:

 

1>   The specified solution area (storage, compute, network).

2>   The key thing that the solution is meant to address (i.e.; converged system, high IOPS, high port count, etc.)

3>   Other solutions in other areas that it works well with (i.e.; UCS with NetApp, flash array with VDI)

4>   Reference architectures for various deployment scenarios (Cisco Design Zone is a good example and resource: http://www.cisco.com/c/en/us/solutions/enterprise/design-zone/index.html )

5>   If the solution has been combined with others before and has been deployed successfully, then model that entire reference architecture and catalog it as well. You can re-use it in the future.

6>   Any “gotchas” or known issues, such as the solution not working as expected with a specific firmware version, or no upgrade path to a newer version.

After all of these are noted, then it can be considered a validated building block for your design.

If you decide to create a database for it, here are some short names for fields

Solution Name (SN)

Focus1, Focus2, Focus3 (F1, F2, F3)

Compatible Solutions1, Compatible Solutions2 (CS1, CS2)

Reference architecture (REF)

Larger Reference architecture (LREF)

Known Issue1, Known Issue2 (KI1, KI2)

Solution ID (SID)

Example:

Solution name Cisco UCS B series
Focus1 Manageability
Compatible Solutions1 VMware vSphere 5.1
Reference architecture Cisco UCS B-Series Blade Servers Configuration Guides
Larger Reference architecture FlexPod Data Center with VMware vSphere 5.1
Known Issue1 SD cards not support for boot on firmware before 2.2x
Solution ID 1000489

 

With these metadata details for each building block, you are able to more precisely analyze the interactions and develop a sound model. In medicine, the poor interactions of procedures or drugs are called contraindications.

LEGO6

The same idea can be used for any complex system, whether biological or in IT infrastructure. The benefit of fully understanding building block interactions is that you can more accurately model very complex environments with greater certainty.

In a minimalist form, a resource library is a project related repository where you have whitepapers, reference architecture documents, best practice documents, release notes and personal notes of experience from previous deployments. You review them all and make remarks along the way to aid in the documentation or design of the project.

In its complex form, it is part of a shared document management and workflow system that acts as a design sanity check for each of the block components used. It would be a database with links to the information archive, have project history information, collaboration capabilities, all text from documents indexed and quotable with dynamic links to new versions of the documents.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s