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:

• How INOVVO delivers big data network analysis for greater mobile user loyalty
• DevOps by design--A practical guide to effectively ushering DevOps into any organization
• Need for Fast Analytics in Healthcare Spurs Sogeti Converged Solutions Partnership Model
• HPE's composable infrastructure sets stage for hybrid market brokering role
• Nottingham Trent University Elevates Big Data's role to Improving Student Retention in Higher Education
• Forrester analyst Kurt Bittner on the inevitability of DevOps
• Agile on fire: IT enters the new era of 'continuous' everything
• Big data enables top user experiences and extreme personalization for Intuit TurboTax
• Feedback loops: The confluence of DevOps and big data
• IoT brings on development demands that DevOps manages best, say experts
• Big data generates new insights into what’s happening in the world's tropical ecosystems
• DevOps and security, a match made in heaven
• How Sprint employs orchestration and automation to bring IT into DevOps readiness

Nottingham Trent University Elevates Big Data’s Role to Improving Student Retention in Higher Education

Transcript of a BriefingsDirect discussion on how one university uses big data analysis to track student performance and quickly identify at-risk students.

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 big-data case-study interview examines how Nottingham Trent University in England has devised and implemented an information-driven way to encourage higher student retention.

By gathering diverse data and information and making rapid analysis, Nottingham Trent is able to quickly identify those students having difficulties. They can thereby provide significant reductions in dropout rates while learning more about what works best to usher students into successful academic careers.

What’s more, the analysis of student metrics is also setting up the ability to measure more aspects of university life and quality of teaching, and to make valuable evidence-based correlations that may well describe what the next decades of successful higher education will look like.

To learn more about taking a new course in the use of data science in education, we're pleased to welcome Mike Day, Director of Information Systems at Nottingham Trent University in Nottingham, UK. Welcome, Mike.

Mike Day: Thank you.

Gardner: First tell us about Nottingham Trent University. It’s a unique institute, a very large student body and many of them attending university for the first time in their families.

Day: That’s right. We've had around 28,000 students over the last few years, and that’s probably going to increase this year to around 30,000 students. We have, as you say, many, many students who come from poor backgrounds -- what we call "widening participation" students. Many of them are first generation in their family to go to university.

Sometimes, those students are a little bit under-confident about going to university. We’ve come to call them "doubter students," and those doubters are the kinds of people that when they struggle, they believe it’s their fault, and so they typically don't ask for help.

Gardner: So it's incumbent upon you to help them know better where to look for help and not internalize that. What do you use to measure the means by which you can identify students that are struggling?

Low dropout rate

Day: We’ve always done very well in Nottingham Trent. We had a relatively low dropout rate, about seven percent or so, which is better than sector average. Nevertheless, it was really hard for us to keep students on track throughout their studies, especially those who were struggling early in their university career. We tended to find that we have to put a lot of effort into supporting students when they had failed exams, which for us, was too late.

Day

We needed to try to find a way where we could support our students as early as possible. To do that, we had to identify those students who were finding it a bit harder than the average student and were finding it quite difficult to put their hand up and say so.

So we started to look at the data footprint that a student left across the university, whether that was a smart card swipe to get them in and out of buildings or to use printers, or their use of the library, in particular taking library books out, or accessing learning materials through our learning management system. We wanted to see whether those things would give us some indication as to how well students were engaged in their studies and therefore, whether they're struggling or not.

Gardner: So this is not really structured information, not something you would go to a relational database for, part of a structured packaged application, for example. It's information that we might think of as breadcrumbs around the organization that you need to gather. So what was the challenge for dealing with such a wide diversity of information types?

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

Day: We had a very wide variety of information types. Some of it was structured, and we put a lot effort into getting some good quality data over the years, but some of it was unstructured. Trying to bring those different and disparate datasets together was proving very difficult to do in very traditional business intelligence (BI) ways.

We needed to know, in about 600 terabytes of data, what really mattered, what were the factors that in combination told us something about how successful students behave, and therefore something about comparing those that were not having such an easy time at the university how to compare that to those who were succeeding in it.

We needed ultimately to get to a position where we could create great relationships between people, particularly between tutors or academic counselors and individual students.

