Agile Computing Authors: Liz McMillan, Zakia Bouachraoui, Elizabeth White, Pat Romanski, Maria C. Horton

Related Topics: FinTech Journal, Java IoT, Microservices Expo, Linux Containers, Containers Expo Blog, Agile Computing, @CloudExpo, @DevOpsSummit

FinTech Journal: Blog Post

The Journey to Enterprise #DevOps | @DevOpsSummit #IoT #Docker #Microservices

Andi Mann & Bernard Golden discussed such topics as how does DevOps get started and who should lead a DevOps initiative?

The Journey to Enterprise DevOps: Process Change and Other Thorny Issues

Many people recognize DevOps as an enormous benefit - faster application deployment, automated toolchains, support of more granular updates, better cooperation across groups. However, less appreciated is the journey enterprise IT groups need to make to achieve this outcome. The plain fact is that established IT processes reflect a very different set of goals: stability, infrequent change, hands-on administration, and alignment with ITIL. So how does an enterprise IT organization implement change to achieve DevOps outcomes?

Bernard Golden sat down with Andi Mann, VP in the Office of Strategic Solutions at CA Technologies to address this thorny problem in a recent Cloud Luminary Fireside Chat. Andi and Bernard discussed topics such as: How does DevOps get started - top-down or bottom-up? Who should lead a DevOps initiative - Dev or Ops? Common pitfalls encountered in DevOps initiatives, and other considerations.

Below is a recap of the discussion.

About the Guest: Andi Mann is a VP in the Office of the CTO at CA Technologies. Andi is an accomplished digital business executive with extensive global expertise as a strategist, technologist, and communicator. For over 25 years across five continents, Andi has built success with corporations, vendors, governments, and as a leading research analyst.

Andi is a sought-after commentator on business technology in trade and business media, at tradeshows and conferences, on radio, television, webcasts, podcasts, and live events. Andi has been named to Business Insider's Top Thought-Provoking Enterprise Tech Execs and Huffington Post's Top 100 Cloud Computing Experts. He is co-author of the popular handbook, 'Visible Ops - Private Cloud'; and his latest book, 'The Innovative CIO'. He blogs at 'Andi Mann - Übergeek', and tweets as @AndiMann. Visit ca.com/devops for Andi's research.

Defining DevOps - Communication, Integration, Collaboration

Bernard: A good place to start would be how would you define DevOps?...What would you say DevOps is and isn't?

Andi: There's various schools of thought on that, whether the definition even exists. I joke that if you ask five people for a definition of DevOps you'll get ten different responses. For me, I sort of take a classic one, it's in Wikipedia, I think collaboration, communication and integration between development and operations, in order to speed delivery of applications. That's the quote that you can put into the definition in the paper...it's a cultural change, it's a movement, it's a philosophy. I think it's important to understand there's process change. Technology is a part of it. I think it's a very important part, depending on especially the scale. So I think it's the cultural change being driven by culture, process, and technology as well. And in terms of why are you doing it...I don't believe it's just about speed. I say this in some research I do, and certainly talking to my customers. Speed is absolutely important, but quality is a critical drive as well.

So communication, integration, and collaboration at its core is definitely what we're talking about. But there's the desire for speed, for higher quality, using better processes, changing the culture, and driven by technology.

Where Does Culture Fit In?

Bernard: I've gone to a lot of DevOps Days, and one thing you hear a lot is people go, "DevOps is about culture." And I state quite strongly...culture is for yogurt. Saying that somehow the way into DevOps is changing the culture, and then you say, "Well what does that mean?" And they go, "Well, people talking to one another." And to me, if you don't have the right organization, supporting tooling, and critically, measurements and metrics, and motivational reinforcement...all you're going to get is happy people who still aren't getting this working. I mean, this isn't about personal relationships. This is about putting in processes and tooling that enable this kind of speed and quality. Out of that probably comes better relationships, and a culture of working together. But there is no dial that you can go in and say, "Oh let me just change the culture and magic will happen." You have a perspective on that?

