How Bon Jovi Taught Me How to Adapt to the Cloud

When we talk about the shift towards cloud architecture, there are many folks who get worried about what we are saying. One thing to note as we have these discussions is that the shift towards cloud has been happening for some time, and will continue to happen. It isn’t an overnight thing, so you shouldn’t imagine that you have to make an overnight change to adapt. However, let’s take a look at some life lessons I’ve learned along the way.

Bon Jovi Taught Me How to Adapt

Everyone has had to endure some kind of change as we have gone through life. Some adapt better than others, and some honestly don’t have to depending on a number of factors. We all know someone who’s dad still has a hairstyle like Elvis, and hasn’t needed to change because they aren’t faced with a requirement to do so.

Let’s take a look at a great example of how adaptation happens gradually over a career. Our example here is New Jersey band, Bon Jovi. Once a part of the massive hair band revolution that took place in the 1980s, they looked the part and fit in well with what was happening at the time.


We almost want to make fun of it when we see it now, but remember that at the time that they were rising to popularity and moving from clubs to arenas, this was what everybody looked like. And in case you didn’t believe it, take a look at this:


That’s right, they looked just like everybody else.

Why Bon Jovi Chose a Different Path

Bon Jovi did something that we as systems administrators and systems architects need to do. They saw the writing on the wall and they began to adapt their style with a longer term plan to succeed. It isn’t that they abandoned what they were doing, but they faced some adversity over their lack of alignment with the heavier sounding competitors that were living like every year would be 1986.

So as I made a choice not too long ago to dive head first into areas of technology where I was not working with on a daily basis, I had some of what Bon Jovi taught me in mind. For quite some time I had a sort of a dichotomy happening because I was doing significant learning on platforms that I wasn’t getting to use every day. Now many ask why I would do this? Here’s why.

Bridging the Gap

In cycling, we have something that happens regularly. The larger group known as the peloton, rides in a large pack, and at some point a small group of riders make the jump to become what is called an escape group. This group will work extra hard for a short while to make a gap between themselves and the peloton, and then they hope to gradually increase, or maintain that lead.

One of the talents I’ve learned is that even when you can’t make the lead group, you can also make a well timed decision to go solo and bridge the gap. That means that you, and you alone make an incredible effort to ride out of the peloton and latch onto the escape group. This means that you may use massive energy to get there and you may not be the overall winner, but you have the opportunity to be with a group that leads the peloton right to the end of the race.

This is something I do in my every day efforts. I research relentlessly. I try things out that I have limited time to work with. I have a Kanban board that has a backlog that would make most people weep, but I have the same WIP (Work in Progress) limits that anyone else does. The difference is that I choose short sprints to do my work, and I make sure that the things that I am working on are directional and advancing my value as a person, and as an IT resource.

Bon Jovi Bridged the Gap

So here we are many years later, and we can make the references to bands like Bon Jovi because you probably know many songs they’ve done. In fact, you may know songs that they have done in the last few years. Yes, the same band who was touring arenas in 1986 is still doing the same thing today. If you look at how long they were around, they were actually doing bar gigs and small clubs as far back as 1983.


As you can see by the picture, these are the same people who were there before, but they just have some more age changes, and they have changed their style in small ways to adapt to the changing music ecosystem around them. All those bands who made fun of them for being “mainstream” and for not staying with their single-minded methods of delivering the same musical formula over and over, well, those bands are gone. Some are coming back because they are considered “retro” now, but Bon Jovi have had thriving careers all the way through.

Bon Jovi Taught Me the Cloud is Important

I saw the writing on the wall. Among many people I was getting exposed to I saw Cody Bunch was talking about OpenStack, Nick Weaver was creating vCHS with a team of outliers who were making a path forward where none had been marked. I was witnessing the escape group. But these same people who were escaping the peloton, they were a part of the peloton for many years.

So as former systems administrators, how did these outliers make the choice to take the lead? They were the early adopters. Scott Lowe was telling me about VXLAN and stretched clustering which everyone thought was a hobby. That same crowd that didn’t see it as a “current” requirement, didn’t see the future need. I saw that this meant something

This means something...

This means something…

I was surrounded by the same rock stars of the IT industry who were a part of the crowd just like you and I. This was one of the many “Aha!” moments I had that told me that I needed to prepare.

This Journey Has Just Begun

We are always moving. Our environment is always adapting. Slowly, but surely, we are seeing the shift. It is a tectonic shift that is slow and gradual, but every once in a while it causes a massive disruption. I hope that I can help to give people the inspiration to have that “Aha!” moment that leads them to the next step in their learning path and the next step in their career.


Change versus Transformation

While a lot of my day to day activity touches on technology, I always explain what I do to people as working with three things: People, Process and Technology. I always explain it in that order, and with good reason. People and process define how we use technology. Which brings me to what this post is about: Change versus Transformation.

Who Moved My Cheese?

Have you ever heard of the book Who Moved My Cheese? It’s a great book about the effect of change on people. As a rule, most people do not like change. In fact we may even say that they fear change.

In my role at my organization, and among the technology community, I am tasked with bringing new things to people which include processes and technology that is new, or different from what we have today.

Many people see the role of a Systems Architect as a “bringer of change” but with the way that people inherently do not like change, I want to change the way that we view this. We need to put aside the word “change” and look at “transformation”.

What’s the difference?

Change as a word is scary when you look at the definition:


I don’t like the sound of that

If you tell somebody that they are going to be facing change, they do often think of it as replacement, or different. In some cases, it is seen as being replaced which is the real heart of why people fear change. I really enjoy Nick Weaver’s talks on automation because they really highlight where we win on transforming the way that we do our work.

Thus, I like the wording much more when we look at transformation:


While it may be semantics, the truth of the matter is that we have to pitch what we do in Systems Architecture and in business process automation as “transformation” rather than “change”. There will be much better acceptance of new methods if we are able to excite everyone about what we are doing by introducing transformative processes.

Because we’ve always done it that way

I can’t even count the number of times that I’ve been handed the excuse “Because we’ve always done it that way” when I suggest introducing something new, or  transforming a process. Isn’t that the worst excuse you’ve ever heard?! We are constantly given this response when we suggest automation, or modifying methods.

And don’t kid yourselves that this isn’t an excuse. It is not a justification, or a “reason”. It is an outright excuse. As in a total fear of change.

Show by example, not by suggestion

There is one thing that I have learned to do over the years to create better adoption of processes or technology, and that is to introduce a working model. In other words, we need to create a proof of concept and show something in practice rather than laying it out on paper or in a meeting room discussion.

It is a bit of a take off from the old saying “it is easier to get forgiveness than permission” really. By having a practical example of a tool, product, or process, we can let people see it in action and be involved in using it which will ensure that people will have a first hand view of how good the transformative process is. (see…I didn’t say new).


Start Small. Win Big.

Introduce something cool to your organization next week. Make it small. Make it cool. Make it meaningful. But the most important thing that you can do is to positively affect people through transformation. It could be as simple as a script for a small manual process. Transformation comes in many shapes and sizes.

Every step towards transformative thinking is a step closer to automation, orchestration and ultimately to a more effective way to do the thing that you do. Excite yourself about it, and excite the people around you with it. You’d be surprised by how quickly the people around you suddenly have less fear of change.

You’ll find that what start’s as trepidation soon leads to adoption.