Gardner: It sounds as if the challenges were not only in the gathering of good information but in how to then use that effectively in drawing correlations that would point out where students rapidly were struggling. Tell us about both the technology side and then also the methodologies that you then use to actually create those correlations?

Day: You're absolutely right. It was very difficult to find out what matters and to get the right data for that. We needed ultimately to get to a position where we could create great relationships between people, particularly between tutors or academic counselors and individual students.

On the technology side, we engaged with a partner, that was a company called DTP Solutionpath, who brought with them the HPE IDOL engine. That allowed us to submit about five years worth of back data into the IDOL engine to try to create a model of engagement, in other words, to pick out what factors within that data in combination gave as a high confidence around student engagement.

Our partners did that. They worked very closely with us in a very collaborative way, with our academic staff, with our students, importantly -- because we have to be really clear and transparent about what we are doing in all of this, from an ethical point of view -- and with my IT technical team. And that collaboration really helped us to boil down what sorts of things really mattered.

Anonymizing details

Gardner: When you look at this ethically you have to anonymize a great deal of this data in order to adhere to privacy and other compliance issues. Is that the case?

Day: Actually, we needed to be able to identify individual students in all of this, and so there were very real privacy issues in all of this. We had to check quite carefully our legal position to make sure that we did comply with UK Data Protection Act, but that’s only a part of it.

What’s acceptable to the organization and ultimately to individual students is perhaps even more important than the strict legal position in all of this. We worked very hard to explain to students and staff what we were trying to do and to get them on board early, at the beginning of this project, before we had gone too far down the track, to understand what would be acceptable and what wouldn’t.

Gardner: I suppose it’s important to come off as a big brother and not the Big Brother in this?

Day: Absolutely. Friendly big brother is exactly what we needed to be. In fact, we found that how we engage with our student body was really important in all of this. If we try to explain this in a technical way. then it was very much Big Brother. But when we started to say, "We're trying to give you the very best possible support, such that you are most likely to succeed in your time in higher education and reap the rewards of your investment in higher education," then it became a very different story.

We worked very hard to explain to students and staff what we were trying to do and to get them on board early.

Particularly, when we were able to demonstrate the kind of visualizations of engagement to students, that shifted completely, and we've had very little, if any, problems with ethical concerns among students.

Gardner: It also seems to me that the stakes here are rather high. It's hard to put a number on it, but for a student who might struggle and drop out in their first months at university, it means perhaps a diminished potential for them over their lifetime of career, monetization of income, and contribution to society, and so forth.

So for thousands of students, this could impact them over the course of a generation. This could be a substantial return on investment (ROI), to be a bit crass and commercial about it.

Day: If you take all of this from the student’s perspective, clearly students are investing significant amounts of money in their education.

In the UK, that’s ￡9,000 (USD $13,760) a year at the moment, plus the accommodation costs, and the cost of not getting a job early, and all of those sorts of things that those students put into to invest in their early university career. To lose that means that they come out of the university experience being less positive than it could have been, with much, much lower earning potential over their lifetime.

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

That also has an impact on UK PLC, in that it isn’t perhaps generating as many skilled individuals as it might. That has implications for tax returns and also from a university point of view. Clearly if our students dropout, they aren’t paying their fees, and those slots are now empty. In terms of university efficiency, there was also a problem. So everybody wins if we can keep students on course.

On the journey

Gardner: Certainly a worthy goal. Tell us a little bit about where you are now? I think we have the vision. I think we understand the stakes and we understand some of the technologies we’ve employed. Where are you on this journey? Then, we can talk about so far what some of the results have been.

Day: It was very quick to get to a point where the technology was giving us the right kinds of answers. In about two to three months, we got into a position where the technology was pretty much done, but that was only a really part of the story. We really needed to look at how that impacted our practice in the university.

So we started to run a series of pilots into the series of courses. We did that over the course of a year about 18 months ago and we looked at every aspect of academic support for students and how this might change all of this. If we see that a student is disengaging from their studies, and we can see that now about a month or two before it otherwise would have been able to do that, we can have a very early conversation about what the problem might be.