Andi: It's interesting right, because CEO's come in and go, "Oh I need to re-establish the culture of this company." And you see it in lots and lots of especially large companies, and it often just doesn't work. Culture is an output, not an input. You can't go into, if you're looking to do the applications faster and with higher quality...you can't go in and say, "I'm just going to go in and change the culture". That's an output. Culture is a result of what you do. It's not something that you do. So, yes it's difficult. I do believe that things like culture, empathy, human communication, I think these are really important methods of changing culture. But I agree with you.

A lot of my customers, my interactions, with DevOps are in larger organizations. Larger traditional, older organizations who have an established culture of you know, somewhere between twenty and a hundred and fifty, two hundred years...You can't just go into a hundred thousand person organization of a hundred and twenty years old and go, "Time to change your culture, and be collaborative." You've got to do things that affect that change. So I agree with you, mate. Changing processes, changing technologies, adding tooling that are going to help that collaboration happen...especially in larger organizations, all to make the processes that are slowing you down. I'm a big believer in that.

What Benefits Does DevOps Deliver?

Bernard: So what kind of benefits (are there) if a company does do a DevOps initiative?

Andi: I did research to start with. On the average we've seen about a twenty percent improvement in a bunch of different metrics. Things like, interestingly enough, business related metrics...revenue, new products and services made available, time to market, that sort of thing. Also internal metrics -- cost of Ops and Dev going down by about twenty. So there's a whole bunch of stuff there. With my customers it does vary, and some of it's actually quite phenomenal. Seeing improvement of around three hundred percent in terms of ability to deliver more product faster. For banking services, being able to release a new mobile app. One customer of mine, they started out with a one star mobile app...rated as garbage basically. How many people want to go onto the app store, see one star and go "Yes, that's my banker, I'm going to use their app". So for them it was a case of using continuous delivery as a method of continued improvement, until they got up to four stars, four and a half stars. Just increasing the ability to find bugs and put quality code into production is very significant.

Another banking customer of mine was looking at a three X increase in bugs found before production. So because of the automated systems, because they had people working together, they had operations teams working with the developers to do diagnosis, performance analysis, and stuff in Pre Prod...they put out a better quality product. And another banking customer of mine, they actually reduced by one third the number of SEV one (severity one) issues with their applications in production, after they got to a certain level of maturity in their DevOps approaches. So...there's a bunch of different stuff that I've seen in my customers. And as I've said, research shows about eight, nine, different factors across the board, all showing around about a twenty percent improvement.

This is why my customers are jumping on this after how long we've been doing DevOps, five years, six years, something like that. You know the unicorns, the Netflixs, Zingas, and Etzies of the world have been on top of it for a long time, and now the enterprises are seeing that success. And my customers are constantly saying, "I want to be the next Google, or I want to be the next Facebook..." Like no, no no. How about you be the next you, but do it at a three hundred percent improvement.

Bernard: You've just outlined the kind of benefits, and frankly we've seen that too...I wouldn't say it's DevOps specific, but DevOps is part of what you get when you use our product (Stackato). It has a sort of an end-to-end consistency, common artifacts, automation. So you sort of (have) a DevOps foundation in it. And we've had customers that say, "We've had a five hundred percent improvement in deployment times. We've had significantly faster releases. We've had significantly more releases." So we see the same kind of benefits.

How Does DevOps Get Started? Top-Down or Bottom-Up?
So we sort of have understood the "why" in a sense that we see these benefits. Let's talk a little bit about the "how". I go to DevOps Days and they're always full of very inspirational examples. But generally the people who are presenting are, I'd call them...individual contributors. Hands on, I did this, and so forth. And often times they're at small companies, startups, something like that. We're interested in enterprises today.

How does DevOps get started in an IT organization? Is it sort of bottom up? Is it actually a grass roots movement that sort of just emerges? Or is it top down directed from the CIO saying, "Here's two hundred and fifty thousand dollars. Go off and set up a prototype POC. Show us what you've got." What's your experience around that?

Andi: Originally it started in small firms from the ground up. It was operators and developers who sort of got together, talked about what they could do to improve, collaborated more...And I think there's still a lot of that going on...What I see with my customers at the traditional larger enterprise though, is sometimes Devs and Ops are very very separated, larger teams, not as easy to establish that communication themselves, more management, more command and control structure. Devs and Ops can do some stuff. They can improve their own workflows, they can start to work, I mean they can certainly call each other up and get the communication and collaboration happening. But in a larger enterprise especially, to make substantial change, I believe you've got to get that top level support. You can drive it from the bottom, but at some point you're going to hit a ceiling, and you've got to get executive and managerial support.

