Josh Odgers had another great post over at CloudXC where he talked about the need for architects to think outside the scope of the task in front of them to ensure they were not designing a solution that could cause problems down the road (he has a lot of great example design considerations in addition to this post). This is a great post not just for IT/technology but any project as you have to constantly be thinking about future growth and sustainability in your projects – just because you meet the requirements for a specific task or project in a vacuum doesn’t mean you aren’t hampering future projects. I feel quite blessed to have cut my teeth in technology with a manager and team who had this vision 15 years ago, and is one of the reasons I’m constantly shocked that technology groups today are just figuring out that we are all service providers.
A design consideration for my projects I often incorporate is that of company culture, a very non-technical consideration but one that is important just the same. Some might lump this into business requirements but I feel that it is important to call this out as a separate consideration. You have to understand not only the business and technical requirements of the organization you are designing a solution for, but also their work style, team and culture.
A recently project I was involved in scoping was for a small software services company. They very much had a start-up type culture where many people wore many hats. As their development processes were advancing, they wanted to achieve a more agile process both in their development and release cycles. Knowing the people on the team, their work styles and preferences gave me insight into how to plan and design their infrastructure stack. They were not the type of company who, for the foreseeable future, would need or want to dedicate people to maintaining hardware and infrastructure. Knowing this, as well as their technical needs and business requirements lead me to suggesting a platform built around a hyper-converged solution such as VSAN, ScaleIO, Nutanix or Simplivity.
While other solutions would have certainly worked, and knowing the goals of the company would have supported future technical growth, they were not the right solution for them to support on a day to day basis, or even when they needed to add more capacity; be it compute, network or storage. Get to know the people you are designing solutions for, think out side of technical and business requirements and think about the people requirements for maintaining the solution being put in place to add another layer of depth to your design.
If you are looking to wrap up a VMware certification before the end of the year, here is your chance to save 50%. The following codes are still good so long as you schedule by 9/20 and take your exam by 10/31.
I passed, thought it was blog post worthy so here is the blog post. This is certainly a hard test; the level of knowledge is, well, advanced! The knowledge required goes well beyond VMware settings, check boxes and theory – you are expected to have an advanced (sorry had to do it again) level of knowledge on things such as Disaster Recovery, storage and networking – at least that’s what many of my questions were on.
Preparing for the exam, for me, was a bit of a struggle. There are a lot of great resources from the VMware community for those preparing for the VCAP-DCD with a focus on design such as the #vBrownBags from professionalvmware.com, a list of amazing resources from Gregg Robertson (@GreggRobertson) at his blog (thesaffageek.co.uk), a handy guide from Shane Williford (@coolsport00) which is also available at professionalvmware.com that adds useful resources and notes to the exam blue print and of course a few great courses available at www.trainsignal.com. In my opinion, however, this is not a test you can expect to just study for and pass. The ability to pass the test comes from being hands on with the technology – servers, storage, networking, VMware, etc… and the resources that are available I think are invaluable to those who are coming from an engineering/systems background and want to focus on design. The study guides and examples are certainly excellent in helping you understand the conceptual, logical and physical concepts of the test.
My path was a bit different. For a long time I was positioning my career to move into a CIO/VP level role so I feel like I already had a good understanding of many of the design concepts that the test, and study guides focus on – collecting business requirements, identifying constraints, risks and stake holders and then applying those to design decisions to support the business. Just about a year ago I made a conscious decision to go back to being a geek – hands on, making technology work. Since I was straddling technology and design (well really management but I think they are very similar) already, I hadn’t necessarily had the amount of hands on technical work that I would have preferred to have over the last 5 years.
While there are certainly a number of posts available (such as Gregg’s blog which lists an amazing amount of resources), I will focus on the ones that I used since you could make a career of just studying for the test. In no particular order, with a couple of tips:
Now, don’t freak out (sorry I have seen tangled like 10Million times so this is image burned in my brain), I am not suggesting you need to read each and every line from all of those documents, but you need to be honest with yourself about your strengths and weaknesses. Also keep in mind the #vBrownBag recordings are available via iTunes/RSS (thank you Nick Marshall) and the TrainSignal courses can be downloaded as MP3s so you could always listen during your commute. I received 2 hours of training a day (hour each way) thanks to my commute and the ability to listen on the go.
If you are coming from the engineer/admin side you may have a leg up on the technology side of the test but may need to focus your efforts on understanding design and business need. If you are like me and coming from a design/consulting/management side you probably have to brush up on some of the deeper technology pieces that you may not have to think about often. definitely check out the resources I mentioned above, start to think about the business needs for the technology you are using – why is it needed, what business problem is it solving, focus on documentation and the conceptual, logical to physical considerations and you will be well on your way. Craig I hope this was an awesome-enough blog post.