In more than 90 percent of the cases that we have seen so far, those early conversations result in an immediate upturn in student engagement. We’ve seen some very real tangible results and we saw those very early on.

We've started to see students competing with each other to be the best engaged in their course. That’s got to be a good thing.

We expected that it would take as a considerable amount of time to demonstrate the system would give us a value at an institutional level, but actually it didn't. It took about six months or so into that pilot period that would set a year aside for to get to a position where we were convinced, as an institution ,that we roll out across the whole university. We did that at the beginning of this academic year and we rolled out about six months earlier than we thought. So we might even start thinking about that.

We now have had another year thinking about what good practice is, seeing that academic tutors are starting to share good practice among themselves. So there is a good conversation going on there. There is a much, much more positive relationship between those academic tutors and the students being reported from both the students and the tutors, we see that being very positive.

Importantly, there is also a dialogue going on between students themselves. We've started to see students competing with each other to be the best engaged in their course. That’s got to be a good thing.

Gardner: And how would they measure that? Is there some sort of a dashboard or visualization that you can provide to the students, as well as perhaps other vested interests in the ecosystem, so that they can better know where they are, where they stand?

Day: There absolutely is. The system provides a dashboard that gives a very simple visualization. It’s two lines on a chart. One of those lines is the average engagements of the cohort on a course by course basis. The other line is the individual student’s engagement compared to that average engagement in the course; in other words, comparing them with some of their peers on that.

We worked very hard to make that visualization simple, because we wanted that to be consistent. It needed to be something that prompted a conversation between tutors and students, and tutors sharing best practice with other tutors. It's a very simple visualization.

Sharing the vision

Gardner: Mike, it strikes me that other institutions of higher learning might want to take a page from what you've done. Is there some way of you sharing this or packaging it in some way, maybe even putting your stamp and name and brand on it? Have you been in discussions with other universities or higher education organizations that might want to replicate what you’ve done?

Day: Yes, we have. We're working with our supplier SolutionPath who have created now a model that is used to replicate in other universities. It starts with a readiness exercise because this is not about technology mostly. It's about how ready you are, as an organization, to address things like privacy and ethics in all of this. We've worked very closely with that.

We’ve spoken to two dozen universities already about how they might adopt something similar not necessarily exactly the same solution. We've done some work across the sector in the UK with a thing called the Joint Information Systems Committee, which looks at technology across all 150 universities in UK.

Gardner: Before we close out, I'm curious.When you’ve got the apparatus and the culture in the organization to look more discretely at data and draw correlations about things like student attainment and activities, it seems to me that we're only in the opening stages of what could be a much more data-driven approach to higher education. Where might this go next?

Research is another area where we might be able to think about how data helps us, what kind of research might we best be able to engage in.

Day: There’s no doubt at all that this solution has worked in its own right, but what it actually formed is a kind of bridgehead, which will allow us to take the principles and the approach that we have taken around the specific solution and apply to other aspects of the universities business.

For example, we might be able to start to look at which students might succeed on different courses across the university, perhaps regardless of traditional ways of recruiting students through their secondary school education qualification. It's looking at what other information might be a good indicator of success in a course.

We could start looking at the other end of the spectrum. How do students make their way into the world of work? What kinds of jobs do they get? And is this something about linking right at the beginning of a student’s university career, perhaps even at application stage, to the kinds of careers they might succeed in, and to try and advise early on those sorts of things that student might want to get involved with and engaged with. It’s a whole raft of things that we can start to think about.

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

Research is another area where we might be able to think about how data helps us, what kind of research might we best be able to engage in, and so on and so forth.

Gardner: Very interesting. Clearly educating a student is an art as well as a science, but it certainly sounds as if you're blending them in a creative and constructive way. So congratulations on that.

I'm afraid we’ll have to leave it there. We’ve been exploring how Nottingham Trent University in England has devised and implemented an information-driven way to encourage higher student retention, and we’ve heard how by gathering diverse data and information, and by making rapid analysis from that, Nottingham Trent has been able to quickly identify students with difficulties.

So please join me in thanking Mike Day, Director of Information Systems at Nottingham Trent University. Thank you, sir.