It's funny. I've been to I think three DevOps Days in person now, and one topic that came up at all three of them was, "How do I convince my boss? How do I get executive support? How do I get CEO buy in?" Because the individual practitioners at the DevOps Days, they're doing what they can, but they're hitting that ceiling, and they want to know how to get that buy-in from the top. So, I think it's actually important you get both. You've got to have the individuals committed to that change. But in a larger business at some point you've got to have the Ops manager, Dev manager, QA manager, maybe the infrastructure management, and CIO at some point, I think, has to be supportive, if not driving the change.

Bernard: What do they do to convince high level management?

Andi: There's a bunch of things that my customers do...Talking in your manager's language is a good start. It's the same with all sorts of communication and convincing other people. What's in it for them? And there's real good results. You can show them factual data. You can show them case studies and success stories of how it's worked for other companies and stuff like that. But, not just what's in it for you but what's in it for them.

Understand, what are their goals? What are their manager's goals?...There's two things, right. Can you summarize in one sentence what your corporate goal is for this year? It's amazing how many people don't even know that. And then the other one is, do you know exactly what your manager's MBOs are? What are they bonused on? What's going to give them a big tick box in their performance review this year?

And then just aligning what you're doing with what they want done. It seems pretty obvious right, but it's amazing how many people can not articulate either of those responses. So you're talking about language...talking the language of business. This is research that we did...We commissioned an independent researcher, and they found that the businesses that were most successful were those people that measured their DevOps activity before and after -- so that they could measure improvement in business terms, not technical terms -- things like time to market, product delivery, customer satisfaction, rather than burn-down rates, commit rates, release rates, that sort of stuff. I think both are important. Again, talking in a language that's outside of IT Ops, or outside of Dev, and convincing them that it's good for the business, in business terms, becomes really critical.

...Analyst content, the consultant content that your managers and executives read. You know, a lot of practitioners, they'll look at some of those, especially the big analyst firms and the big consultancy firms, and think it's all a bunch of hooey. But you know what, maybe that's the stuff that's convincing your manager what to do. So you have to start to...walk in their shoes, pick up that research and show them what the people they trust are saying. As you know...DevOps is the big thing you've got to do DevOps. I mean it shouldn't be too hard. There's phenomenal results. But yeah, it's a tough conversation for some people though.

Bernard: So to summarize, what I heard was, one, find out what they're being measured on. Two put it in their language. Three, maybe propose what kinds of improvements they would start to see in their measurements.

Metrics for Success - What Is the Criteria?
You mentioned technical metrics, and you also mentioned business metrics. So...sort of commit rates, or maybe release rates...but also, things like increased revenue...How do you design what metrics you measure or what things you look to? What is the criteria by which you evaluate the success of the initiative?

Andi: It varies from company to company of course. Often it depends on what problem they're trying to solve...Find a problem, fix a problem. Especially for the larger companies, you can't change your entire world in a day. You can't just DevOps the whole of IT. You've got to find the problems that you're trying to solve. So looking at things like waste and constraints, finding the right place to solve a problem, that starts to dictate what you want to measure. So maybe, like the bank I was talking about where their app was only one star. So customer satisfaction, the one star rating is an indicator of customer satisfaction on that app, which a business metric. That's something your Chief Revenue Officer and Chief Marketing Officer are really going to care about. So in their case, it was as simple as that. It was measuring the rating of their product.

...So that's one. A bank in Australia, they just had too many SEV one issues, so that's a reliability or an availability measure...For them it was just literally tracking the number of SEV one issues in the two week period after releasing new code. Again, a pretty straight forward measure. A little bit more IT centric, but again, related to customer satisfaction and ability to do business.

