Showing posts with label James Governor. Show all posts
Showing posts with label James Governor. Show all posts

Friday, January 08, 2016

Redmonk Analysts on Best Navigating the Tricky Path to DevOps Adoption

Transcript of a BriefingsDirect discussion on why organizations need DevOps and how they should approach it.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Dana Gardner: Hello, and welcome to the next edition of the HPE Discover Podcast Series. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this ongoing discussion on IT innovation and how it’s making an impact on people’s lives.

Gardner
Our next DevOps Thought Leadership Discussion explores the pitfalls and payoffs of DevOps adoption, with an emphasis on the developer perspective. We're here with two prominent IT industry analysts, the founders of RedMonk, to unpack the often tricky path to DevOps and to explore how enterprises can find ways to make pan-IT collaboration a rule, not an exception.

With that, please join me in welcoming James Governor, Founder and Principal Analyst at RedMonk, and he is based in London. Welcome, James.

James Governor: Good morning.
Learn More About DevOps
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Gardner: We're also here with Stephen O'Grady, Founder and Principal Analyst at RedMonk and he is based in Portland, Maine. Welcome, Stephen.

Stephen O’Grady: Thanks so much for having us.

Gardner: Gentleman, let’s look at DevOps through a little bit of a different lens. Often, it’s thought of as a philosophy. It’s talked about as a way of improving speed and performance of applications and quality, but ultimately, this is a behavior and a culture discussion -- and the behavior and culture of developers is an important part of making DevOps successful.

What do developers think of DevOps? Is this seen as a positive thing or a threat? Do they have a singular sense of it, or is it perhaps all over the map?

O'Grady
O’Grady: The overwhelming assessment from developers is positive, simply because -- if you look at the tasks for a lot of developers today -- it’s going to involve operational tasks.

In other words, if you're working, for example, on public-cloud platforms, some degree of what you're doing as a developer is operational in nature, and vice versa, once you get to the operational side. A lot of the operational side has now been automated in ways that look very much like what we used to expect from development. 

So there is very naturally a convergence between development and operations that developers are embracing.

Driven by developers

Governor: I think developers have driven the change. We've seen this in a number of areas, whether it’s data management or databases, where the developers said, "We're not going to wait for the DBA anymore. We're going to do NoSQL. We're just going to choose a different store. And we're not going to just use Oracle." We've seen this in different parts of IT.

Governor
The bottom line is that waterfall wasn’t working. It wasn’t leading to the results it should, and developers were taking some of the heat from that. So engineers and developers have begun to build out what has now becomes DevOps. A lot of them were cloud natives and thought they knew best, and in some cases, they actually did some really good work.

Partly enabled by cloud computing, DevOps had made a lot of sense, because you're able to touch everything in a way that you weren’t able to on your own prem. It has been a developer-led phenomenon. It would be surprising if developers were feeling threatened by it.

Gardner: Enterprises, the traditional Global 2000 variety, see what happens at startups and recognize that they need to get on that same speed or agility, and oftentimes those startups are developer-centric and culturally driven by developers.

If the developers are, in fact, the tip of the arrow for DevOps, what is it that the operations people should keep in mind? What advice would you give to the operations side of the house for them to be better partners with their developer core?

Governor: The bottom line is that it’s coming. This is not an option. An organization could say we have this way of doing ops and we will continue doing that. That’s fine, but to your point about business disruption, we don’t have time to wait. We do need to be delivering more products to market faster, particularly in the digital sphere, and the threat posture and the opportunity posture have changed very dramatically in the past three years.

It's the idea that Hilton International or Marriott would be worrying about Airbnb. They weren’t thinking like that. Or transport companies around the world asking what the impact of Uber is.

We've all heard that software is eating the world, but what that basically says is that the threats are real. We used to be in an environment where, if you were a bank, you just looked at your four peer banks and thought that as long as they don’t have too much of an advantage, we're okay. Now they're saying that we're a bank and we're competing with Google and Facebook.

Actually, the tolerance for stability is a little bit lower than it was. I had a very interesting conversation with a retailer recently. They had talked about the different goals that organizations have. And it was very interesting to me that he said that, on the first day they launched a new mobile app, it fell over. And they were all high-fiving and fist pumping, because it meant they had driven so much traffic that the app fell over, and it was something they needed to remediate.