Day: Thank you.

Gardner: I’d like to thank our audience as well for joining us for this big data innovation case study 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 how one university uses big data analysis to track student performance and identify at-risk students. Copyright Interarbor Solutions, LLC, 2005-2015. All rights reserved.

You may also be interested in:

• Forrester Analyst Kurt Bittner on the Inevitability of DevOps
• Agile on fire: IT enters the new era of 'continuous' everything
• Big data enables top user experiences and extreme personalization for Intuit TurboTax
• Feedback loops: The confluence of DevOps and big data
• Spirent leverages big data to keep user experience quality a winning factor for telcos
• Powerful reporting from YP's data warehouse helps SMBs deliver the best ad campaigns
• IoT brings on development demands that DevOps manages best, say experts
• Big data generates new insights into what’s happening in the world's tropical ecosystems
• DevOps and security, a match made in heaven
• How Sprint employs orchestration and automation to bring IT into DevOps readiness
• How fast analytics changes the game and expands the market for big data value
• How HTC centralizes storage management to gain visibility and IT disaster avoidance
• Big data, risk, and predictive analysis drive use of cloud-based ITSM, says panel

Forrester Analyst Kurt Bittner on the Inevitability of DevOps

Transcript of a BriefingsDirect discussion on what’s making DevOps such a hot topic and steps that organizations are taking to make it successful.

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 thought leadership discussion explores the building interest in DevOps -- of making the development, test, and ongoing improvement in software creation a coordinated, lean, and proficient process for enterprises.

We're here with a prominent IT industry analyst from Forrester Research to explore why DevOps is such a hot topic, and to identify steps that successful organizations are taking to make advanced applications development a major force for business success.

Please join me in welcoming Kurt Bittner, Principal Analyst, Application Development and Delivery at Forrester Research. Welcome, Kurt.

Kurt Bittner: Thanks, Dana. Great to be here.

Gardner: Let’s start by looking at the building interest in DevOps. What’s driving that?

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

Bittner: It’s essentially the end-user or client organizations as they face increasing pressure from competition and increasing expectations from customers to delivering functionality faster.

I was at a dinner the other night, and there were half a dozen or so large banks there. They were all saying, to my surprise, that they didn’t feel like they were competing with one another, but that they felt like they were competing with companies like Apple, Google, PayPal, and increasingly startup companies. Square is a good example, too.

They're getting into the payment mechanism, and that’s siphoning our business from the banks. The banks are beginning to see drops in their own bottom lines because of the competition from ... software companies. You see companies like Uber having a big impact on traditional taxi companies and transportation.

Increasing competition

So it’s essentially increasing competition, driven by increasing customer expectations. We're all part of that as consumers where we've gravitating toward our mobile smartphones. We're increasingly interacting with companies through mobile devices.

Bittner

Delivering new functionality through mobile experiences, through cloud experiences, through the web, through various kinds of payment mechanisms -- all of these things contribute to the need to deliver services much faster.

Startup companies get this and they're already adopting these techniques in large numbers. What we're finding is that traditional companies are increasingly saying, "We have to do this. This a competitive threat to us." Like Blockbuster Video, they may cease to exist if they don’t.

Gardner: Companies like Apple or Uber probably define themselves as being technology companies. That’s what they do. Software is a huge part of what makes them a successful company. It defines them. What is it that DevOps brings to the table for them and others?

Bittner: DevOps optimizes the software delivery pipeline, all the steps that you have to go through between when you have an idea and when a customer starts benefiting from that idea. In the traditional delivery processes, you have lots of hand-offs, lots of stops and starts. You have relatively inefficient processes, and it can take months -- and sometimes years -- to go from idea to having somebody get a benefit.

With DevOps, we're reducing the size of the things you're delivering, so you can deliver more frequently. Then, you can eliminate hand-offs and inefficiencies in the delivery process, so that you can deliver it as fast as possible with higher quality.

Gardner: And what was broken? What needs to be fixed? Wasn’t Agile suppose to fix this?

Bittner: Agile is part of the solution, but many Agile teams find that they'd like to be more agile. They're held back by lack of testing environments. They're held back by lack of testing automation. They're held back by lack of deployment automation. They, themselves, have lots of barriers.