For another customer, cost is important. It was costing them too much to do development, and it was too long. So, time to release and cost of each release. They were able to bring both of those back, so I mean there's a bunch of different metrics. I'm not a big fan of using commit rates and burn-down rates because I think sometimes when you do that sort of thing, you encourage accidental behavior. People will naturally try to reach metrics for the sake of reaching metrics, because let's face it, people get paid to do that. There's an incentive for them to do that. So, you can commit lots of code, but if it's crappy code, that's not a good outcome...

...So I mean there's a bunch of different stuff, but with my customers especially, I'm working with executives who want big picture items. So I tend to work above that commit rate, burn-down rate, features released, that sort of thing. Because ultimately those are a means to an end, and the end is, what is the business result of that.

Does DevOps Require New Tools?
I'd like to turn to the tooling side of things...our product embodies that. We have that kind of automation...And I think that's quite critical, automation, for two reasons. One is it speeds things up, but the other thing is it reliably implies consistent practices. You don't have someone repeatedly, manually configuring components, which is mistake-prone, so you get higher quality from that.

But let's talk about the tooling specifically. I think it's fair to say that most tooling of ten years ago really assumed manual use. So it was a tool that you could use, but somebody would go in and physically do something. So the question is, if you want to get to this automation, does it require...tossing out what you've got and bringing in new tooling, or at least moving to the next generation of those tools?

Andi: I don't want to put too much emphasis on tooling because you've got to have that collaboration and the culture...CA, we're not a cultural change company, we're not a process company. We work with larger SI's to do business process re-engineering...Where we are specialists is on the technology...In very practical terms, implementing certain tooling helps you get there. You're not going to change the culture overnight just by putting in automation tooling.

Let me give you some examples of what CA Technologies does. In the development side, being able to have multiple developers work with the same systems, even almost in conflicts, so using more testing, having simulated virtual environments, using service virtualization, to be able to do parallel testing, and working together through APIs. Instead of building monolithic code, build smaller - what they call microservices - build and define very descriptive, practical APIs, so that you can work on the code in the background but your well defined API stays static. So you can work better with other people, and with other developers to make sure that you're getting that code out fast with higher quality while working with each other in parallel. And being able to test against back-end systems virtually, so you're finding more problems and fixing them before production. Automating that gap between Dev and QA, Dev and Pre Prod, Dev and Prod.

By automating that release cycle, this is the continuous delivery side of DevOps that a lot of people talk about. CA Release Automation is a product that we sell, of course. Being able to automate the whole process of releasing code in production. Integrating with automated provisioning systems, whether it's cloud based or local VMware or Amazon. Automating configuration management. So you've got indempotent systems that are repeatable -- you can build them up and break them down really quickly so you can do more testing. You can pass that pre-defined system and the code that provisions and configures it to Operations, so that you know as a developer, you've created an operable environment. Maybe with operations coming in and helping you create that environment, by building in things like backup tooling, performance management tooling, security agents -- all the other things that make it an operable environment. So it's really mobile, you can lift and shift, with a container for example, in a full Platform as a Service - the sort of thing that ActiveState is doing, being able to lift and shift that entire environment from one Dev environment into Pre Prod, into SQA.

Being able to do shared monitoring and management of that environment too. If DevOps is about collaboration, then developers need to be able to do monitoring of things like performance, security, penetration, reliability, uptime. So, again this is something that CA technologies does: providing application performance monitoring, that Devs can use as much as Ops. And once you start doing that...sharing these technologies actually creates common language.

I'll give you a real example. In National Australia bank, they started their DevOps journey by implementing CA APM as a common monitoring tool for application performance that Operations and Development shared. Primarily that was for Operations at that time. But then, when problems happened, and problems always happen, the developers, when they got called for support, all of a sudden they're looking at exactly the same screen as the Operations team. They're able to point to things and talk about the same artifacts. They're able to communicate in the same language, and all of a sudden there, it's not Devs are from Mars, Ops are from Venus. All of a sudden it's both teams using the same languages, talking to each other. This is the communication and collaboration and integration of DevOps writ large in a technology tool.

So it's interesting how we talked about culturally, how do you make that happen. Actually one way you can help that change is by implementing the right automation and the right tooling. And I agree with you Bernard, I think it's absolutely critical to have the automation, but you can't just do silos of automation. That's not a DevOps approach. Doing the shared automation is important.