That is not how IT normally thinks. Frankly, the business has not told IT they want it to be either, but it has sort of changed. I think the concern for new experiences, new digital products is now higher than the obsession with stability. So it is a different world. It is a cultural shift.

Differentiator

Gardner: Whether you're a bank or you're making farm equipment, your software is the biggest differentiator you can bring to the market. Stephen, any thoughts about what operations should keep in mind as they become more intertwined with the developer organization?

O'Grady: The biggest thing for me is a variety of macro shifts in the market, things like the availability of open-source software and public cloud. It used to be that IT could control the developer population. In other words, they were essentially the arbiter of what went to production and what actually got produced. If you're a developer and you have a good idea, but you don’t have any hardware or infrastructure, then you're out of luck.

These days, that’s changed, and we see these organizationally, where developers can go to operations and say, they need infrastructure, and operations will say six months. The developers say, "To hell with six months. I'm going to go to Amazon and I have something up in 90 seconds." The notion that's most important for operations is that they're going to have to work with developer populations because, one way or another, developers are going to get what they want.

Gardner: When we think about the supplier, the vendor, side of things, almost every vendor I've talked to in the last two or three months has raised the question of DevOps. It has become top of mind for them. Yet, if you were to ask an organization, how do you install DevOps, how do you buy DevOps, which shape box does it come in, none of those questions are relevant because it’s not a product.
If you're in ops and you are not currently looking at tools like Chef, Puppet, Ansible, or SaltStack, you're doing yourself a disservice. They're powerful tools in the arsenal.

How do the vendors grease the skids toward adoption, if you will? What do you think needs to happen from those tools, platforms and technologies?

Governor: It’s very easy to say that DevOps is not a product, and that’s true. On the other hand, there are some underlying technologies that would have driven this, particularly in automation and the notion of configuration is code.

If you're in ops and you are not currently looking at tools like Chef, Puppet, Ansible, or SaltStack, you're doing yourself a disservice. They're powerful tools in the arsenal. 

One of the things to understand is that in the world of open source, it's perhaps going to be packaged by a more traditional vendor. Certainly, one of the things is rethinking how you do automation. I would counsel anyone in IT ops to at least have a team starting to look at that, perhaps for some new development that you're doing.

It’s easy to say that everything is a massive transformation, because then it’s just a big services opportunity and there's lots of hand waving. But at the end of the day, DevOps has been a tools-driven phenomenon. It’s about being closer to the metal, having better observability, and having a better sense of how the application is working.

One of the key things is the change in responsibility. We've lived in an environment where we remember the blame game and lots of finger pointing. If you look at Netflix, that doesn’t happen. The developer who breaks the build fixes it.

There are some significant changes in culture, but there are some tools that organizations should be looking at.

What can they do?

O’Grady: If we're talking from a vendor perspective, they can talk to their customers about the cultural change and organizational change that’s necessary to achieve the results that they want, but they can't actually affect that. In other words, what we're talking about, rather, is what they can do.

The most important thing that vendors who play in this and related spaces can do is understand that it’s a continuum. From the first code that gets written, to check-in, to build, to being deployed on to infrastructure that’s configured using automated software, it’s a very, very long chain, a very long sequence of events.

Understanding from a vendor perspective where you fit into that lifecycle, what are the other pieces you have to integrate with, and from a customer perspective what are all the different pieces they are going to be using is critical.

In other words, if you're focused on a particular functional capability and that's the only thing that you are aware of and that’s the only thing that you tackle, you're doing your customer a disservice. There are too many moving pieces for any one vendor to tackle them all. So it’s going to be critically important that you're partner-friendly, project-friendly and so on and integrate well and play nicely with others.
Learn More About DevOps
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Governor: But also, don’t let a crisis go to waste. IT ops has budget, but they're also always getting a kick in the teeth. Anything that goes wrong is their fault, even if it’s someone else's. The simple fact is that we're in an environment where organizations, as I've said, are thinking that the threat and opportunity posture has changed. It's time to invest in this.

