How to introduce Cloud and DevOps in an organisation that is conservative in nature? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 11 months ago.

Improve this question

I am a senior software developer, once also worked for a big consulting house. I have been using various cloud services for many years and DevOps is already in my blood.

Recently I moved into another organization. This organization is very lovely in many ways (that's why I moved), but the IT, its tools and processes, are a bit aged. And the culture is a bit conservative. Basically engineers worked upon commands/requirements from business units, every engineer has clear defined responsibility, and engineers' initiatives were not really encouraged or wanted. Some progressive engineers are not happy about lacking of things such as Git, some business units are not happy about the inagility of the IT. Management saw this and would like a change. I, among other progressive colleagues, were asked to help bring the modern tools / methodologies / processes into my organisation.

Introducing Cloud and DevOps to this org is very different from introducing such things to my ex. clients. In most organizations, it is usually enough to mention some obvious benefits of Cloud / DevOps. My focus at other clients was always execution rather than persuasion. My new org is very, very different. It is not a normal business, it has almost no competition, my peer engineers here worry much less about innovation. For a long while "serving the business units stably" has been the value No.1 in this IT (This is not blame at all. Many of my colleagues here are very diligent. Once a task is defined, they deliver high-quality jobs in the defined context). If one mentions those obvious benefits of modern IT, first peer questions could well be "Well, do our business units really care about these? Do they care how we develop our software? Do they care whether we host our applications on our own server or on an cloud? If the business units don't care, why should we modernize? Why should we learn new techs, learn new tools, and learn new methodologies? We have enough chores to do, we don't have time for those hypes (yes, Cloud and DevOps are often viewed as hypes here)."

I am trying to persuade some of my peers. I have already prepared some example applications, example docker files, some very progressive peers have already been trying out Kubernetes on their private computers and on public clouds. Good examples of code also needs good introduction. My introductory article begins like this:

As the xxxxxxx project launched in xxxxxx, many of us raised good questions such as:

• What is DevOps?
• What is Cloud?
• Do we really need Cloud?
• What organizational impact do DevOps and Cloud have on us?
• How do we approach DevOps and Cloud?

Now let me try to explain.

A brief excursion to the history of development of software engineering during the last 60 years might bring out the rationals behind the current cloud/DevOps movement.

In the acient 1960s to early 1980, software were written with ....

While I am digging into historical literature and constructing a compelling story for my peer engineers, I'd like to humbly ask for your idea of how to introduce Cloud and DevOps (its motivation, essence and roadmap for a conservative org.) under my circumstances. Any suggestion or idea will be highly appreciated.

Please note that I am not asking for opinions about whether we need modern practices such as devops / cloud in my organization. The question is rather: Assume there is a real need, how to approach these given my circumstances?

Best, Nicole

Answer 1

You introduce it by doing it.

Now that it's done it needs support. Who's ready for a new toy?

engineers' initiatives were not really encouraged or wanted

Stop expecting to get rewarded by management for everything. Sometimes you pick up the trash because you're sick of the trash.

Some progressive engineers are not happy about lacking of things such as Git

Get a copy of git. You don't even need a server. Use it locally. Have shared folder? Put a remote repository there. Share it with a buddy who's working on the project who uses git. Use it while getting something done.

some business units are not happy about the in agility of the IT. Management saw this and would like a change. I, among other progressive colleagues, were asked to help bring the modern tools / methodologies / processes into my organisation.

You've got managements blessing. Go do good things.

For a long while "serving the business units stably" has been the value No.1 in this IT.

Fancy way to say don't break things when you change things.

Well, do our business units really care about these? Do they care how we develop our software? Do they care whether we host our applications on our own server or on an cloud?

As you already said, some do.

If the business units don't care, why should we modernize? Why should we learn new techs, learn new tools, and learn new methodologies? We have enough chores to do, we don't have time for those hypes (yes, Cloud and DevOps are often viewed as hypes here).

Same reason you use old tools and old methodologies. Because someone found them useful, used them, and you got stuck maintaining what they made.

There is no one true tech stack. There's just a bunch of tech that happened. So learn them all. Only once you know how to do it the new way are you ready to say the old way is better.

My focus at other clients was always execution rather than persuasion.

Persuasion is the wrong goal. Educate. Create a workforce that can oppose moving a project to the cloud not because it's confusing and new but because they understand exactly why the project shouldn't be in the cloud.