This may not be for everyone, but if you’re facilitating NSX design sessions and you haven’t solved these situations by other means, it’s been very evident to me that having separate design sessions may be more effective than “let’s get everyone together” strategies.
I do a fairly large number of NSX designs a year, for a pretty wide client base and regardless of the industry, no two organizations are alike. The vast majority of clients have similar infrastructure, but often times very different functional and operational requirements, both in current and future design goals.
After experiencing this for a number of years and at times, allowing the client to drive who the stakeholders are and who would be contributing, I came to the realization that there really needs to be two key design stakeholders and two separate design groups. Each of the design sessions needs to be performed in order to facilitate the actual business outcomes and to ensure that design features and functional requirements are met.
The infrastructure teams of compute, networking and storage, need physical design meetings for connectivity, capacity and resiliency planning, while the application stakeholders need functional use-case design sessions to determine NSX feature use, options and functional requirements.
Performing functional before physical design is probably the single most important factor in determining the success of your client design and how long the design process will take.
It’s extremely important to have the client spell out any current and future functional use-cases. Each use-case should be documented, with dependencies and requirements, including the outcomes desired. Going through each scenario in detail with each dependency will likely add requirements that were unknown or undiscovered.
As to who should be in each group, the answer is simple, but against many organization’s natural instincts to include everyone in each. Requirements gathering needs to be done without interjection and competition between groups. The vast majority of enterprises have histories of clashes and competing agendas between infrastructure (compute, network, storage) and application owners, developers, and even business units in larger organizations. To avoid these unproductive scenarios, we remove the infrastructure “power players” from the Functional Design Group and then the inverse from the Physical Design Group.
The Functional Design Group should include developer system architects, at least one hands-on technical developer, the application owner or owners, a security architect and security owner, and any business sponsors who are responsible for the intended business outcomes. To support the Functional Design Group, infrastructure should provide a technical engineer from compute, networking and storage, with senior level knowledge of current operations and architecture for their respective domains to answer technical questions on current capabilities and operations only. The business sponsors are the key stakeholders for the Functional Design Group.
The Physical Design Group attendees are the infrastructure architects, a technical engineer from compute, networking and storage, with senior level knowledge of current operations and architecture for their respective domains and the stakeholders for overall infrastructure. The key stakeholders for infrastructure are preferably not the managers from compute, network and storage, but rather an overarching director, technical directors or even a vice-president of infrastructure, if that role exists. In support of the infrastructure team, the application team should provide a senior devops member, a security architect and a technical representative from the application team who are to provide answers on current and future design operations only. Again, we don’t want application “power players” in this group to avoid any historically combative scenarios.
Stakeholders need only attend the first and last of their respective design sessions and workshops to ensure that they’re getting what they asked for in the business outcomes they owe back to the business. Exposing stakeholders to “how the sausage is made” or any design challenges, can affect their confidence in the overall initiative and be counter productive.
Again, these are recommendations only and different engagements and clients will at times call for adjustments to group membership, but again, the idea is to keep the infrastructure teams from telling the application teams “they can’t do that” and the like for the infrastructure groups.
Lesson 1: Keep each design group’s membership weighted so they can express their desires and concerns without conflict. The majority of infrastructure and app teams enjoy defeating each other too much and already have a taste for blood. Be the peacekeeper, the broker, the communicator for the groups and ensure any supporting staff from other groups understand their roles in only providing answers, without adding push-back.
Lesson 2: Don’t try to hold a physical design session first. Even though most infrastructure teams are anxious for their connectivity, capacity and redundancy requirements and options, explain the need for an NSX functional use-case design first and how those NSX functional use-cases will supply the physical design requirements for it. If you start with physical design, you may very likely (WILL) end up redesigning (and rebuilding) it again after the functional use-cases are determined.
It’s not easy to tell infrastruture teams that they can’t start with connectivity and physical design, but everyone will be better off, in the end, once you know what the functional use-case requirements are.
Lastly, always listen to exactly what the client is telling you and don’t make assumptions, ask questions. I had this beaten into my head by Paul Mancuso at VMware, a few years back in a mock NSX design defense and I’ve never forgotten it since. There is probably not more sage advice in regards to requirements gathering, than that one point alone.