Does DevOps Mean Discarding ITIL?
What you've outlined is very automated processes, consistent artifacts. I would say that also requires automated policy enforcement...Let's talk about ITIL, because ITIL has really had a powerful influence in enterprises. And I would say that a part of the interest for it was, in the past you would have people who would say, "I'm just going to go and make this little change to the production system. I know it will be okay." And then all of a sudden everything crashed. So it was sort of designed to prevent that. The way it did it, I would say, was a very structured process that was typically quite manual. The classic example is the change control board...Somebody says, "I want to make a change" and you say, "We're going to have a bi-weekly meeting where we'll consider all changes"...

I think change control boards and this view of the world that we're moving toward are not very compatible. So, in your view, does DevOps mean discarding ITIL, and if so, what does that mean?

Andi: It's a bit of a four letter word in the DevOps circles, that's for sure. Look, there's a lot of perception that ITIL is the olden bastard, and DevOps is the new hotness, right? And to an extent that's true. Change approval board, gee, if my customers could get a CAB running bi-weekly, I think they'd be very happy. You're lucky if you got a CAB meeting monthly, maybe even quarterly in some of the organizations I work with. It's a roadblock...

But this is the thing...DevOps doesn't start with Dev and doesn't end with Ops. There's a lot of process that goes into delivering that application. You mentioned planning, PMO office, stuff like that, change approval board maybe...The thing about ITIL, is pick the bits of ITIL that make your business better. A slavish approach to every single part of ITIL isn't really going to be the answer for any given business. You've got to find what makes you better. And so ITIL is very much process definition. It's very prescriptive. There's some really good ideas in ITIL. I don't believe those good ideas all of a sudden became bad just because we found ways to work better together and deliver software. Things like having approval gates. Sometimes that's actually important, especially for mission critical systems, online banking systems, for example, healthcare systems. We do a lot of work with your government, so citizens services, defense services, healthcare.

Sometimes stuff is actually life and death. And leaving the decision to implement new code into an embedded device in a hospital, sometimes your operator and developer need to approve that. And I'm okay with that. So things like service delivery is really still important to that process. Think about service support. Where in DevOps does the help desk fit? Where does service desk fit? It should fit. It's part of the feedback loop, right? But Dev and Ops, neither of those teams in a large enterprise necessarily do that service support. There's a third group often called Support, and they funnel questions back into those other teams. So service support becomes an important part of DevOps. So you've got project management, and project planning, and portfolio management at the top end. Where am I investing my money to do development enhancement of existing features, existing software? At the bottom end you've got the service support side, feeding back into the planning process, and the bug fixers and patchers and so forth, even just doing workarounds. But you've got to modify all of that to achieve the agility. You can't have a monthly CAB preventing you from doing continuous delivery.

There's a lot of good work done on this, by the way. One of my team did a presentation at DevOps Days. I think it was Austin a year or so ago, on "ITIL invented DevOps", which is really interesting if you look at ITIL and what DevOps is doing, there's a lot of actual parallels and antecedents.

But, things like having approval gates, doing it a little bit more sensibly. When there's a small change that goes into production, maybe you don't need to go through the CAB every time. Maybe if it's a really important change, then you do. So starting to assign to each development and each story, things like risk level, you can start to think in high risk, low risk, high probability, low probability, basic risk analysis, risk management. And depending on what the risk is, you know what? Maybe you don't release it into production automatically, continuously. Maybe you do actually go to a third party of some kind to get some sort of gating approval if it's a high risk change.

I think DevOps and ITIL are absolutely compatible. I think both have to flex a little bit. You've got to be pragmatic about this stuff, Bernard. I don't think dogma helps you do much business...You've got to be pragmatic. Do what's good for the business. And some ITIL processes are going to help you, some are going to hurt you. Pick the ones that make your business better. But don't throw the whole lot out.

The Right People for the Job - New or Existing Staff?
So we've talked about tooling, we've talked about process. I'd like to talk about people now, the triumvirate of things traditionally. As I said, the previous generation of tools assumed manual stuff. So you had sort of a smart person who would...sit down and go, okay, I'm going to install this thing...Automation, I would say, is a meta skill in the sense that you're building a system to do that automatically. It requires a new set of skills...And so the question is, buy or build? Do you have to go out and recruit a new set of people...Or do you look to your existing staff? Do you have any take on that or what you see most organizations do?

