So you are starting on your VCDX journey. Or perhaps you’re thinking about starting it. It is dangerous to go alone, take this.
What is this, exactly you ask? Good question. I have seen a lot of people on Twitter lately trying to get started, so hopefully I can provide some ideas on how to get going. This is different for everyone, but here’s what I took along when I set out (DISCLAIMER: I am not a VCDX, however I have submitted an application and been accepted to the defense phase – UPDATE! I became VCDX-236 in November 2016!).
Of course we need a design to be a design expert. It may not be perfect in its current state, but that’s all part of the process. I hate to break it to you, but chances are you won’t be able to send whatever design you have is. You’re going to make sure that you’ve all of the points within the VCDX Blueprint as part of your submission, so chances are your design will need some sort of modification. My advice would be to pick one you really enjoyed working on. You’re about to become really, really good friends.
Several. For me, nothing quite substitutes paper. I used it to write out outlines, sketch diagrams, map design choices and basically just write things down to sanity check them.
Speaking about diagrams, sometimes you’ll be on a real roll, and it will be killer to stop to draw something out on the computer. I just sketched in the notebook, took a picture, and put the image in my design doc. Then I went back later and drew them in OmniGraffle.
So far I have one notebook filled, another half way there, and a third started. I started with one lined and one unlined for different purposes, but they were mainly for creating the documentation. The third I used to write down random things I learned in the process, because you will learn random things in the process.
I found this to be indispensable. Beyond your main design document, you’re going to do all sorts of other things that a lab is handy for. It’s also handy for testing out setting and configurations as you determine what features of vSphere you’re going to use to design your environment.
I didn’t have a big whiteboard, but I did go out and get myself some nice big paper in the form of a flip chart. This was great for listing things out and putting things together. It was also good to leave a page open reminding me of some key aspects of my submission, such as the design quality (AMPRS/RAMPS).
Eventually, when I started prepping for the defense phase, I went out and got an Amazon special white board sheet that I hung up to practice the design scenario. If you can put a white board in a place you can see it while you go through the process, it may be a good idea to get one up front.
Kind of duh on this one. I suppose there’s no rule against writing your design in calligraphy and sketching your screen shots, but the fact remains you need to send over your design in PDF format. You’ll need a computer to do this.
Your computer is also a great place to store your reference material! Make sure you have several copies of your documentation in different locations. You don’t want your computer to bite the dust, and lose your work now, do you?
There’s a lot of different views out there on templates. Some say absolutely not, others say they are good reference point. Each of my design components started with a blank document that I used to fit my needs. You’re going to become really good at Microsoft Word, or whatever word processing method you choose.
Make sure you figure out how you’re going to outline things, and how you’re going to use different headings and for what purpose. If you’ve never edited Word styles before, this is a great place to start. Also, custom number formats could end up being some of your very best friends, along with Captions.
Don’t neglect your table of contents (or table of figures…or index of tables), and get the formatting right at the beginning so you don’t have to mess around with changing things with a huge amount of content.
Multiple Reams of Paper.
Back to paper. Have I mentioned I still love paper? I ended up printing things out and reading the paper copies as the time to submit was approaching. Along with a nice red pen, this helped me catch lots of little errors, like missing periods and incomplete sentences.
I also recommend having someone else read your material. You may want to hand them a paper copy to mark up as they seem fit (thanks, Mom!). I think I need to go plant a tree after this endeavor.
Books, white papers, etc. Whatever you can get your hands on that pertains to your design. Need a break? Might as well have a nice relaxing read. Derek Seaman has an awesome reading list to get you started.
You’re not alone in this journey. There are a number of VCDXs out there who have been kind enough to document their journey on their blogs. By reading them, you’ll begin to get a feel for what the journey entails, and what you need to do to make it to the end.
As you start working on it, it may take a while to hit your “groove”. This may mean you go back and complete hack and slash complete sections of your document. It is part of the process.
The best advice I can give is don’t be afraid to do this. You will evolve during the process, as will your documentation. Proudly, take a break to re-read what you’ve accomplished so far, and fix it accordingly.
I don’t recommend on whipping through the whole document, then trying to deal with revising it all at once. By the time my submission date was approaching, I had done thorough editing of all the sections within the document, and spent the last few days on formatting and checking for non-technical errors.
The First Sentence.
We’ve all got to get started somewhere. Start by writing a sentence. Then another. Then another. Set aside a couple of hours to just write and do what comes naturally. It may not be the best, it may not even be a part of your final submission, but hey! You just got started!
Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security. She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.