So, Agile is part of the solution in the sense of involving the business more on a day-to-day basis in the project decision-making. It also provides the ability to break a problem down into smaller increments, and at least demonstrate in smaller increments, but it doesn’t actually deliver into production in smaller increments.

Other capabilities

You need to have other capabilities to do that. One illustration of how DevOps helps to accelerate Agile came in talking to a large manufacturing organization that was making the transition to Agile.

They had a problem in that they weren't able to get to development or test environments for months. IT operations processes had been set up in a very siloed way. Development and testing environments got low priority when other things were going on.

So, as much as the team wanted to work in an Agile way, they couldn’t get a rapid test environment. In effect, they were completely stopped from any forward progress. There's only so much you can do on a developer workstation.

These DevOps practices benefit Agile as well, by enabling Agile to really fully realize the promise that it’s had.

These DevOps practices benefit Agile as well, enabling Agile to really fully realize the promise that it’s had.

Gardner: Is there a change in philosophy, too, Kurt, where software is released before it's really cooked and let the environment, the real world, be their test bed, their simulation if you will? And then they do rapid iterations? Are we going to begin seeing that now, as DevOps gains ground in established traditional enterprises?

Bittner: You're right. There is a tendency toward getting functionality out there, seeing what the market says about it, and then improving. That works in certain areas. For example, Google has an internal motto that says if you're not somewhat embarrassed by your first release, you didn’t move fast enough.

But we also have to realize that we have software in our automobiles and in our aircraft, and you don’t want to put something out there into those environments that’s basically not functional.

I separate the measures of quality from measures of aesthetic qualities. The software that gets delivered early has to be high-quality. It can’t be buggy. It has to work and satisfy a certain set of needs. But there's a wide variety of variability on whether people will like it or not or whether people will use it or not.

So when organizations are delivering quickly and getting feedback from the market, they're really getting feedback on things like usability and aesthetics and not necessarily on some critical business-processing capability. Or let’s say the software in your anti-lock braking system (ABS) system in your car. You don’t want that to fail, but you might be very interested in how the climate-control system works.

That may be subject to wide variations. To get better fuel efficiency, you may be willing to sacrifice something in the air conditioner to provide better efficiency. So, it’s largely driving feedback on non-safety-critical features. That's where most organizations are focused. 

More feedback

Gardner: You mentioned feedback. That seems to be a core aspect of DevOps, more feedback between operations, the real world, the use of software, and the development  and test process. How do we compress that feedback loop -- not only for user experience, but also data coming out of an embedded system, for example -- so that we can improve? Let’s address feedback and compressing the feedback-loop.

Bittner: If you think about what traditional application releases do, they tend to bundle a lot of different features into a single release. If you think about this from a statistical perspective, that means you have a lot of independent variables. You can’t tell when something improves. You can’t tell why it improved, because you have so many variables in there.

In the feedback loop with DevOps, you want to make the increment of releases as small as possible, basically one thing at a time, and then measure the result from that, so you know that your results improve because of that one single feature.

The other thing is that we start to shift toward a more outcome-oriented software release. You're not releasing features, but you're doing things that will change a customer’s outcome. If it doesn’t change a customer’s outcome, the customer doesn’t really care.

You optimize the delivery cycle, removing waste and hand-offs to make that as fast as possible with a high degrees of automation.

So by having the increment of a release be one outcome at a time, and then measuring the result from that, you get the capabilities out there as quickly as possible. Then you can tell whether you actually improved because of what you just did. If you didn’t improve, then you stop doing that and do something else.

Gardner: Is that what you mean by continuous delivery, these iterative small parts, rather than the whole big dump every six to 12 months?

Bittner: That’s a big part of it. Continuous delivery is also, more precisely, a process by which you make small changes. You optimize the delivery cycle, removing waste and hand-offs to make that as fast as possible with a high degrees of automation, so that you can get out there and get the feedback as quickly as possible.

So, it’s a combination. It needs not just fast delivery, but a number of techniques that are used to improve that delivery.