Andi: This is a really challenging question, especially for a larger enterprise...I was working in the UK, with a recruiter out there, and we talk about unicorns and horses in DevOps. He was saying the real unicorns are the gun programmers who want to do this and can make these changes. The ability to get these top developers who are willing to make these changes, and do things different ways and implement new tooling...These are rare skills. I think DICE did a survey - as soon as you put DevOps in a title, or in a skill set, then all of a sudden your salary goes up by thirty percent. And meanwhile, think about things like government, or large insurance, banking, trying to compete for top talent with Silicon Valley - with Netflixs and Zingas and Twitters.

At CA Technologies we're constantly looking for top talent. We opened up a new office in Santa Clara mainly so we could tap into that talent pool - because we're doing DevOps too, by the way. We're starting to operate our own software, deliver the SaaS model. So it's important to use that we get this top DevOps talent as well. But again, we're a thirty seven year old company. We got a lot going for us, but it's hard at least reputationally, to compete with these new startups, two years old, three years old. Reputation for a more agile versus a big bank or government reputation for being very constrained. So, there's not enough of that level of talent that you can hire it in. Which means you've got to use your own people. You've got to train your own people. You might get one or two people in who've already done DevOps...that can have the skills, and the insight, the experience to be able to bring that change to your organization, and act as change agents. But there's just not enough of them to go around yet, at least.

And part of the conversation I was having yesterday in fact was the idea that DevOps in its early days required a lot of expertise and expert people. Over time we will productize this concept. It means that average staff will be able to take this concept on a lot more easily because it's a solved problem. What we're doing right now is still solving the problem. So for every organization, I think DevOps gets adopted differently. And so you've got to have creative people who are willing to look for new solutions and work with other people in new ways.

Honestly, not everyone does that. There's a lot of people, especially in larger enterprises, who've been there twenty, thirty, forty years, they do the things they do because that's the way they do them. They're not looking to change. That's a tough staffing question to answer. So, sometimes you've got to give them a short, sharp, shock. Bring in some radical new technology and say, "You know what, from now on you're going to use that." That's an approach that CIO I was talking to yesterday has actually used. So, brought in, one of these transformative new technologies, and said, "You know what, that old stuff, you're not using that anymore. And I don't care if you know how to use that new stuff or not, you will learn. Here it is." So that's maybe one approach.

But you've got to train your own staff, get them working. They're valuable people too. They know your applications, they know your business, they know what connects to what. They know who to talk to when they've got a problem with something that they need solved. So you can't just all out change and bring in new people. I think that's a recipe for disaster.

But getting consultants who have got the experience to work with you - I know we did research just recently again, that showed about sixty percent of enterprises looking to adopt a DevOps approach are planning to engage a consultant to help them. So that's one way. Hiring in someone with the experience and knowledge to do knowledge transfer and instill cultural change is another way. Straight up training your own people. Send your practitioners to DevOps Days. Talk to people like you and me. Talk to vendors. Talk to consultants. Train them up. You've got to do a sort of all of the above approach.

Common Pitfalls Encountered in DevOps Initiatives
That's a very good lead into our next and, probably our final question. What are the common pitfalls encountered in DevOps initiatives?...What kinds of issues do you see organizations confront, successfully or unsuccessfully?

Andi: I think first and foremost in the organizations I work with is, a lack of executive support. And it's something we talk about, certainly when working with our customers all the time across every project. If you don't have executive support, then you're really barking up the wrong tree. You can certainly help to get that executive support. Things like, a lot the time Development wants to get this going, and they'll get push back from Operations. Operations will be saying, "You can't release ten times a day because that impacts stability, which for me impacts reliability." There's also the fear of losing your job. Actually, I'll admit, I thought that was part of the goal when I first started to look at DevOps. I thought, "Oh it's Devs taking over Ops jobs." I had an almost visceral reaction to that. I'm a former operator myself...

