VCDX Mentoring Series with Customer Connect

Since transitioning to a panelist role for the VCDX program almost 3 years ago, I have missed the mentoring aspect. Working with VCDX candidates was very rewarding and a helpful learning experience for me to understand other business project use cases and designs.
I still get VCDX mentoring requests and recommend others in the field who may help. However, there is always a limited amount of time for people to volunteer. Typically mentoring is limited to design reviews, final mocks, and some 1:1 Q&A.

How would a person looking to achieve the VCDX develop the skills to create the design and deliver a presentation in the first place?
Having completed a VCP and maybe one VCAP, there is still a lot to do, and the journey to VCDX can seem confusing.

Over the past couple of months, I have been working with Diane Mayer and Daniela Quesada from the VMware Customer Connect Learning (VCCL), team to help plan a dedicated mentoring webinar series for the VCDX program.

With Karl Childs’s tremendous support, Customer Connect Learning has now teamed up with over 20 VCDX holders to discuss each phase of the VCDX journey in detail.

I joined the VCCL team and Karl Childs alongside the presenters for the first webinar. Each session is recorded and provides technical approaches that a VCDX candidate can use to succeed in their journey.

Common questions such as How to get started? , What makes a good project?, What to submit? , are discussed, but in addition, deep dives into areas such as logical design and risk mitigation are covered.
These deeper areas are often stumbling blocks at the submission and on defense day.

Links to sessions

Thank you again to Diane Mayer, Daniela Quesada & Karl Childs for letting me be help develop the series.

Accepted Risks in Architectural Design

With the introduction of any new business solution, there will be risks associated with a technology or design.
Whether they are specific product constraints, technical knowledge gaps, or budgetary/duration of a rollout, a project risk register can often be forgotten about once the project team has released the solution.

An architect can spend many hours documenting, researching, and considering the logical and physical design decisions for various project areas.

“Some might say that we should never ponder.

On our thoughts today ’cause they hold sway over time.”

Noel Gallagher – 1995

With every decision made, there can be an impact on the design and potentially the solution from a conceptual requirement perspective (i.e., SLA/RPO/RTO, Security, availability) and a potential risk to understand and ensure mitigation to protect the business investment.

Having a systematic approach to enterprise risk management has become one of the most valuable takeaways from my VCDX journey and something I continually seek to improve in my fieldwork.

The specific framework or methodology may vary from project to project; however, the ability to relate technological decisions to business objectives is valuable.   

In times of crisis, for example, with a service-impacting incident, a robust method of risk identification and design review is essential for any IT professional or technologist, not just someone with an architect design focus.   

When faced with a seemingly unfixable problem that potentially costs money/brand reputation for a customer, the fear of not knowing enough of a specific technology can be relentless, especially with the number of integration points and ever-changing approaches in the world today.

The ability to review, address, and mitigate technology areas in an agnostic manner can help calm these thoughts and help move forward within long-running troubleshooting or projects in crisis.

Some Thoughts From the Field & for Certification Efforts.

The business has accepted this risk.

Often this is agreed upon without the overarching understanding of a solution.

As an architect, one objective is to minimize the risk impact of new technology, potentially within the operationalizing phase.  

For example, creating a specific monitoring process.   

Once identified, the risk can potentially be lowered, and the initial manual process developed to automate, notify and correct with minimal service impact. 

Developing a risk-based specific check is different from applying a general cloud monitoring service or creating a new local monitoring product/instance.

The decision impacts another area; we don’t have responsibility for that

(i.e., Networking, Security).

As an architect proposing a solution, the aim is to create a working product that meets requirements and a measurable service definition (i.e., SLA, Performance, Cost optimization, Operational improvement, etc.).

Creating a new service with dependencies on other business areas or impacting existing layers without due diligence or review can be risky in the long term and hard to justify within architecture based certifications such as the VCDX.

It’s out of scope for this project & It will be covered in the next phase.

Conflicting requirements and scope can be challenging within projects.  

A pragmatic view of risk identification and mitigation is essential for this. What is the value of a project being delivered if it is not going to be successfully consumed or operationally reliable? 

Lots of business transformation programs consist of multiple projects, which over time increase as a business matures.  

An error in one project could impact user confidence, create operational issues and hinder the transformation journey.  

Recommended Resources

The Value of a VCDX Documentation Submission

I passed the VCDX certification back in 2016. It was a journey that I felt was very worthwhile.

The process helped me develop skills that I have used every day as a freelance instructor, independent consultant, and, over the past two years, within my current role in the field as an architect for VMware.
Another valuable and re-usable output of the VCDX process, in my opinion, is the documentation submission itself.

The VCDX requires significant investment both from a monetary and time perspective. Also, most certifications have a specific shelf life around the support lifecycle of the product being examined. Is this true for the VCDX?

The VCDX submission phase requires;

  • Architecture design document
  • Installation guide
  • Implementation plan
  • Testing Plan
  • Standard operating procedures.

The completeness and detail required for each document within a VCDX submission may be seen as overwhelming for real-life project needs.

The year is now 2020; nearly 4 years have passed since I finished my VCDX journey. My documentation set and presentation are still as valuable to me as ever.
I think this is a key differentiator between the VCDX and other certifications.

