Cisco Blogs


Cisco Blog > Data Center and Cloud

Cisco Validated Designs (CVD) for the Data Center – Your Feedback?

This past week, Thomas Scheibe (Director, Data Center Architecture) had the opportunity to co-present with VMware and NetApp at TechFieldDay on a broad range of Data Center topics.

Thomas is one of the leaders in our Solutions and Strategy Unit (SASU) that is responsible for creating Cisco Validated Designs (CVD).  One of the topics discussed was the recent CVD on Enhanced Secure Multi-Tenancy and Thomas asked, “How many of you are familiar with the depth of technical content in a CVD?

I’m somewhat disappointed to say that the show of hands was less than unanimous. Now this shouldn’t have come as a complete surprise to us, because in the past CVDs were primarily targeted at Network Administrators and the TechFieldDay audience is traditionally more focused on Servers, Storage and Applications. But considering that many of our Data Center solutions are no longer just focused on networking elements, we look at this as an opportunity to create awareness for the Architect and Administrator communities. We also look at it as an opportunity to solicit your input and feedback on how we can better deliver content that will help you design and deploy Data Center solutions that are becoming more complicated as convergence, virtualization, and automation blur the lines between IT organizations.

Before we go any further, I want to provide some background on CVDs. While we are constantly testing our products for different use-cases and levels of interoperability, CVDs take this validation up several levels. The SASU teams are staffed with CCIE’s and experts from multiple disciplines (network, virtualization, security, applications, storage, operations, performance-testing, etc.). These architects work with our largest customers (Service Provider, Enterprise, Government and Commercial), largest ecosystem partners and Cisco IT to translate solution-level requirements into designs that cross multiple technology domains. From there they create flexible and scalable architectures that are put into massive labs around the world. We bring our ecosystem partners into the labs and together we pound on the architecture until everyone is comfortable that it scales, interoperates and will ultimately deliver a great solution for our customers. It’s a grueling process that often takes months and uncovers numerous bugs that wouldn’t have been found if we just designed the solution on paper. At the end of each lab-validation process, the output is a CVD that provides design guidance, configurations, test results, and interoperability statements. The single source of all that work can be found on Cisco Design Zone, with solutions covering almost every area of Data Center delivery, from partners including VMware, Citrix, Microsoft, SAP, Oracle, EMC and NetApp. We hope you’ll have the opportunity to see what’s out there today and hopefully use the guidance to improve your Data Center deployments and operations.

OK, getting back to the original premise of this post…your feedback. Based on some very informal research we know a few things about the CVDs:

1 – Not enough of the non-networking people are aware of them

2 – For those that know about CVDs, many would like to see them in formats which are less “tech manual” and more “HOW TO”.

But what else?

How else can we help you take the knowledge that’s in the CVD and make it more useful, more easily consumable? Should we be augmenting the content with more videos that demo certain aspects (features, interfaces, design concepts)? Would it help for us to create podcasts where the architects discuss the designs, challenges and solutions?

Your feedback is extremely valuable to us, so we welcome your comments, suggestions and ideas. We encourage you to provide them below and we look forward to an active discussion about how we can better deliver Data Center focused technical knowledge to all the groups responsible for keeping the most critical of IT assets running and solving business challenges.

Tags: , , , , , , , , , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

4 Comments.


  1. Without doubt, one of Cisco’s greatest strengths is their documentation, white papers and other technical writing. I’ve been using CVD’s for a long time and find them to be hugely valuable source of information, reference and technical learning. I regularly check to see if new content has been uploaded and have a substantial collection of older material which has been useful many, many times.

    One of my regular criticisms of Cisco competitors is the lack of these documents, they really are market makers and solution drivers with key decision influencers and makers.

    My suggestions:

    - break out the technical overview into a white paper for ‘light’ reading, but keep that overview attached to a CVD that contains the configurations. People sometimes see the configurations and think it’s not the right document for them but the introduction is valuable content it in own right.

    - Make them longer. Sometimes they cut configurations to keep it short but why ? It’s only a PDF file, it doesn’t matter how long it is (but must be well organised).

    - More documentation references to fundamentals. Sometimes the CVDs assume that you know all the technology. It could help to have references to Internetnetwork Technology Guide, or feature references, etc etc for people new to certain technologies. We don’t necessarily know everything.

    Hope this helps.

    greg

       0 likes

  2. Brian Gracely

    Thanks Greg, appreciate the feedback and suggestions. Your blog today also offered some excellent guidance to vendors: “Eleven Rules of Design Documentation” http://etherealmind.com/rules-design-documentation-etherealmind/

       0 likes

  3. The CVD’s are very useful for the engineering teams. There are three areas where I’ve seen the need for more detail, particularly around cloud build outs.

    1) The underlying business assumptions for a CVD. Specially for Cloud Service Providers, the architecture is related to the specific offering and how they’ll be selling and delivering the service.

    For example, a SP selling VM’s a la Amazon architects differently than someone selling managed services.

    2) The on going and surrounding operational model. Again, for cloud providers, the struggle is to figure out how to operate the new business, which means processes, roles and tools.

    Example: You will need an on-going portal and service design function. Plan for that job.

    3) There’s a fair bit of software that needs to surround the technology in the CVD and it’s necessary to create the POC / Reference architecture.

    Example: What of the underlying resources should be surfaced to the customer for visibility and control, and how?

    My view is clouded by newScale’s experience in self-service when we encounter a customer working with a CVD.

       0 likes

  4. I love CVDs and whole heartedly agree with Greg + Rodrigo’s excellent guidance on how to make them better, esp wrt operations, but I would add one thing extra: if a system has been built to build the CVD, then can we get some way to navigate around that system as a showcase?

    e.g. Shannon’s great View/Cisco CVD – if we could see that system, perhaps a model of it, look at the configs, see the end result… it would make it really compelling.

    My one negative observation of CVDs is that they are dangerous in the wrong hands: if people think they are all that one needs to build a system, and these people are out there, then trouble lies ahead (and that isn’t the fault of the CVD author!).

    Great work, Cisco, great work.

       0 likes