VMworld 2015 – SDDC5027 – VCDX Unwrapped

By | December 9, 2015
  • DNA of a VCDX candidate
    • Real-world experience in design, architecting, presenting & implementing solutions
    • Does not ask what needs to be done, they actively seek out solutions when problems present themselves
  • Traits
    • Self-motivated and driven
    • Applies critical thinking
      • Particular customer environment may not fit best practice
    • Organised and methodical
      • Good designs and documentation.  If customer is paying for it, will they be help with the end result?  Process, clear to understand etc.
    • Process oriented
    • Confident and adaptable
    • Innovative and insightful
      • Don’t apply the same things and approach, because it’s the easy approach.
      • Analyse customer requirements – what do they really need to achieve? Maybe slightly different approach to achieve that.
    • Inquisitive and proactive
    • Customer focused
    • Continuous learner
  • Personal and career goals – VCDX highest level
  • Benefits career and development
  • Premier certification of architecture, in terms of VMware solutions
  • Think through all of the different aspects of the design
  • Process and thinking being applied to design, shouldn’t change too much from design to design.
  • Having lots of designs behind you before going for VCDX isn’t necessarily required
  • Defending in front of panel for 2nd time, is subject to change now. May be required.
  • VCDX isn’t a technical test, more about design acumen which is the same across all products
    • Articulate what you are doing and how it met customer requirements
    • Designs can become larger due to customer organically growing, thus making some designs more complex
  • Don’t cut out products that are relevant to the design, otherwise large gaps may appear and catch you out during defence.
  • Don’t throw products in to make it look better
  • Watch your page count, not important. Quality first.
  • Go for whatever path you are most comfortable with. The area you have most experience around talking with customers
  • Specific security requirements and policies in place, can dictate that services need to be laid out in specific way.  Include this in your design (justification etc.)
  • If ‘costs’ impact your design decisions, include this to bring the justification to light
  • Political decisions in design – Challenging debates
    • Decisions can be primarily driven by politics, such as how the organisation is structured, nothing to do with technology.
    • Capture as constraint or explain the situation.
    • Document in VCDX design so panel can understand why you made your decisions
    • Document these internally (for PSO) and also with the customer, to be reviewed and agreed with by customer.  Reference person or team you had discussion with.
      • If customer pushes you into that position, always document it
      • For defence, be able to articulate ‘what you would have done instead’. Options.
    • Decide whether you include these just in your VCDX design and\or the design deliverable for the customer
  • Typical question in defence – If the situation or requirements were different from the customer, what would you have done differently, design wise?
    • Good to capture these different options, as you move through documenting the design
  • ‘Constraint is not a crotch’, forced to do that, and that was that
    • If every design decision is a constraint, then what did you design? All assumptions.
  • 3 day course (invite only for defendants only) – Discussion amongst peers
    • Mock panels at VMUGs – May be better option
  • Majority of consultants more comfortable to customer interaction
    • Have been seen multiple designs. More experience, in different environments, providing broader range of knowledge
    • Works on design from beginning to finish, knows every single bit of the design
    • Guys from customer or support have gone through VCDX process and pass, so the above isn’t a pre-requisite.
    • Don’t have to be a hardened architect, part of it, is understanding the concepts of the certification
    • Support staff generally think more on a technical level than consultants\architects, who consider justification, constraints or requirements etc
  • Mock panels on your defence – To help you articulate the decisions and information
  • Answers in defence, can be white boarded or discussed, whatever is easiest
  • No workloads or assessment with design.  Can make design more generic.
    • Explain decisions around LUN sizing, capacity v IOPs, desktop sizing etc.
  • What would I do if my assumption was wrong?  How would you find out?
  • Consultants can go into customer and ask for IOPs requirements for example, and receive a blank (no idea).  The panel understand this type of scenario.
  • Mitigating risk – Define when workload is no longer suitable for type of storage etc.
  • Real design for customer – Can occur when a design is written up, when implementing, it doesn’t work as planned, and you have to make modifications
  • Panel is there to provide candidate with every chance to succeed – If you can go off track, panel will usually try to bring you back on track
    • Think out loud, so panel can you hear your thought process, to allow direction if needed
  • Size of environment isn’t important – Recommendation of multi-site, but not a requirement
    • Have seen people pass with x8 hosts, 1 site or x2 desktop hosts!!
    • More about interesting requirements & constraints
  • Key – Look at the blueprint, types of criteria, design needs to be meet.
    • No size of design stated.
  • Design needs to meet business critical application requirements etc.
  • Don’t make it needlessly complex
    • Simple and basic doesn’t help either
  • All about thought process, go through design patterns, design decisions, justification, requirements, constraints and risks etc.
    • It’s about a solution that meets a business need.  As part of this, someone has to operate it.  If it’s needlessly complicated, if people can’t operate, it’s going to fall over on the business requirement and unable to keep the solution running
    • Otherwise the solution isn’t fit for purpose
  • Some of the best designs are smaller, but have a lot of interesting constraints, and it’s how the candidate architected around those constraints which is important
  • If you can execute the test plan and validate the solution or one of your design choices, you can be confident in your defence, to defend your design decision, if questioned upon this
    • Being part of the validate\test and implementation stages can help this
  • Installation Guide – Can you take design and implement based on your design specification
  • Operational Guide – Base this on specific or interesting requirements.  Need to specify these.
  • Document if some parts of the design, are architected by someone else.

Leave a Reply