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
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.
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
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.