A good example of this would be that we always talk about standardization, but then nobody wants to give us the budget to do that. One of the things that we've tended to see in these web-native companies and how they manage operations and so on is that they've done an awful lot of standardization on what the infrastructure looks like. So there is an opportunity here. It’s a threat and an opportunity as well.

Gardner: I've been speaking with a few users, and there are a couple of rationales from them on what accelerates DevOps adoption. One of them is security and compliance, because the operations people can get more information back to the developers. Developers can insist that security gets baked in early and often.

The other one is user experience. The operations side of the house now has the data from the user, especially when we talk about mobile apps and smaller customer-facing applications and web apps. All that data is now being gathered. What happens with the application can be given back to development very quickly. So there is a feedback loop that's compressed.

What do you think needs to happen in order for the incentives to quicken the adoption of DevOps from the perspective of security, user experience, and feedback loops of shared data?

Ongoing challenge

Governor: That’s such a good question. It’s going to remain an ongoing challenge. The simple fact is that, as I said about the retail and the mobile app, different parts of the business have different goals. Finance doesn't have the same goals as sales, and sales does not have the same goals as marketing in fact.

Within IT, there are different groups that have had very different key performance indicators (KPIs), and that’s part of the discussion. I think you are absolutely right to bring that up, understanding what are the metrics that we should be using, what are the new metrics for success? Is it the number of new products or changes to our application code that we can run out?

We're all incredibly impressed by Etsy and Netflix because they can make all of these changes per day to their production environment. Not everybody wants to do that, but I think it’s what these KPIs are.

It might be, as Stephen had mentioned, if previously we were waiting six months to get access to server and storage, and we get that down to a minute or so, it’s pretty obvious that that’s a substantive step forward.
The big one for me is user experience, and that to me is where a lot of the DevOps movement has come from.

You're absolutely right to say that it is about the data. When we began on this transition around agile and so on, there was a notion that those guys don’t care about data, they don’t care about compliance. The opposite is true, and there has been a real focus on data to enable the developer to do better work.

In terms of this shift that we're seeing, there's an interesting model that, funnily enough, HPE has begun talking about, which is "shifting left." What they mean by that is taking that testing earlier into the process.

We had been in an environment where a developer would hand off to someone else, who would hand off to someone else, at every step of the way. The notion that testing happens early and happens often is super important in this regard.

Gardner: Continuous delivery and service virtualization are really taking off now. I just want to give Stephen an opportunity to address this alignment of interests, security, user experience, and shared data, and thoughts about how organizations should encourage adoption using these aligned interests.

User experience

O’Grady: I can’t speak to this query angle as much. In other words, there are aspects to that, particularly when we think about configuration management and the things that you can do via automation and so on.

The big one for me is user experience, and that to me is where a lot of the DevOps movement has come from. What we've found out is that if you want to deliver an ideal experience via an application to 100 people or 1,000 people, that’s not terribly difficult, and what you are using infrastructure-wise to address that is also not a sort of huge challenge.

On the flip side, you start talking millions and tens of millions of users, hundreds of millions of users potentially, then you have a completely different set of challenges involved. What we've seen from that is that the infrastructure necessary to deliver quality experiences, whether you're Netflix, Facebook, or Google, or even just a large bank, that's a brand-new challenge.
But security is definitely an elephant stomping around the room. There's no question. The feedback loop around DevOps has not been as fixated on security as it might be.

Then, when you get into not just delivering a quality experience through a browser, but delivering it through a mobile application, this encourages and, in fact, necessitates a series of architectural changes to scale out and all these other sort of wonderful things that we talk about.

Then, if we're dealing with tens of thousands or hundreds of thousands of machines, instead of a handful of very, very large ones, we need a different approach, and that different approach in many respects is going to be DevOps. It’s going to be taking a very hands-on developer approach to traditional operational tasks.

Governor: But security is definitely an elephant stomping around the room. There's no question. The feedback loop around DevOps has not been as fixated on security as it might be.

Quite frankly, developers are about getting things done and this is the constant challenge, ops, security, and so on. Look at Docker. Developers absolutely love it, but it didn’t start in a position of how do we make this the most secure model you could ever have for application deployment.

There are some weird people who started to use the word DevOps(Sec), but there are a lot of unicorns and rainbows and there is going to be a mess that needs clearing up. Security is something that we generally don’t do that well.