The methodology, approach, and understanding of the appropriate level of detail for each area of a technical project are hidden within the submitted VCDX documentation set.
I personally created my own conceptual and logical styles/icons for my documentation and presentation materials. I now use and update these styles as the technology I work with and types of projects change.

My submission has gradually become my working starting material for all my architectural, presentation, and enablement work. A set of styles for the way I think and develop ideas with others.
Without my VCDX journey, I doubt I would have had such an understanding of the roles each different team has in the project lifecycle, the outputs required at each stage, nor would I have dedicated as much time to creating personalized documentation styles I can use time and time again.

As technologists, we gain experience from each project we work on. We may have good examples of documentation, however not necessarily a cohesive set that illustrates the links between technical and business layers on a single project. The advantage of the VCDX journey experience is the understanding and examples of where gaps can cause problems later ( i.e. Risk management, operational testing, security considerations, project planning approach).

In the field, it is often these gaps that cause the problems and unfortunately, they can occur too late to change without significant impact to a project or product consumption.
Possessing example (peer-reviewed) documentation or an understanding of where to start/what to cover is a great advantage when working with others with limited time to assist.

Although my current role is more design review than creation, I often transition from a whiteboard in the initial phases of project discussions to providing example design material created using the experience and styles I created during my VCDX experience.

The level of detail, and thought process required for the VCDX certification provides the structure I need to quickly form relevant materials to articulate and display design decisions, operational tasks,s or customer requirements/impacts to other professionals.

From a partner or consulting perspective this method of architectural output has become second nature post-VCDX and is valuable for transitioning between pre-sales to post-sales, scoping custom services, and working with teams with a variety of skill sets.

Some thoughts, questions, and tips I have picked up along my VCDX journey.

Should I use some templates and just customize them for my VCDX project?
Although accepted as part of the VCDX submission, it is unlikely a standard project template will cover all areas of the blueprint for a VCDX submission. The amount of reworking required could potentially take a lot of time. I personally recommend creating your own simple style at least for the conceptual and logical phases (ie with diagrams – no vendor symbols, simple shapes with data flow, design illustrations).
These can form part of your custom workflow and toolset post VCDX. The reusable opportunity makes this activity much more justifiable and rewarding.

Is the reusability of a VCDX submission another way of recommending to use boiler-plate designs?
Not at all, every artifact is customized for the project being worked on. The process, logic, and level of detail are the reusable factors. The time it took to create the first set for a VCDX defense is dramatically reduced as an architect gains more experience.

I am working on a joint submission with another candidate. Do I lose some value here? Does it even apply to me?
Although you may be submitting jointly, you will go through the review process in the same manner. Creating a customized, unique slide deck and style may help you understand and position/present the areas your VCDX partner documented. The panel phase of the certification also has soft skills elements, being comfortable with your content and wording is extremely important to showcase your skills on the defense day.

Create a redacted version of your VCDX documentation and use it as an example of work for interviews, and future job discussions.
Having an example project story and detailed example of documentation to discuss with a future employer is extremely useful. The level of explanation and detail from a VCDX submission is great for a body of work, also post VCDX you will be well versed in answering questions and leading an interview type scenario.

As you create a documentation set for any future project, consider creating a corresponding working slide deck at the same time.
I find creating a VCDX panel defense style of presentation for every project I am working on extremely useful for an unexpected Zoom call or an urgent status report. This approach helps provide structure and technical comfort to the team reassuring them that everything is progressing well. The presentation looks so much better online than skimming through a draft document.

How is this relevant to new technologies?
When learning a new technology, I normally use a light touch or abridged version of this VCDX submission process to establish the likely questions, design choices, operational impacts, and example architecture to quickly self enable. This method of working is one of the most valuable by-products of the VCDX journey. Technology is always changing; this way of working enables me to evolve, too.

Guest on the VCDX Podcast

I am a passionate advocate for the VCDX program by VMware. 

The learning journey I followed really helped me professionally.  From a technical perspective I use the process and skills I gained by achieving the VCDX  every day with customers.

Now I work for VMware,  I am very honoured to be part of the VCDX Panel team and have the pleasure of listening to candidates present their designs.  It’s great to see how people think different from a design perspective and how designs can be communicated.

When I started my ever changing VMware Certification journey, I stumbled on a Blog  called – SLOG that provided lots of VMware & VCP advice, reviews etc.   

The  website author, Simon Long went on a VCDX and VMware employee journey himself, although he moved to Datrium before I joined full time at VMware.  I am very happy  to have been asked to join Simon on an episode of his VCDX podcast.

We had a great discussion on “Learning from previous mistakes”.   The podcast episode is available here

Thanks very much Simon,  it was great talking to you on the episode.

Design Webinar #3 recording

The 3rd seminar is the Adventures in design series was held recently.
I had  2 great presenters (Yevs and Rebecca),  both active architects, instructors and VCDX certified.
We discussed everything DR, BC and Back Up, both from a  business and technical architecture point of view.
Although not aimed directly at any particular certification,  it could be useful for the VCAP6-DCD and VCDX certifications.
The recording is available here