The Next BriefingsDirect data center
architecture modernization journey interview explores how HP Inc. (HPI)
has rapidly separated and modernized a set of data centers as part of its
splitting off from what has become Hewlett Packard Enterprise (HPE).
We will now learn how HP Inc.
has taken four shared data centers and transitioned to two
agile ones, with higher performance, lower costs, and an obsolescence-resistant
and strategic infrastructure design.
Here to help us define the
data center of the future are Sharon Bottome,
Vice President and Head of Infrastructure Services at HPI, and Piyush Agarwal, Senior
Director of Infrastructure Services, also at HPI. The discussion is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.
Here are some excerpts:
Gardner: We know the story of HP
Inc. splitting off into a separate company from HPE in 2015. Yet, it
remains unusual. Most IT modernization efforts combine -- or at the least replicate
-- data centers. You had to split off and modernize your massive
infrastructures at the same time, and you are still in the process of doing
that.
Sharon, what have been the
guiding principles as you created new IT choices from a combined corporate
legacy?
Bottome: When
the split happened, leadership had to make a lot of decisions around speed and
agility just to get the split done. A new underlying IT infrastructure wasn’t necessarily
the key decision maker for how the split went.
We therefore ended up on shared
infrastructure in four data centers, which then ended up being shared again as HPE
split off assets to Micro Focus and DXC Technology
in 2017. We ended up in a situation of having four data centers with shared
infrastructure across four newly separated companies.
As you can imagine, we have a
different imperative now that we are a new and separate company. HPI is very aggressive
and wants to be very fast and agile. So we really need to continue and finish what
was an initial separation of all of the infrastructure.
Gardner: Is it
fair to say, Piyush, that this has been an unprecedented affair at such scale and
complexity?
Agarwal: Yes,
that is true. If you look at what some of the other organizations and companies
have done, there have been a $5 billion and $10 billion company that have
undertaken such data center transformations. But the old Hewlett-Packard as a
joint company was a $100 billion company, so separating the data centers for a
$100 billion company is a huge effort.
So, yes, companies have done this
in the past, but the amount of time they had -- versus the amount of time we
are seeking to do the separation makes this totally unthinkable. We are still
on that journey.
Gardner: What
is new in 2018 IT that allows you to more aggressively go at something like
this? What has helped you to do this that was not available just a few years
ago?
Bottome:
First, the driver for us is we really want to be independent. We want to truly
transform our services. That means it's much more about the experiences -- and
not just the technology.
We have embarked predominantly
on HPE gear.
We architected the new data centers using the newest technologies, whether it’s
3PAR,
HPE Synergy,
and some of the other hardware. That allows us to take about 800 applications
and 22,000 operating systems instances and migrate those. It's just a huge
undertaking.
Learn How the Future of Hybrid IT Can Be Made Simple
But by using a lot of the new
technology and hardware, we have to then transform our own processes and all
the services to go along with that.
Gardner:
Piyush, what have you learned in terms of the underlying architecture? One of
my favorite sayings is, “Architecture is destiny.”
If you make the right architecture decisions, many other things then fall into
place.
What have you done on an
architectural level that's allowed this to go more smoothly?
Simpler separation solutions
Agarwal: It’s more
about a philosophy than just an architecture, in my view. It goes to the previous
question you asked. Why is it simpler now? Just after the separation, there was
a philosophy around going to public cloud.
Everybody thought that we would save a lot of money by just going to the public
cloud.
But in the last two or three
years, we realized that the total cost of ownership (TCO) in a public cloud –
especially if the applications are not architected for public cloud – means we
are not going to save much. So based on that that epiphany, we said, “Hey, is
it the right time to look at our enterprise data center
and architect it in such a way that it provides cloud-like functionality and still
offers flexibility in terms of how much we pay?”
Having HPE Synergy as the underlying
composable
infrastructure really helps with all of that. Obviously, the newer software-defined
data center (SDDC) architectures are also playing a major role. So
now, where the application is hosted is less of a concern, because -- thanks to
the software-defined architecture and best-fit model -- we may be able to move
the workloads around over time.
Gardner: Where
you are on this journey? How does that extend around the world?
Multicloud, multinational
Bottome: We
are going from four data centers in Texas -- two in Austin and two in Houston –
down to two, one each in Houston and Plano. We are deploying those two with
full resiliency, redundancy, and disaster
recovery.
Gardner: And
how does that play into your global reach? How are you using hybrid IT
to bring these applications to your global workforce?
Bottome: Anyone
who says they are not in a multicloud
environment is certainly fooling themselves. We basically are already in a
multicloud environment. We have many, many platforms in other people’s clouds
in addition to our core data centers. We also have, obviously, our customer
resource management (CRM) as a cloud service, and we are moving our enterprise
resource planning (ERP) into another cloud.
How do we support all of these cloud environments? We have partners along with us. We are very much out-sourced, too.
So it's a multicloud environment
and managing that and changing operations to be able to support that is one of
the things we are doing with this transformation. How do we support all of
these cloud environments? We have partners along with us. We are using managed
service providers (MSPs). We are very much outsourced, too. So it's a journey
with them on learning how to have them all supported across all of these multiple
clouds.
Ticketing transformed
Gardner: You
mentioned management as being so important. Piyush, when it comes to some of
the newer management capabilities we are hearing about – such as HPE OneSphere
-- what have you learned along the journey so far? Do both HPE OneView
and HPE OneSphere play a role as a continuum?
Agarwal: It’s difficult
to get into the technology of OneView versus OneSphere. But the predictive
analytics that every provider uses to support us is remarkably different, even
in just the last five years.
When we were going through
this request for proposal (RFP) process for MSPs for our new data center transformation
and services, every provider was showing us the software and intelligence on
how tickets can be closed -- even before the tickets are generated.
So that’s a huge leap from
what we saw four or five years ago. Back then the cost of play was about being
in a low-cost location because employee costs were 80 percent of the total. But
new automation and intelligence into the ticketing systems is a way to move
forward. That’s what will drive the service efficiencies and cost reductions.
Gardner: Sharon,
as you continue on your transformation journey, are you able to do more for less?
Bottome: This
is actually a great success story for us. In the new data center transformation
and the services transformation RFP that Piyush was mentioning, we actually are
getting $50 million a year in savings every year over five years. That’s
allowed us, obviously, to reinvest that money in other areas. So, yes, it's
been a great success story.
We are transforming a lot of
the services -- not just in the data center. It's also about how our user base
will experience interacting with IT as we move to more of these management
platforms with this transformation.
Gardner: How
will this all help your IT operations people to be more efficient?
IT our way, with our employees
Agarwal: When
we talk about IT services, there is always a pendulum. If you go back 15 or 20
years, there used to be articles about how Solectron moved all
of their IT to IBM.
In 2001, there were so many of those kinds of deals.
But within one to two years
people realized how difficult it was. The success of the businesses depended
not just on IT outsourcing, but in keeping the critical talent to manage the
business expectations and manage the service providers.
Where we are now with HPI, over
the period of the last three years, we have learned how to work in a managed
services environment. What that means is how to get the best out of a supplier but
still maintain the critical knowledge of the environment within our own IT.
Learn How the Future of Hybrid IT Can Be Made Simple
Our own employees can therefore
run the IT tomorrow on some other service provider, if we so choose. It maintains
the healthy mix of relationships between the suppliers and our employees. So,
we haven’t gone too far right or too far left in terms of how the IT should be
run from a service provider perspective.
With this transformation, that
thought process was reinforced. We realized when we began this transformation
process that we didn’t yet have critical mass to run our IT services
internally. Over the period of the last one-and-a-half years, we have gained
that critical mass back.
From an HPI IT operations
team’s perspective, it generates confidence back -- versus having a victim
mentality of, “Oh, it’s a supplier and the suppliers are going to do it,” that
is opposed to having the confidence ourselves to deliver on that accountability
with our own IT employees. They are the ones driving our supplier to do the
transformation, and to do the operations afterward.
Gardner: We
have also seen an increase in automation,
orchestration, and some very powerful tools, many of them data-driven. How have
automation techniques helped you in this process of regaining and keeping
control?
Automation advantages
Agarwal: DevOps
provides, on the one hand, the overall infrastructure, orchestration, and
agility to provision. Being part of the previous Hewlett Packard Company, we
always had the latest and greatest of those tools. We were a testing ground for
those tools. We always relied on automated ways of provisioning, and for quick
provisioning.
If I look at that from a transformation
perspective, we will continue to use those orchestration and provisioning
tools. Our internal cloud is heavily reliant on such cloud service automation (CSA).
For other technologies, we rely on server automation for all of the Linux and
Unix platforms. We always have that mix of quick provisioning.
At the same time, we will continue
to encourage our developers to encompass these infrastructure technologies in
their DevOps models. We are not there yet, where the application tier integrates
with the infrastructure tier to provide a true DevOps model, but I think we are
going to see it in the next one to two years.
Gardner: Is
there a rationalization process for your data? What’s the underlying data transformation
story that’s a subset of the general data center modernization story?
Application
rationalization remains an ongoing exercise for us. In a true sense, we
had 1,200 applications. We are bringing that down to 800. The
application and data center transformations are going in parallel.
Agarwal: Our
CIO was considered one of the most transformative in 2015. There is a Forbes
article on it. As part of 2015 separation, we undertook a couple of
transformation journeys. The data center
transformation was one, but the other one was the application
transformation. Sharon mentioned that for our CRM application, we moved to Microsoft
Dynamics. We are consolidating our ERP.
Application
rationalization (AR) remains an ongoing exercise for us. In a
true sense, we had 1,200 to 1,300 applications. We are trying to bring that
down to 800. Then, there is a further reduction plan over the next two to three
years. Certainly the application and data center transformations are going in
parallel.
But from a data perspective --
looking at data in general or of having data totally segregated from the
applications layer -- I don’t think we are doing that yet.
Where we are in the overall
journey of applications transformation, with the number of applications we
have, in my view, the data and segregation of applications is at a much higher
level of efficiency. Once we have data center transformation and consolidated
applications and reduce those by as many as possible, then we will take a look
at segregating the data layer from the applications layer.
Gardner: When
you do this all properly, what other paybacks do you get? What have been some
of the unexpected benefits?
Getting engaged
Bottome: We
received great financial benefits, as I mentioned. But some of the other areas include
the end-user experience. Whether it’s time-to-fix by improving the experience
of our employees interacting with IT support, we’re seeing efficiencies there
with automation. And we are going to bring a lot more efficiency to our own
teams.
And one of the measurements
that we have internally is an employee satisfaction measure. I found this to be
very interesting. For the infrastructure organization, the IT internal personnel,
their engagement score went up 40 points from before we started this
transformation. You could see that not only are they getting rescaled or
retooled, we make sure we have enough of that expertise in-house, and their
engagement scores went up right along with that. It helped us on keeping our
employees very motivated and engaged.
Gardner: People
like to work with modern technology more than the old stuff, is that not true?
Agarwal: Yes,
for sure. I want to work with the iPhone X not iPhone 7.
Gardner: What
have you learned that you could impart to others? Now, not many others are
going to be doing this reverse separation, modernization, consolidation,
application, rationalization process at the same time -- while keeping the
companies operating.
But what would you tell other
people who are going about application and data center modernization?
Prioritize your partners
Bottome: Pick
your partner carefully. Picking the right partner is very, very important, not
only the technology partner but any of the other partners along the journey
with you, be it application migration or your services partners. Our services
partner is DXC.
And the majority of the data center is built on HPE gear, along with Arista and Brocade.
Also, make sure that you truly
understand all of the other transformations that get impacted by the
transformation you’re on. In all honesty, I’ve had some bumps along the way
because there was so much transformation going on at once. Make sure those dependencies
are fully understood.
Gardner:
Piyush, what have you learned that you would impart to others?
Agarwal: It
goes back to one of the earlier questions. Understand the business drivers in
addition to picking your partners. Know your own level of strength at that
point in time.
Learn How the Future of Hybrid IT Can Be Made Simple
If we had done this a year and
a half ago, the confidence level and our own capability to do it would have been
different. So, picking your partner and having confidence in your own abilities
are both very important.
Bottome: Thank
you, Dana. It was exciting to talk about something that has been a lot of work
but also a lot of satisfaction and an exciting journey.
The next BriefingsDirect cloud deployment strategies interview explores how public cloud adoption is not reaching its potential due to outdated behaviors and persistent dissonance between what businesses can do and will do with cloud strengths.
Many of our ongoing
hybrid IT
and cloud computingdiscussions focus on infrastructure trends that support the evolving hybrid IT continuum.
Today’s focus shifts to behavior -- how individuals and groups, both large and
small, benefit from cloud adoption.
It turns out that a dark side
to cloud points to a lackluster business outcome trend. A large part of the disappointment
has to do with outdated behaviors and persistent dissonance between what line
of business (LOB) practitioners can do and will do with their newfound cloud
strengths.
We’ll now hear from an
observer of worldwide cloud adoption patterns on why making cloud models a
meaningful business benefit rests more with adjusting the wetware than any
other variable.
Gardner: What
is happening now with the adoption of cloud that makes the issue of how people react
such a pressing concern? What’s bringing this to a head now?
Christiansen: Enterprises
are on a cloud
journey. They have begun their investment, they recognize that
agility is a mandate for them, and they want to get those teams rolling. They
have already done that to some degree and extent. They may be moving a few
applications, or they may be doing wholesale shutdowns of data centers. They
are in lots of different phases in adoption situations.
What we are seeing is a lack
of progress with regard to the speed and momentum of the adoption of
applications into public clouds. It’s going a little slower than they’d like.
Gardner: We
have been through many evolutions, generations, and even step-changes in
technology. Most of them have been in a progressive direction. Why are we catching
our heels now?
Christiansen: Cloud
is a completely different modality, Dana. One of the things that we have
learned here is that adoption of infrastructure that can be built from the ground-up
using software is a whole other way of thinking that has never really been the
core bread-and-butter of an infrastructure or a central IT team. So, the
thinking and the process -- the ability to change things on the fly from an
infrastructure point of view -- is just a brand new way of doing things.
And we have had various fits
and starts around technology adoption throughout history, but nothing at this level.
The tool kits available today have completely changed
and redefined how we go about doing this stuff.
Gardner: We
are not just changing a deployment pattern, we are reinventing the concept of
an application. Instead of monolithic applications and systems of record that
people get trained on and line up around, we are decomposing processes into
services that require working across organizational boundaries. The users can also
access data and insights in ways they never had before. So that really is
something quite different. Even the concept of an application is up for grabs.
Christiansen: Well,
think about this. Historically, an application team or a business unit, let’s
say in a bank, said, “Hey, I see an opportunity to reinvent how we do funding
for auto loans.”
We worked with a company that
did this. And historically, they would have had to jump through a bunch of
hoops. They would justify the investment of buying new infrastructure, set up the
various components necessary, maybe landing new hardware in the organization, and
going into the procurement process for all of that. Typically, in the financial
world, it takes months to make that happen.
Today, that same team using a
very small investment can stand up a highly available redundant data center in
less than a day on a public cloud. In less than a day, using a software-defined
framework. And now they can go iterate and test and have very low
risk to see if the marketplace is willing to accept the kind of solution they
want to offer.
And that just blows apart the procedural-based
thinking that we have had up to this point; it just blows it apart. And that
thinking, that way of looking at stuff is foreign to most central IT people. Because
of that emotion, going to the cloud has come in fits and starts. Some people are
doing it really well, but a majority of them are struggling because of the
people issue.
Gardner: It
seems ironic, Robert, because typically when you run into too much of a good
thing, you slap on governance and put in central command and control, and you
throttle it back. But that approach subverts the benefits, too.
How do you find a happy medium?
Or is there such a thing as a happy medium when it comes to moderating and
governing cloud adoption?
Control issues
Christiansen: That’s
where the real rub is, Dana. Let’s give it an analogy. At Cloud
Technology Partners (CTP), we do cloud adoption workshops
where we bring in all the various teams and try to knock down the silos. They get
into these conversations to address exactly what you just said. “How do we put
governance in place without getting in the way of innovation?”
It’s a huge, huge problem,
because the central IT team’s whole job is to protect the brand of the company and
keep the client data safe. They provide the infrastructure necessary for the
teams to go out and do what they need to do.
When you have a structure like
that but supplied by the public clouds like Amazon (AWS), Google, and Microsoft Azure,
you still have the ability to put in a lot of those controls in the software. Before
it was done either manually or at least semi-manually.
The
central IT team's whole job is to protect the brand of the company and
keep the client data safe. They provide the infrastructure necessary for
the teams to go out and do what they need to do.
The challenge is that the central
IT teams are not necessarily set up with the skills to make that happen. They
are not by nature software development people. They are hardware people. They
are rack and stack people. They are people who understand how to stitch this
stuff together -- and they may use some automation. But as a whole it’s never
been their core competency. So therein lies the rub: How do you convert these
teams over to think in that new way?
At the same time, you have the
pressing issue of, “Am I going to automate myself right out of a job?” That’s
the other part, right? That’s the big, 800-pound gorilla sitting in the corner
that no one wants to talk about. How do you deal with that?
Gardner: Are we
talking about private cloud, public cloud, hybrid cloud, hybrid IT -- all the
above when it comes to these trends?
Public perceptions
Christiansen: It’s mostly
public cloud that you see the perceived threats. The public cloud is perceived
as a threat to the current way of doing IT today, if you are an internal IT
person.
Let’s say that you are a
classic compute and management person. You actually split across both storage
and compute, and you are able to manage and handle a lot of those
infrastructure servers and storage solutions for your organization. You may be
part of a team of 50 in a data center or for a couple of data centers. Many of
those classic roles literally go away with a public cloud implementation. You
just don’t need them. So these folks need to pivot or change into new roles or reinvent
themselves.
Let’s say you’re the director
of that group and you happen to be five years away from retirement. This
actually happened to me, by the way. There is no way these folks want to give
up the range right before their retirement. They don’t want to reinvent their
roles just before they’re going to go into their last years.
They literally said to me, “I
am not changing my career this far into it for the sake of a public cloud
reinvention.” They are hunkering down, building up the walls, and slowing the
process. This seems to be an undercurrent in a number of areas where people
just don’t want to change. They don’t want any differences.
Gardner: Just
to play the devil’s advocate, when you hear things around serverless,
when we see more operations automation, when we see artificial intelligence (AI)Ops
use AI and machine
learning (ML) -- it does get sort of scary.
You’re handing over big
decisions within an IT environment on whether to use public or private, some
combination, or multicloud in some combination. These capabilities are coming
into fruition.
Maybe we do need to step back
and ask, “Just because you can do something, should you?” Isn’t that more than
just protecting my career? Isn’t there a need for careful consideration before
we leap into some of these major new trends?
Transform fear into function
Christiansen: Of
course, yeah. It’s a hybrid world. There are applications where it may not make
sense to be in the public cloud. There are legacy applications. There are what
I call centers of gravity that are database-centric; the business runs on them.
Moving them and doing a big lift over to a public cloud platform may not make
financial sense. There is no real benefit to it to make that happen. We are
going to be living between an on-premises and a public cloud environment for
quite some time.
The challenge is that people
want to create a holistic view of all of that. How do I govern it in one view
and under one strategy? And that requires a lot of what you are talking about, being
more cautious going forward.
And that’s a big part of what
we have done at CTP. We help people establish that governance framework, of how
to put automation in place to pull these two worlds together, and to make it
more seamless. How do you network between the two environments? How do you
create low-latency communications between your sources of data and your sources
of truth? Making that happen is what we have been doing for the last five or
six years.
We
help establish that governance framework, of how to put automation in
place to pull these two worlds together, and to make it more seamless.
The challenge we have, Dana,
is that once we have established that -- we call that methodology the Minimum
Viable Cloud (MVC). And after you put all of that structure, rigor,
and security in place -- we still run into the problems of motion and momentum.
Those needed governance frameworks are well-established.
Gardner:
Before we dig into why the cloud adoption inertia still exists, let’s hear more
about CTP. You were acquired by HPE
not that long ago. Tell us about your role and how that fits into HPE.
CTP: A cloud pioneer
Christiansen: CTP was
established in 2010. Originally, we were doing mostly private cloud, OpenStack
stuff, and we did that for about two to three years, up to 2013.
I am one of the first 20
employees. It’s a Boston-based company, and I came over with the intent to
bring more public cloud into the practice. We were seeing a lot of uptick at
the time. I had just come out of another company called Cloud Nation
that I owned. I sold that company; it was an Amazon-based, Citrix-for-rent
company. So imagine, if you would, you swipe a credit card and you get NetScaler,
XenApp
and XenDesktop running on top of AWS way back in 2012 and 2013.
I sold that company, and I
joined CTP. We grew the practice of public cloud on Google, Azure, and AWS over
those years and we became the leading cloud-enabled professional services
organization in the world.
We were purchased by HPE in
October 2017, and my role since that time is to educate, evangelize, and press
deeply into the methodologies for adopting public cloud in a holistic way so it
works well with what people have on-premises. That includes the technologies, economics,
strategies, organizational change, people, security, and establishing a DevOps
practice in the organization. These are all within our world.
We do consultancy and professional
services advisory types of things, but on the same coin, we flip it over, and we
have a very large group of engineers and architects who are excellent on
keyboards. These are the people who actually write software code to help make a
lot of this stuff automated to move people to the public clouds. That’s what we
are doing to this day.
Gardner: We
recognize that cloud adoption is a step-change, not an iteration in the evolution
of computing. This is not going from client/server to web apps and then to N-Tier
architectures. We are bringing services and processes into a company
in a whole new way and refactoring that company. If you don’t, the competition
or a new upstart unicorn company is going to eat your lunch. We certainly have
seen plenty of examples of that.
So what prevents organizations
from both seeing and realizing the cloud potential? Is this a matter of skills?
Is it because everyone is on the cusp of retirement and politically holding
back? What can we identify as the obstacles to overcome to break that inertia?
A whole new ball game
Christiansen: From
my perspective, we are right in the thick of it. CTP has been involved with
many Fortune 500 companies through this process.
The technology is ubiquitous,
meaning that everybody in the marketplace now can own pretty much the same
technology. Dana, this is a really interesting thought. If a team of 10
Stanford graduates can start up a company to disrupt the rental car industry,
which somebody has done, by the way, and they have access to technologies that
were only once reserved for those with hundreds of millions of dollars in IT
budgets, you have all sorts of other issues to deal with, right?
So what’s your competitive
advantage? It’s not access to the technologies. The true competitive advantage
now for any company is the people and how they consume and use the technology
to solve a problem. Before [the IT advantage] was reserved for those who had
access to the technology. That’s gone away. We now have a level playing field.
Anybody with a credit card can spin up a big data solution today – anybody. And
that’s amazing, that’s truly amazing.
For an organization that had
always fallen back on their big iron or infrastructure -- those processes they had
as their competitive advantage -- that now has become a detriment. That’s now
the thing that’s slowing them down. It’s the anchor holding them back, and the
processes around it. That rigidity of people and process locks them into doing
the same thing over and over again. It is a serious obstacle.
Untangle spaghetti systems
Another
major issue came very much as a surprise, Dana. We observed it over the last
couple of years of doing application inventory assessments for people
considering shutting down data centers. They were looking at their applications,
the ones holding the assets of data centers, as not competitive. And they asked,
“Hey, can we shut down a data center and move a lot of it to the public cloud?”
We at CTP were hired to do
what are called application
assessments, economic evaluations. We determine if there is a cost
validation for doing a lift-and-shift [to the public cloud]. And the number-one
obstacle was inventory. The configuration
management data bases (CMDBs), which hold the inventory of where all
the servers are and what’s running on them for these organizations, were wholly
out of date. Many of the CMDBs just didn’t give us an accurate view of it all.
When it came time to
understand what applications were actually running inside the four walls of the
data centers -- nobody really knew. As a matter of fact, nobody really knew
what applications were talking to what applications, or how much data was being
moved back and forth. They were so complex; we would be talking about hundreds,
if not thousands, of applications intertwined with themselves, sharing data
back and forth. And nobody inside organizations understood which applications
were connected to which, how many there were, which ones were important, and
how they worked.
When
it came time to understand what applications were actually running
inside of the four walls of the data centers -- no one really knew.
Nobody knew what applications were talking to what applications, or how
much data was being moved back and forth.
Years of managing that world
has created such a spaghetti mess behind those walls that it’s been
exceptionally difficult for organizations to get their hands around what can be
moved and what can’t. There is great integration within the systems.
The third part of this trifecta
of obstacles to moving to the cloud is, as we mentioned, people not wanting to
change their behaviors. They are locked in to the day-to-day motion of maintaining
those systems and are not really motivated to go beyond that.
Gardner: I can
see why they would find lots of reasons to push off to another day, rather than
get into solving that spaghetti maze of existing data centers. That’s hard
work, it’s very difficult to synthesize that all into new apps and services.
Christiansen: It was
hard enough just virtualizing these systems, never mind trying to pull it all apart.
Gardner: Virtualizing
didn’t solve the larger problem, it just paved the cow paths, gained some
efficiency, reduced poor server utilization -- but you still have that
spaghetti, you still have those processes that can’t be lifted out. And if you
can’t do that, then you are stuck.
Christiansen:
Exactly right.
Gardner: Companies
for many years have faced other issues of entrenchment and incumbency, which can
have many downsides. Many of them have said, “Okay, we are going to create a Skunk
Works, a new division within the company, and create a seed
organization to reinvent ourselves.” And maybe they begin subsuming other
elements of the older company along the way.
Is that what the cloud and
public cloud utilization within IT is doing? Why wouldn’t that proof of concept
(POC) and Skunk Works approach eventually overcome the digital transformation inertia?
Clandestine cloud strategists
Christiansen: That’s
a great question, and I immediately thought of a client who we helped. They
have a separate team that re-wrote or rebuilt an application using serverless on
Amazon. It’s now a fairly significant revenue generator for them,
and they did it almost two and-a-half years ago.
It uses a few cloud servers,
but mostly they rely on the messaging backbones and non-server-based platform-as-a-service
(PaaS) layers of AWS to solve their problem. They are a consumer
credit company and have a lot of customer-facing applications that they generate
revenue from on this new platform.
The team behind the solution educated
themselves. They were forward-thinkers and saw the changes in public cloud.
They received permission from the business unit to break away from the central IT
team’s standard processes, and they completely redefined the whole thing.
The team really knocked it out
of the park. So, high success. They were able to hold it up and tried to extend
that success back into the broader IT group. The IT group, on the other hand,
felt that they wanted more of a multicloud strategy. They weren’t going to have
all their eggs in Amazon. They wanted to give the business units options, of
either going to Amazon, Azure, or Google. They wanted to still have a uniform
plane of compute for on-premises deployments. So they brought in Red Hat’s
OpenShift, and they overlaid that, and built out a [hybrid cloud] platform.
Now, the Red Hat platform, I
personally had had no direct experience, but I had heard good things about it.
I had heard of people who adopted it and saw benefits. This particular
environment though, Dana, the business units themselves rejected it.
The core Amazon team said, “We
are not doing that because we’re skilled in Amazon. We understand it, we’re using
AWS CloudFormation.
We are going to write code to the applications, we are going to use Lambda
whenever we can.” They said, “No, we are not doing that [hybrid and multicloud
platform approach].”
Other groups then said, “Hey,
we’re an Azure shop, and we’re not going to be tied up around Amazon because we
don’t like the Amazon brand.” And all that political stuff arose, they just use
Azure, and decided to go shooting off on their own and did not use the
OpenShift platform because, at the time, the tool stacks were not quite what
they needed to solve their problems.
The company ended up getting a
fractured view. We recommended that they go on an education path, to bring the people
up to speed on what OpenShift could do for them. Unfortunately, they opted not
to do that -- and they are still wrestling with this problem.
CTP and I personally believe that
this was an issue of education, not technology, and not opportunity. They
needed to lean in, sponsor, and train their business units. They needed to
teach the app builders and the app owners on why this was good, the advantages
of doing it, but they never invested the time. They built it and hoped that the
users would come. And now they are dealing with the challenges of the blowback from
that.
Gardner: What
you’re describing, Robert, sounds an awful lot like basic human nature, particularly
with people in different or large groups. So, politics, right? The conundrum is
that when you have a small group of people, you can often get them on board. But
there is a certain cut-off point where the groups are too large, and you lose
control, you lose synergy, and there is no common philosophy. It’s Balkanization;
it’s Europe in 1916.
Christiansen: Yeah,
that is exactly it.
Gardner: Very
difficult hurdles. These are problems that humankind has been dealing with for
tens of thousands of years, if not longer. So, tribalism, politics. How does a
fleet organization learn from what software development has come up with to
combat some of these political issues? I’m thinking of Agile
methodologies, scrums,
and having short bursts, lots of communication, and horizontal rather than command-and-control
structures. Those sorts of things.
Find common ground first
Christiansen: Well,
you nailed it. How you get this done is the question. How do you get some kind
of agility throughout the organization to make this happen? And there are
successes out there, whole organizations, 4,000 or 5,000 or 6,000 people, have
been able to move. And we’ve been involved with them. The best practices that
we see today, Dana, are around allowing the businesses themselves to select the
platforms to go deep on, to get good at.
Let’s say you have a business
unit generating $300 million a year with some service. They have money, they
are paying the IT bill. But they want more control, they want more the
“dev” from the DevOps process.
The
best practices that we see today are around allowing the businesses
themselves to select the cloud platforms to go deep on, to get good at.
... They want the "dev" from the DevOps process.
They are going to provide much
of that on their own, but they still need core common services from central IT team.
This is the most important part. They need the core services, such as identity
and access management, key management, logging and monitoring, and they need
networking. There is a set of core functions that the central team must
provide.
And we help those central
teams to find and govern those services. Then, the business units [have cloud
model choice and freedom as long as they] consume those core services -- the
access and identity process, the key management services, they encrypt what
they are supposed to, and they use the networking functions. They set up
separation of the services appropriately, based on standards. And they use
automation to keep them safe. Automation prevents them from doing silly things,
like leaving unencrypted AWS S3 buckets open to the public Internet, things
like that.
You now have software that
does all of that automation. You can turn those tools on and then it’s like a
playground, a protected playground. You say, “Hey, you can come out into this
playground and do whatever you want, whether it’s on Azure or Google, or on
Amazon or on-premises.”
“Here are the services, and
if you adopt them in this way, then you, as the team, can go deep, you can use Application
programming interface (API) calls, you can use CloudFoundation or Python or
whatever happens to be the scripting language you want to build your
infrastructure with.”
Then you have the ability to
let those teams do what they want. If you notice, what it doesn’t do is overlay
a common PaaS layer, which isolates the hyperscale public cloud provider from
your work. That’s a whole other food fight, religious battle, Dana, around
lock-in and that kind of conversation.
Gardner: Imposing
your will on everyone else doesn’t seem to go over very well.
So what you’re describing,
Robert, is a right-sizing for agility, and fostering a separate-but-equal
approach. As long as you can abstract to the services level, and as long as you
conform to a certain level of compliance for security and governance -- let’s
see who can do it better. And let the best approach to cloud computing win, as
long as your processes end up in the right governance mix.
Development power surges
Christiansen: People
have preferences, right? Come on! There’s been a Linux and .NET battle
since I have been in business. We all have preferences, right? So, how you go
about coding your applications is really about what you like and what you don’t
like. Developers are quirky people. I was a C programmer for 14 years, I get
it.
The last thing you want to do
is completely blow up your routines by taking development back and starting
over with a whole bunch of new languages and tools. Then they’re trying to
figure out how to release code, test code, and build up a continuous
integration/continuous delivery pipeline that is familiar and fast.
These are really powerful
personal stories that have to be addressed. You have to understand that. You
have to understand that the development community now has the power -- they
have the power, not the central IT teams. That shift has occurred. That power
shift is monumental across the ecosystem. You have to pay attention to that.
If the people don’t feel like
they have a choice, they will go around you, which is where the problems are
happening.
Gardner: I
think the power has always been there with the developers inside of their
organizations. But now it’s blown out of the development organization and has
seeped up right into the line of business units.
Christiansen: Oh,
that’s a good point.
Gardner: Your
business strategy needs to consider all the software development issues, and
not just leave them under the covers. We’re probably saying the same thing. I
just see the power of development choice expanding, but I think it’s always
been there.
But that leads to the
question, Robert, of what kind of leadership person can be mindful of a
development culture in an organization, and also understand the line of
business concerns. They must appreciate the C-suite strategies. If you are a
public company, keeping Wall Street happy, and keeping the customer
expectations met because those are always going up nowadays.
It seems to me we are asking
an awful lot of a person or small team that sits at the middle of all of this.
It seems to me that there’s an organizational and a talent management deficit,
or at least something that’s unprecedented.
Tech-business cross-pollination
Christiansen: It
is. It really is. And this brings us to a key piece to our conversation. And
that is the talent enablement. It is now well beyond how we’ve
classically looked at it.
Some really good friends of
mine run learning and development organizations and they have consulting
companies that do talent and organizational change, et cetera. And they are
literally baffled right now at the dramatic shift in what it takes to get teams
to work together.
In the more flexible-thinking
communities of up-and-coming business, a lot of the folks that start businesses
today are technology people. They may end up in the coffee industry or in the
restaurant industry, but these folks know technology. They are not unaware of
what they need to do to use technology.
So, business knowledge and
technology knowledge are mixing together. They are good when they get swirled
together. You can’t live with one and not have the other.
For example, a developer needs
to understand the implications of economics when they write something for cloud
deployment. If they build an application that does not economically work inside
the constructs of the new world, that’s a bad business decision, but it’s in
the hands of the developer.
It’s an interesting thing. We’ve
had that need for developer-empowerment before, but then you had a whole other IT
group put restrictions on them, right? They’d say, “Hey, there’s only so much
hardware you get. That’s it. Make it work.” That’s not the case anymore, right?
We
have created a whole new training track category called Talent
Enablement that CTP and HPE have put together around the actual
consumers of cloud.
At the same time, you now have
an operations person involved with figuring out how to architect for the cloud,
and they may think that the developers do not understand what has to come
together.
We have found that much of an organization’s
delay in rolling this out is because the people who are consuming the cloud are
not ready or knowledgeable enough on how to maximize their investment in cloud.
This is not for the people building up those core services that I talked about,
but for the consumers of the services, the business units.
We are rolling that out later
this year, a full Talent
Enablement track around those new roles.
Gardner: This targets
the people in that line of business, decision-making, planning, and execution
role. It brings them up to speed on what cloud really means, how to consume it.
They can then be in a position of bringing teams together in ways that hadn’t
been possible before. Is that what you are getting at?
Teamwork wins
Christiansen: That’s
exactly right. Let me give you an example. We did this for a telecommunications
company about a year ago. They recognized that they were not going to be able
to roll out their common core services.
The central team had built out
about 12 common core services, and they knew almost immediately that the rest
of the organization, the 11 other lines of business, were not ready to consume them.
They had been asking for it,
but they weren’t ready to actually drive this new Ferrari that they had asked
for. There were more than 5,000 people who needed to be up-skilled on how to
consume the services that a team of about 100 people had put together.
Now, these are not classic technical
services like AWS architecture, security frameworks, or
Access control list (ACL) and Network
ACL (NACL) for networking traffic, or how you connect back and backhaul,
that kind of stuff. None of that.
I’m talking about how to make sure
you don’t get a cloud bill that’s out of whack. How do I make sure that my team
is actually developing in the right way, in a safe way? How do I make sure my
team understands the services we want them to consume so that we can support
it?
It was probably 10 or 12 basic
use domains. The teams simply didn’t understand how to consume the services. So
we helped this organization build a training program to bring up the skills of
these 4,000 to 5,000 people.
Now think about that. That has
to happen in every global Fortune 2000 company where you may only have a
central team of a 100, and maybe 50 cloud people. But they may need to turn over
the services to 1,000 people.
We have a massive, massive,
training, up-skilling, and enablement process that has to happen over the next
several years.
Interarbor Solutions, LLC is committed to protecting the privacy and accuracy of confidential information to the extent possible, subject to provisions of state and federal law. We DO NOT collect any personal information about you when you visit our BriefingsDirect blogs or podcasts. This web site may contain links to other web sites. Some of those web sites may be operated by third parties. We provide the links for your convenience, but we do not review, control, or monitor the privacy practices of web sites operated by others.
Copyright Interarbor Solutions, LLC, 2005-2024. All rights reserved.