On the other hand, as I said, we're less concerned with stability, and on the security side, it does seem like. Look at privacy. We all gave up on that, right?

Gardner: I suppose. Let’s not give up on security though.

Governor: Well, those things go together.

Gardner: They do.

Need to step up

Governor: Certainly, the organizations that would claim to be really good at security are the ones that have been leaving all of their customers' details on a USB stick or on a laptop. The security industry has not done itself many favors. They need to step up as much as developers do.

Gardner: As we close out, maybe we can develop some suggestions for organizations that create a culture for DevOps or put in place the means for DevOps. Again, speaking with a number of users recently, automation and orchestration come to mind. Having that in place means being able to scale, to be able to provide the data back, monitoring, and data from a big-data perspective across systems to pan IT data, and the ability to measure that user experience. Any other thoughts about what you as an organization should put in place that will foster a DevOps mentality?

Governor: There are a couple of things. One thing you didn’t mention is pager duty. It's a fact that somebody is going to get called out to fix the thing, and it’s about individuals taking responsibility. With that responsibility, give them a higher salary. That’s an interesting challenge for IT, because they're always told, here are a bunch of tools that enable the Type As to get stuff done.
What’s important is to just get out and start spending time reading the stuff that the web companies are doing and sharing.

As to your point about whether this is a cultural shift or a product shift, the functional areas you mentioned are absolutely right, but as to the culture, just what’s important is to just get out and start spending time reading the stuff that the web companies are doing and sharing.

If you look at Etsy or Netflix, they're not keeping this close to their chest. Netflix, in fact, has provided the tools it uses to improve stability through Chaos Monkey. So there's much more sharing, there's much more there, and the natural thing would be to go to your developer events. They're the people building out this new culture. Embed yourself in this developer aesthetic, where GitHub talks about “optimizing for developer joy." Etsy is about “Engineering Happiness.”

Gardner: Stephen, what should be in place in organizations to foster better DevOps adoption?

O’Grady: It’s an interesting question. The thing that comes to mind for me is a great story from Adrian Cockcroft, who used to be with Netflix. We've talked about him a couple of times. He's now with Battery Ventures, and he gives a very interesting talk, where he goes out and talks to executives and senior technology executives from all of these Fortune 500 companies.

One of the things he get asked over and over and over is, "Where do you find engineers like the ones that work at Netflix? Where do we find these people that can do this sort of miraculous DevOps work?" And his response is, "We hired them from you."

The singular lesson that I would tell all the organizations is that somewhere in your organization probably are the people who know how this stuff works and want to get it done. A lot of times, it’s basically just empowering them, getting out of the way and letting the stuff happen, as opposed to trying to put the brakes on all the time.

Organic DevOps

Gardner: So allowing the organic DevOps to happen as well as the top-down DevOps.

Governor: That’s right.   

O’Grady: That’s exactly right.
Learn More About DevOps
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Gardner: Well, great, I'm afraid we will have to leave it there. We've been talking with two prominent IT industry analysts, the Founders of RedMonk, on unpacking the path to DevOps.

I would like to thank James Governor, Founder and Principal Analyst at RedMonk, along with Stephen O’Grady, also the Founder and Principal Analyst at RedMonk.

And thank you as well to our audience for joining us for this DevOps Thought Leadership Discussion. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of HPE-sponsored discussions. Thanks again for listening, and come back next time.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Transcript of a BriefingsDirect discussion on why organizations need DevOps and how they should approach it. Copyright Interarbor Solutions, LLC, 2005-2016. All rights reserved.

You may also be interested in:

Thursday, November 19, 2015

Agile on Fire: IT Enters the New Era of 'Continuous' Everything

Transcript of a BriefingsDirect discussion on the concept of continuous processes around development and deployment of applications.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Dana Gardner: Hello, and welcome to the next edition of the HPE Discover Podcast Series. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host and moderator for this ongoing discussion on IT innovation and how it’s making an impact on people’s lives.

Gardner
Our next DevOps Thought Leadership Discussion explores the concept of continuous processes around the development and deployment of applications and systems. Put the word continuous in front of many things and we help define DevOps: continuous delivery, continuous testing, continuous assessment, and there is more.