Gardner: Folks listening and reading this might very well like the idea of DevOps: "I'd like to do DevOps; where do I buy it?" DevOps, though, isn't really a product, a box, or a download. It’s a way of thinking in a methodological approach. How people go about implementing DevOps? Where do you start?

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

Bittner: You’re right. It's more of a philosophy than a product. It’s not even really a product category, but a bunch of different products, and processes, and to some degree, a philosophy behind that. When we talk to organizations that implemented this successfully, there are a couple of patterns.

First of all, you don't implement DevOps across an entire organization all at once. It tends to happen product by product, team by team. It happens first in the applications that are very customer-facing, because that's where the most pressure is right now. That’s where the biggest benefit is. So on the team-by-team basis, first of all you have to have some executive mandate to make a change. Somebody has to feel like this is important enough to the company.

While developers, engineers, and IT Ops people can be passionate about this, it typically requires executive leadership to get this to happen, because these changes cut across traditional organizational silos. Without some executive sponsorship, these initiatives tend not to go very far.

There's too much wait time when people are assigned to multiple projects or multiple applications.

The first step – and this is sort of very mundane area -- tends to be changing the way that environments are provisioned. That includes getting environments provisioned on-demand, using techniques like infrastructure-as-code to automatically generate environments based on configuration settings so that you can have an environment anytime you need it. That removes a lot of friction and a lot of delays.

The second thing that tends to be implemented are techniques like continuous integration and then, after that, test automation, based on APIs. There's a shift to APIs on an integrated architecture for the applications, and then usually deployment automation comes after that. Once you have environments provisioned in code that you can put into those environments, you need a way to move that code between environments.

As you make those changes, you start to run into organizational barriers, silos in the organization, that prevent effectively working together. There's too much wait-time when people are assigned to multiple projects or multiple applications.

There's a shift in team structure to become more product-oriented with dedicated resources to a product, so that you can release, and do release after release most effectively. That tends to break the organization silos down and start shifting to a more product-centric organization and away from a functionally oriented organization.

All of those changes together typically take years, but it usually starts with some sort of executive mandate, then environment provisioning, and so on.

Management capability

Gardner: It sounds, too, that it's important to have better management capabilities across these silos -- with metrics, dashboards, validating efforts, of being able to measure discretely what's going on, and then reinforce the good and discard the bad.

Are there any particular existing ways of doing that? I'm thinking about the long-term application lifecycle management (ALM) marketplace. Does that lend itself to DevOps? Should we start from scratch and create a new management layer, if you will, across the whole continuum of software design, test, and delivery?

Bittner: It’s a little bit of both. DevOps is really an outgrowth of ALM, and all of the aspects of ALM are there. You need to be able to manage the work, track the work, and to determine what work got done. In addition to that, you’re adding automation in the areas that I was just describing; environment provisioning, continuous integration, test automation, and deployment automation.

There's another component that becomes really important, because out of those applications, you want to start gathering customer experience data. So things like operational and application analytics are important to start measuring the customer experience.

You don’t find one DevOps suite from one company that provides everything.

Combining all of those into a single view, single dashboard is evolving now. The ALM tools are evolving in that direction, and there are ways of visualizing that. But right now it tends to be a multi-vendor ecosystem. You don’t find one DevOps suite from one company that provides everything.

But the good news is that the same thing that’s been happening in the rest of the industry around services and interoperability has happened in applications. We have a high degree of interoperability between tools from different vendors today that allows you to customize this delivery pipeline to give you the DevOps capability.

Gardner: It seems that, in some ways, the prominence of hybrid cloud models, mobile, and mobile-first thinking, when it comes to development, are accelerants to DevOps. If you have that multiple cloud goal, you're going to want to standardize on your production environment. Hence, also the interest in containers these days. And, of course, mobile-first forces you to think about user experience, small iterations apps, rather than applications. Do you see an acceleration from these other trends reinforcing DevOps?

Bittner: It’s both reinforcing it and, to some degree, causing it, because it's mobile that’s triggered this explosion and the need for DevOps -- the need for faster delivery. To a large degree, the mobile application is the proverbial tip of the iceberg. Very few mobile applications stand alone. They all have very rich services running behind them. They have systems of record providing the data. Virtually every mobile application is really a composite application with some parts in the cloud and some parts in traditional data centers.