But that's not the case either, so again, communicate and collaborate about what this actually means. This means they'll be able to do more, do it better, to especially for operations, to get rid of some of that grunt work of provisioning and configuration, which is, once you've done it a couple of dozen times, let me tell you, it gets pretty dull to provision and configure exactly the same environment over, and over, and over, again. But there's a lot more...Sitting, pouring over spreadsheets, trying to do a capacity plan for a new application, rather than using automated feedback from performance management into capacity planning tools.

Convincing the operations team to do it: A. Get executive support to make sure the operations team know this is critical to the business. B. Let them know what's in it for them. Like I said before, walk in their moccasins. Let them know it's about being able to do more smart work, architectural design, product design, rather than just rack and stack provision, configure. There's also just budgets, right.

At the core of DevOps, if it's about collaboration and communication, it's really not very costly. You might have to spend money to buy a pizza that two teams can share, right. But, if you want to do it to get really significant results, like you said, there's automation involved which means software, which means in a lot of cases purchasing. And there's a lot of open source in the DevOps community and the DevOps tool chain. You know what, open source is not free either. There's other costs associated: support costs, training costs, whatever it might be...So if you don't budget for some of it, that's going to slip you up.

Trying to do too much is another huge issue...Especially someone like my customers, they want to get results very quickly. You can't do an eighteen month delivery of anything...That's not going to fly. They're looking for immediate results. So you've got to pick and choose what to do. Find a problem, fix a problem, and show the results...You're showing executives, you're showing managers, hey this is actually working, we're doing better already. But, if you try and do everything all at once, then you're not going to show results for twelve, eighteen months, maybe longer in a larger enterprise. So finding a chewable problem and biting into it, is a good solution there.

Bernard: So...a common pitfall was lack of executive sponsorship. Real involved executive sponsorship. A second is lack of sufficient investment for tooling, or whatever it might be. A third is not scoping a project so it can be executed fairly quickly, and show results fairly quickly, thereby proving the foundation for further stuff. I think that makes sense.

Andi: And just quickly, the fourth one there was basically, getting all the stakeholders to support. So if you're Dev and you want to do DevOps, getting Ops and QA to support it. If you're Ops, you just want to make your life better getting Dev to support it. If you're going to collaborate, everyone's got to be on board.

Register for the next fireside chat: http://fireside.activestate.com.

The post The Journey to Enterprise DevOps: Process Change and Other Thorny Issues appeared first on ActiveState.

More Stories By Michael Kanasoot

Michael Kanasoot is a Product Marketing Manager and caffeine enthusiast at ActiveState. He manages product messaging and marketing campaigns for various products including Stackato and Komodo IDE. Prior to joining ActiveState, Michael specialized in marketing mobile security and IT asset management solutions. He holds a Bachelor of Commerce from the University of British Columbia.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
Moroccanoil®, the global leader in oil-infused beauty, is thrilled to announce the NEW Moroccanoil Color Depositing Masks, a collection of dual-benefit hair masks that deposit pure pigments while providing the treatment benefits of a deep conditioning mask. The collection consists of seven curated shades for commitment-free, beautifully-colored hair that looks and feels healthy.
The textured-hair category is inarguably the hottest in the haircare space today. This has been driven by the proliferation of founder brands started by curly and coily consumers and savvy consumers who increasingly want products specifically for their texture type. This trend is underscored by the latest insights from NaturallyCurly's 2018 TextureTrends report, released today. According to the 2018 TextureTrends Report, more than 80 percent of women with curly and coily hair say they purcha...
The textured-hair category is inarguably the hottest in the haircare space today. This has been driven by the proliferation of founder brands started by curly and coily consumers and savvy consumers who increasingly want products specifically for their texture type. This trend is underscored by the latest insights from NaturallyCurly's 2018 TextureTrends report, released today. According to the 2018 TextureTrends Report, more than 80 percent of women with curly and coily hair say they purcha...
We all love the many benefits of natural plant oils, used as a deap treatment before shampooing, at home or at the beach, but is there an all-in-one solution for everyday intensive nutrition and modern styling?I am passionate about the benefits of natural extracts with tried-and-tested results, which I have used to develop my own brand (lemon for its acid ph, wheat germ for its fortifying action…). I wanted a product which combined caring and styling effects, and which could be used after shampo...
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.