To help better understand the continuous nature of DevOps, we're joined by two guests, James Governor, Founder and Principal Analyst at RedMonk, and Ashish Kuthiala, Senior Director of Marketing and Strategy for Hewlett Packard Enterprise (HPE) DevOps. Welcome to you both.
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information
Ashish Kuthiala: Hi, glad to be here, Dana.

Gardner: Ashish, we hear a lot about feedback loops in DevOps between production and development, test and production. Why is the word "continuous" now cropping up so much? What do we need to do differently in IT in order to compress those feedback loops and make them impactful?

Kuthiala: Gone are the days where you would see the next version 2.0 coming out in six months and 2.1 coming out three months after that.

Kuthiala
If you use some of the modern applications today, you never see Facebook 2.0 is coming out tomorrow or Google 3.1 is being released. They are continuously and always making improvements from the back-end onto the platforms of the users -- without the users even realizing that they're getting improvements, a better user experience, etc.

In order to achieve that, you have to continuously be building those new innovations into your product. And, of course, as soon as you change something you need to test it and roll it all the way into production.

In fact, we joke a lot about how if everything is continuous, why don’t we drop the word continuous and just call it planning, testing, or development, like we do today, and just say that you continuously do this. But we tend to keep using this word "continuous" before everything.

I think a lot of it is to drive home the point across the IT teams and organizations that you can no longer do this in chunks of three, six, or nine months -- but you always have to keep doing this.

Governor: How do you do the continuous assessment of your continuous marketing?

Continuous assessment

Kuthiala: We joke about the continuous marketing of everything. The continuous assessment term, despite my objections to the word continuous all the time, is a term that we've been talking about at HPE.

The idea here is that for most software development teams and production teams, when they start to collaborate well, take the user experience, the bugs, and what’s not working on the production end at the users’ hands -- where the software is being used -- and feed those bugs and the user experience back to the development teams.

When companies actually get to that stage, it’s a significant improvement. It’s not the support teams telling you that five users were screaming at us today about this feature or that feature. It’s the idea that you start to have this feedback directly from the users’ hands.

We should stretch this assessment piece a little further. Why assess the application or the software when it’s at the hands of the end users? The developer, the enterprise architects, and the planners design an application and they know best how it should function.

Whether it’s monitoring tools or it’s the health and availability of the application, start to shift left, as we call it. I'd like James to comment more about this, because he knows a lot about the development space. The developer knows his code best; let him experience what the user is starting to experience.

Governor: My favorite example of this is that, as an analyst, you're always looking for those nice metaphors and ways to talk about the world -- one notion of quality I was very taken with was when I was reading about the history if ship-building and the roles and responsibilities involved in building a ship.

Governor
One of the things they found was that if you have a team doing the riveting separate from doing the quality assurance (QA) on the riveting, the results are not as good. Someone will happily just go along -- rivet, rivet, rivet, rivet -- and not really care if they're doing a great job, because somebody else is going to have to worry about the quality.

As they moved forward with this, they realized that you needed to have the person doing the riveting also doing the QA. That’s a powerful notion of how things have changed.

Certainly the notion of shifting left and doing more testing earlier in the process, whether that be in terms of integration, load testing, whatever, all the testing needs to happen up front and it needs to be something that the developers are doing.

The new suite of tools we have makes it easier for developers to have better experiences around that, and we should take advantage.

Lean manufacturing

One of the other things about continuous is that we're making reference to manufacturing modes and models. Lean manufacturing is something that led to fewer defects, apart from one catastrophic example to the contrary. And we're looking at that and asking how we can learn from that.

So lean manufacturing ties into lean startups, which ties into lean and continuous assessment.

What’s interesting is that now we're beginning to see some interplay between the two and paying that forward. If you look at GM, they just announced a team explicitly looking at Twitter to find user complaints very, very early in the process, rather than waiting until you had 10,000 people that were affected before you did the recall.

Last year was the worst year ever for recalls in American car manufacturing, which is interesting, because if we have continuous improvement and everything, why did that happen? They're actually using social tooling to try to identify early, so that they can recall 100 cars or 1,000 cars, rather than 50,000.