The development across all of those different code lines and the coordination of releases across all those different code lines really requires the DevOps approach to be able to do that successfully.

Demand and complexity

So it's both demand created by higher customer expectations from mobile customers, but also the complexity of delivering these applications in a really rapid way across all those different platforms. You made an interesting point about cloud and containers being both drivers for demand and also enablers, but they're also changing the nature of the work.

As containers and microservices become more prevalent -- we’re seeing growth in those areas -- it's increasing the complexity of application delivery. It simplifies the deployment, but it increases the complexity. Now, instead of having to coordinate dozens of moving parts, you have to coordinate hundreds and, we think, in the future, thousands of moving parts. That's well beyond what somebody can do with spreadsheets and manual management techniques.

The other thing is that cloud simplifies environment provisioning tremendously and it provides this great elastic infrastructure for deploying applications. But it also simplifies it by standardizing environments, making it all software configurable. It's a tremendous benefit to delivering applications faster and it gives you much more flexibility than traditional data-center applications. There's definitely movement toward those kind of applications, especially for DevOps.

Cloud simplifies environment provisioning tremendously and it provides this great elastic infrastructure for deploying applications.

Gardner: When I heard you mention the complexity, it certainly sounds like automating and moving away from manual processes, standardizing processes across your development test-to-deploy continuum, would be really important steps to take.

Bittner: Absolutely. I would say more than important. It’s absolutely essential that, without automation and that data-driven visibility into what's happening in the applications, there's almost no way to deliver these applications at speed. We find that many organizations are releasing quarterly now, not necessarily the same app every quarter, but they have a quarterly release cycle. At quarterly rates of speed, through seat of the pants and sort of brute force, you can manage to get that release out. It’s pretty painful, but you can survive.

If you turn up the clock rate faster than that and try to get down to monthly, those manual processes completely fall apart. We have organizations today that want to be delivering at weekly and daily intervals, especially in SaaS-based environments or cloud-based environments. Those kinds of delivery speeds are inconceivable with any kind of manual processes. As organizations move away from quarterly releases to faster releases, they have to adopt these techniques.

Gardner: Listening to you Kurt, it sounds like DevOps isn't another buzzword or another flashy marketing term. It really sounds inevitable, if you're going to succeed in software.

Bittner: It is inevitable, and over the next five years, what we’ll see is that the word itself will probably fade, because it will simply become the way that organizations work.

Gardner: I'm afraid we'll have to leave it there. We've been exploring the popularity of DevOps for making sure that development, test, deployment and ongoing improvement in software creation are coordinated, lean, and proficient process. We've heard from a prominent industry analyst at Forrester Research about what’s making DevOps such a hot topic and steps that organizations are taking to make it successful.

Please join me in thanking Kurt Bittner, Principal Analyst Applications Development and Delivery at Forrester Research.

Solutions That Unify Development and Operations
To Accelerate Business Innovation
Get More Information

And a big thank you also to our audience as well 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 what’s making DevOps such a hot topic and steps that organizations are taking to make it successful. Copyright Interarbor Solutions, LLC, 2005-2015. All rights reserved.

You may also be interested in:

• Agile on fire: IT enters the new era of 'continuous' everything
• Big data enables top user experiences and extreme personalization for Intuit TurboTax
• Feedback loops: The confluence of DevOps and big data
• Spirent leverages big data to keep user experience quality a winning factor for telcos
• Powerful reporting from YP's data warehouse helps SMBs deliver the best ad campaigns
• IoT brings on development demands that DevOps manages best, say experts
• Big data generates new insights into what’s happening in the world's tropical ecosystems
• DevOps and security, a match made in heaven
• How Sprint employs orchestration and automation to bring IT into DevOps readiness
• How fast analytics changes the game and expands the market for big data value
• How HTC centralizes storage management to gain visibility and IT disaster avoidance
• Big data, risk, and predictive analysis drive use of cloud-based ITSM, says panel
• Rolta AdvizeX experts on hastening big data analytics in healthcare and retail