So, let's transition to
talk about this first area in operationalizing and that's people.
I mentioned already that this is often the most difficult area to make transformation.
Processes, we can see business value.
Tooling, we can understand the technology might require it.
But when it comes to people,
we're having to change people's mindsets with the way that they approach not
just their daily work but maybe even the career path that they've chosen.
So, on our agenda for this particular section is to talk about
this question who takes on the role of managing NSX.
We're going to look at some team structures and different makeups.
Some team culture and some mindset.
The roles and responsibilities that we've seen from organizations that have deployed NSX,
and then some learning and education opportunities beyond just what we have here.
So, who takes on this role of NSX?
Well, realistically, the networking and security professionals
that are in IT today should become the experts on NSX,
and there's very good reasons for that.
Particularly, NSX is based on concepts and technology
that require an understanding of networking or an understanding of security.
So, if you take the silos that we have today,
take a virtualization administrator,
they are not as fluent in things like BGP and
OSPF and Packet Walks and ARP request and ARP replies.
There's a lot of things that they just don't do on
a regular basis that would be really new to them.
The networking security engineers have to learn virtualization.
So, while the virtualization administrators might have
trouble understanding some of the concepts of NSX, well,
it's also true that the networking and security folks would have
some problems understanding the concepts that we have inside of virtualization.
Maybe they don't truly understand what a hypervisor does or maybe they don't
understand the abstraction layer that we have with ESXi.
So, there's some different cross training opportunities here for these different silos.
But the shift to virtualization and the shift to software defined networking security,
this is not something that might happen,
this is something that's happening now.
So, it's important that we start to get the people involved
so that we can continue to be successful within the IT organization.
All right, so now let's jump over and we're going to do a light board presentation.
So I've been told that all I have to do is clap and I'll be teleported over.
So, here we go.
Wait I didn't go anywhere.
Hey, I'm up here.
Oh, [inaudible] I was supposed to teleported,
I wasn't supposed to be duplicated.
Jim, it might be a problem man.
I must be the cool cologne. Get this thing done.
All right. So, what we have here is a typical data center architecture.
We've got VMware ESXi as our hypervisor providing compute virtualization.
We've got a physical network infrastructure and we've got our firewalls.
As you can see over the years as the architecture has evolved into something like this,
the colors themselves show that we've got
very clear delineation between what somebody's job role might be.
So, for example, if I was the virtualization person,
my job would encompass everything from here up.
If I was the networking person I would be working down
here in the physical networking space and security is
off here to the side providing all of
the ingress and egress security for the data center.
But what's happening now with NSX is,
NSX is bringing networking up into this layer.
So not just the networking but also the security.
So, what's happening is we're blurring the lines now between who
is supposed to handle which particular tasks,
and to be honest this is not something that
a typical virtualization administrator really wants to add to their workload.
It's really something that's more geared for somebody
who's been managing the physical network,
the constructs, the ideas around switching,
dynamic routing with BGP and OSPF.
Maybe it's packet walks ARP replies, ARP request,
those are skills that are really honed and
are very strong skills among the physical networking folks,
and the same thing is true with security.
When you deal with the way that applications communicate,
the ports and the protocols and the flows of communication between application tiers,
that's really something that's handled by the security team.
So even though we're blurring those lines and abstracting those services now,
it's still very much something where
role-based access control is an important part for the NSX design.
So, we're not suggesting that everybody now gets to handle,
we're not suggesting the networking people are now going to be managing
constructs and components within virtualization piece,
and we're not suggesting that firewall people are going to be
performing the emotions or configuring clusters, managing clusters.
It's simply about understanding,
it's about knowing that if I'm dealing with logical networking from NSX,
I have to have an understanding of these hypervisors.
I have to know the role that they play,
I have to understand the architecture of it and if I'm
the security person and the enforcement point is now being moved into the hypervisor,
I still need to understand the flows and the communication of the different applications,
but now I need to know how to enforce those,
how to create those rules so that that enforcement point can now
make my infrastructure more efficient and ultimately more secure.
All right. So, now that you've had a little bit of a history lesson on how
we got to where we are with regards to these silos within IT,
let's talk a little bit about the psychology of how this is impacting our ability to
create significant change within the people of an IT organization.
So, there's a book that's available,
that I highly recommend it's called Mindset The New Psychology of Success by Carol Dweck.
In this book, Professor Dweck a Stanford PhD,
she defines two different mindsets.
She defines a fixed mindset and she defines a growth mindset.
The book defines the fixed mindset as someone who thinks about intelligence,
abilities, outcomes, personality, character, as fixed traits.
Something that we can't change that's the way that we're born.
On the other hand, the growth mindset
sees intelligence, abilities, outcomes, personality,
and character as something that we can develop,
something that we can exert effort in order to make change.
So, when we look at the comparison of these two different mindsets,
a fixed mindset is one that might avoid challenges or avoid obstacles,
doesn't take criticism or feedback very well,
and is not interested in the success of others.
The growth mindset on the other hand will seek out challenges and overcome obstacles,
they will actually leverage criticism and feedback to make improvements,
and they appreciate the success of others.
They find value in the success of others.
In the book, Professor Dweck talks about something called the natural syndrome,
and it might be something that we see more when we label kids as a natural athlete or we
say girls are naturally good at one thing and boys are naturally good at another.
So, it might not apply directly when we talk about IT organizations,
but the concept of labeling certainly does,
and we just saw that in the light board presentation.
The way that our IT structures have evolved,
we've put ourselves in these boxes and we've put labels onto what we
do that really prevent us from being open to this idea of taking on additional roles,
additional challenges, new technologies.
So the IT culture is impacted by mindset,
it's something that happens internally within the organizations although,
organizationally we could say all the organization has
a growth mindset in the way that it wants to move forward.
But in this case we're talking more about
the internal mindset of the people within the organization.
So having that mindset that says I'm
the VLAN guy or I do all the routing or I'm the security person.
Those silos that we saw in the lightboard,
the idea that we eliminate this ability to go do something else.
I'm not the person that does that right passing the buck onto somebody else
without maybe taking responsibility or accountability for something new,
is a very fixed mindset way to
approach not just what you do every day but your career in general.
So what we need to do,
is we need to foster this growth mindset within the individuals of IT.
We want people to ask questions like "How can I
change the way I work to better support the business?"
So it's important that from a top down approach,
that the sea level is sharing the vision and strategy of the organization,
so that people within IT can understand that and then
think about how they can work better to support that vision,
or maybe how do current processes impact the line of business and or my co-workers in IT?
So rather than just kind of doing your thing
and not thinking about the impact on someone else,
thinking about what can I do to facilitate my coworkers and as we saw in the lightboard,
with the abstractions of networking and security into the hypervisor,
it really becomes that single space where everybody has to operate and understand.
Then finally a growth mindset individual,
might ask a question like what value can I bring to
a more closely aligned team that can drive success for the company?
To as an individual looking to say what can I learn?
What can I study? What certification could I get?
How can I bring more value to the team and ultimately help the organization?
So mindset for change.
Leaders have to be a mindset for change or have to have the change mindset,
to influence behavior and align these new ways of working.
We need people who will catalyze this change,
we need people who will embrace this change.
We need to build a coalition of like-minded change agents.
We look at the current model for IT,
the current mindset again fixed mindset hoarding of scarce resources, owning of assets,
managing assets and costs so we can be a low cost provider,
commending controlling told only what they need to know
and execute without any type of context whatsoever,
and then controlling change and eliminating risk completely.
Whereas the target mindset what we would like to evolve into,
is more of a growth mindset for the sharing of resources,
taking on challenges and experimenting to improve.
So over the past few years I've met with some customers that have
a very fixed mindset when it comes to a new technology,
they're scared of the new technology,
"oh we might fail,
there might be a problem,
there might be something that we have to overcome",
and then there's the organizations that say, "look,
we know that with any new technology there's going to be some type of challenge,
but we know that as an organization,
in order to grow in order to succeed,
then we have to be able to take calculated risks with what we're doing".
The target mindset, we want to deliver a service that
provides value to the business and competitive advantage.
We would like to empower our teams,
we want teams that are self aligned to
the core mission of the organization and have decision-making authority.
Bringing those traditional silos together to make decisions
about a next-generation architecture or a new tool a new technology,
and then finally embracing and driving
continuous or repeated change and managing risks to the right level.
What does this team makeup look like?
We'll stop and think for a moment,
what would the ideal team look like for
your service or your set of applications in your organization?
Maybe it's based on the use case,
maybe it's based on the people that you have in your organization, it could vary.
Ultimately, the cross-functional self service oriented team
with diverse skill sets across technology domains and disciplines,
is going to serve the largest number of customers in the best way.
A self-sufficient team or an autonomous team with decision-making authority,
means that we can do things faster,
we can be more agile,
if we don't have to continue to go to levels above us to ask
questions or ask if we can make design decisions or changes,
then we're able to achieve a more rapid and dynamic infrastructure.
Change agents, leaders and evangelists with a growth mindset are
critical to moving forward and evolving our IT transformation.
Incentivized based on goals of the cross-functional team.
So rather than building incentives for
the networking team or incentives for
the virtualization team or incentives for the security team,
we should build incentives that are service driven where
all of the teams have to participate in order to achieve success.
VMware does offer additional training and
certifications as well as documents for architects,
for engineers and for operators,
so that you can continue to learn more within your respective area.
So here's an example of some IT organization,
some simplified IT structures and if you work for
a company now you can think about which model best looks like your organization,
if you're new to IT then you get an idea of what some different models look like.
In the first model, this is really our functional siloed model,
most organizations operate in this way.
We have compute team,
we have storage team,
we have network team, we have security team.
Now, realistically sense probably VMware infrastructure three,
the compute team and the storage team,
really started working more closely together.
Network still operate it on their own,
security kind of still operate it on their own,
but the compute and storage over the past decade or so have slowly come to work more
closely together because the line wasn't as clear between those two teams.
In model two, it's more of a product or platform
or service-based organizational structure,
where we're defining IT structure on a service or an application and then model three,
is really the hybrid of both of those right?
Take this siloed functional model and
overlay it with this service platform model and now we
get this convoluted complex model for trying to manage IT services and structures.
So, the current model of the culture within
IT is that we communicate mainly within the silos.
There might be some communication across silo
but it's certainly not as much as what happens within the silo.
We have domain-specific, infrastructure-focused carried out by multiple silos.
This is especially true when it comes to things like design, or engineering,
or troubleshooting where the networking team might get something and say,
"Oh, well, maybe it's not us."
and we toss it over the wall to
the virtualization team who then spend some time looking at it,
"Oh, it's not us, let's toss it over the wall to the security team."
So, nobody's really interacting with one another,
they're only communicating within the silo to determine that,
"Hey, it wasn't us."
Right? Of course, the old adage goes that it's, blame the network,
it's always the networking team,
but that's not necessarily the case.
But when don't communicate among these silos,
then we're extending the amount of time it takes to find a resolution to a problem.
The culture today is highly specialized in
a particular technology domain and mostly around physical infrastructure,
like physical routing and switching,
physical security or the physical compute which includes the hypervisor stuff.
Issues and feedback can be hidden and kept within the silo.
There's often concern about blame.
"I don't want to be blamed for a particular problem."
So, if we do solve a problem,
then we don't really tell anybody what it was.
Okay. It's running joke where we might say, "Oh, there's a problem.
Well, blame the network.
Hey, networking guys, there's a problem."
Then all of sudden, the problems fixed, and what did you do?
Nothing. It fixed itself, I guess.
But we want to prevent future mistakes.
Specialists learn together within their technology domain and
discipline and we have local optimization for the infrastructure.
So, if I've been in that historical networking silo,
then most of the education I get, the courses I take,
the certifications I get,
are all focused around networking.
That doesn't support the way that the industry is going.
If you look at the cloud model,
the cloud model doesn't support having
individuals that understand only one particular technology.
If your organization is looking at some type of hybrid cloud,
maybe it's Amazon, maybe it's IBM,
maybe it's any of the other partners that VMware has,
we're going to need individuals that understand multiple cloud architectures.
You might have to be certified in Cisco for
physical networking and VMware for hypervisor,
virtualized networking and security,
and then maybe even an Amazon certification
in order to bring all of these different pieces together to really
create that next generation hybrid cloud environment
that your organization is looking to achieve.
So, that's what brings us to this new model.
Let's focus on customer experience.
Let's focus on adding value.
So, rather than trying to find a solution within the area that we are experts,
let's grow our expertise so that we can
provide solutions that are a better experience and more value.
Members have an area of expertise but should strive to
become more knowledgeable across the full-stack, more of a generalist.
Now, it doesn't mean that you can't have technical depth in a particular area,
but you should also have some technical knowledge across a broader range of technologies.
Continuous learning from incidents,
failures and waste and a focus on improvement in order to prevent future issues.
Then finally, in the new model,
we want end-to-end optimization at the service level through sharing of information,
innovation, practices and skills development.