It’s that monitoring really early in the process, testing early in the process, and most importantly, garnering user feedback early in the process. If GM can improve and we can improve, yes.

Gardner: I remember in the late '80s, when the Japanese car makers were really kicking the pants out of Detroit, that we started to hear a lot about simultaneous engineering. You wouldn’t just design something, but you designed for its manufacturability at the same time. So it’s a similar concept.
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information
But going back to the software process, Ashish, we see a level of functionality in software that needs to be rigorous with security and performance, but we're also seeing more and more the need for that user experience for features and functions that we can’t even guess at, that we need to put into place in the field and see what happens.

How does an enterprise get to that point, where they can so rapidly do software that they're willing to take a chance and put something out to the users, perhaps a mobile app, and learn from its actual behavior? We can get the data, but we have to change our processes before we can utilize it. 

Kuthiala: Absolutely. Let me be a little provocative here, but I think it’s a well-known fact that the era of the three-year, forward-looking roadmaps is gone. It’s good to have a vision of where you're headed, but what feature, function and which month will you release so that the users will find it useful? I think that’s just gone, with this concept of the minimum viable product (MVP) that more startups take off with and try to build a product and fund themselves as they gain success.

It’s an approach even that bigger enterprises need to take. You don't know what the end users’ tastes are.

I change my taste on the applications I use and the user experience I get, the features and functionality. I'm always looking at different products, and I switch my mind quite often. But if I like something and they're always delivering the right user experience for me, I stick with them.

Capture the experience

The way for an enterprise to figure out what to build next is to capture this experience, whether it’s through social media channels or engineering your codes so that you can figure out what the user behavior actually is.

The days of business planners and developers sitting in cubicles and thinking this is the coolest thing I'm going to invent and roll out is not going to work anymore. You definitely need that for innovation, but you need to test that fairly quickly.

Also gone are the days of rolling back something when something doesn’t work. If something doesn’t work, if you can deliver software really quickly at the hands of end users, you just roll forward. You don’t roll back anymore.

It could be a feature that’s buggy. So go and fix it, because you can fix it in two days or two hours, versus the three- to six-month cycle. If you release a feature and you see that most users -- 80 percent of the users -- don’t even bother about it, turn it off, and introduce the new feature that you were thinking about.

This assessment from the development, testing, and production that you're always doing starts to benefit you. When you're standing up for that daily sprint and wondering what are the three features I'm going to work on as a team, whether it’s the two things that your CEO told you you have to absolutely do it, because "I think it’s the greatest thing since sliced bread," or it’s the developer saying, "I think we should build this feature," or some use case is coming out of the business analyst or enterprise architects.
We have wonderful new platforms that enable us to store a lot more data than we could before at a reasonable cost.

Now you have data. You have data across all these teams. You can start to make smarter decisions and you can choose what to build and not build. To me, that's the value of continuous assessment. You can invest your $100 for that day in the two things you want to do. None of us has unlimited budgets.

Gardner: For organizations that grok this, that say, "I want continuous delivery. I want continuous assessment," what do we need to put in place to actually execute on it to make it happen?

Governor: We've spoken a lot about cultural change, and that’s going to be important. One of the things, frankly, that is an underpinning, if we're talking about data and being data-driven, is just that we have wonderful new platforms that enable us to store a lot more data than we could before at a reasonable cost.

There were many business problems that were stymied by the fact that you would have to spend the GDP of a country in order to do the kind of processing that you wanted to, in order to truly understand how something was working. If we're going to model the experiences, if we are going to collect all this data, some of the thinking about what's infrastructure for that so that you can analyze the data is going to be super important. There's no point talking in being data-driven if you don’t have architecture for delivering on that.

Gardner: Ashish, how about loosely integrated capabilities across these domains, tests, build, requirements, configuration management, and deployment? It seems that HPE is really at the center of a number of these technologies. Is there a new layer or level of integration that can help accelerate this continuous assessment capability?

Rich portfolio

Kuthiala: You're right. We have a very rich portfolio across the entire software development cycle. You've heard about our Big Data Platform. What can it really do, if you think about it? James just referred to this. It’s cheaper and easier to store data with the new technologies, whether it’s structured, unstructured, video, social, etc., and you can start to make sense out of it when you put it all together.

There is a lot of rich data in the planning and testing process, and all the different lifecycles. A simple example is a technology that we've worked on internally, where when you start to deliver software faster and you change one line of code and you want this to go out. You really can’t afford to do the 20,000 tests that you think you need to do, because you're not sure what's going to happen.

We've actually had data scientists working internally in our labs, studying the patterns, looking at the data, and testing concepts such as intelligent testing. If I change this one line of code, even before I check it in, what parts of the code is it really affecting, what functionality? If you are doing this intelligently, does it affect all the regions of the world, the demographics? What feature function does it affect?
We've actually had data scientists working internally in our labs, studying the patterns, looking at the data, and testing concepts such as intelligent testing.

It's helping you narrow down whether will it break the code, whether it will actually affect certain features and functions of this software application that’s out there. It's narrowing it down and helping you say, "Okay, I only need to run these 50 tests and I don't need to go into these 10,000 tests, because I need to run through this test cycle fast and have the confidence that it will not break something else."

So it's a cultural thing, like James said, but the technologies are also helping make it easier.

Gardner: It’s interesting. We're borrowing concepts from other domains in the past as well -- just-in-time testing or fit-for-purpose testing, or lean testing?

Kuthiala: We were talking about Lean Functional Testing (LeanFT) at HP Discover. I won't talk about that here in terms of product, but the idea is exactly that. The idea is that the developer, like James said, knows his code well. He can test it well before and he doesn’t throw it over the wall and let the other team take a shot at it. It’s his responsibility. If he writes a line of code, he should be responsible for the quality of it.

Gardner: And it also seems that the integration across this continuum can really be the currency of analysis. When we have data and information made available, that's what binds these processes together, and we're starting to elevate and abstract that analysis up and it make it into a continuum, rather than a waterfall or a hand-off type of process.

Before we close out, any other words that we should put in front of continuous as we get closer to DevOps -- continuous security perhaps?

Security is important

Kuthiala: Security is a very important topic and James and I have talked about it a lot with some other thought leaders. Security is just like testing. Anything that you catch early on in the process is a lot easier and cheaper to fix than if you catch it in the hands of the end users, where now it’s deployed to tens and thousands of people.

It’s a cultural shift. The technology has always been there. There's a lot of technology within and outside of HP that you need to incorporate the security testing and the discipline right into the development and planning process and not leave it towards the end.

In terms of another continuous word, I mean I can come up with continuous Dana Gardner podcast.

Governor: There you go.

Gardner: Continuous discussions about DevOps.
One of the things that RedMonk is very interested in, and it's really our view in the world, is that, increasingly, developers are making the choices, and then we're going to find ways to support the choices they are making.

Governor: One of the things that RedMonk is very interested in, and it's really our view in the world, is that, increasingly, developers are making the choices, and then we're going to find ways to support the choices they are making.

It was very interesting to me that the term continuous integration began as a developer term, and then the next wave of that began to be called continuous deployment. That's quite scary for a lot of organizations. They say, "These developers are talking about continuous deployment. How is that going to work?"

The circle was squared when I had somebody come in and say what we're talking to customers about is continuous improvement, which of course is a term again that we saw in manufacturing and so on.

But the developer aesthetic is tremendously influential here, and this change has been driven by them. My favorite "continuous" is a great phrase, continuous partial attention, which is the world we all live in now.

Gardner: I'm afraid we will have to leave it there. We've been exploring the concept of continuous processes around development and deployment of applications.

I'd like to thank our guests, James Governor, Founder and Principal Analyst at RedMonk, and Ashish Kuthiala, Senior Director of Marketing and Strategy for HPE DevOps.
Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information
I'd also like to thank our audience for joining this special DevOps Thought Leadership Discussion. I'm Dana Gardner, Principal Analyst at Interarbor Solutions, your host for this ongoing series of HPE-sponsored discussions. Thanks again for listening, and come back next time.

Listen to the podcast. Find it on iTunes. Get the mobile app. Download the transcript. Sponsor: Hewlett Packard Enterprise.

Transcript of a BriefingsDirect discussion on the concept of continuous processes around development and deployment of applications. Copyright Interarbor Solutions, LLC, 2005-2015. All rights reserved.

You may also be interested in: