devopsy.kinsta.cloud

Tag: survey

  • Cloud Foundry Study Confirms Accelerated App Development

    Cloud Foundry Study Confirms Accelerated App Development

    When it comes to accelerating the development of applications, having a standard set of runtimes can make all the difference. A new study of 753 IT professionals conducted by ClearPath Strategies on behalf of the Cloud Foundry Foundation (CFF) finds a marked decrease in the time it takes organizations using the Cloud Foundry platform-as-a-service (PaaS) environment to develop code—just 18 percent need three months or longer, compared with 51 percent of respondents that don’t use the Cloud Foundry Application Runtime. And, according to the study, the 46 percent of responding companies that use the Cloud Foundry Application Runtime see application development times of less than a week, compared with only 16 percent of non-users.

    Abby Kearns, executive director for CFF, says use of Cloud Foundry Application Runtime has expanded considerably in the last year. Nearly half (45 percent) of the respondent have been using the PaaS environment in the last year. The survey also finds that more than half (51 percent) now have more than 10 developers employing Cloud Foundry Application Runtime, while 28 percent now have more than 50 developers.

    Kearns says those results are noteworthy because it shows that CF is now being used for a lot more than simple proof-of-concept projects. In fact, Kearns notes use of CF to develop a broader range of cloud-native application is increasing. The study finds half of Cloud Foundry users currently use containers, with another 35 percent evaluating or deploying containers.

    Kearns says there’s a high correlation between implementations of CF and adoption of DevOps processes. He notes that often organizations decide to implement CF to force the DevOps issue—a PaaS environment the size and scale of CF requires every process and function within an IT environment to participate in what has become a large-scale continuous application/continuous integration (CI/CD) platform operating at scale. Confronted with that requirement, Kearns says it’s not too long before the IT culture adjusts to that new reality by implementing a new organizational structure.

    CF is not the only PaaS game in town. But via CF distributions from Pivotal, IBM, SAP and others, use of CF has steadily grown, especially among larger enterprises that have the skills required to implement CF at scale. The survey finds that enterprise IT organizations with more than $1 billion in revenue account about half (49 percent) of all CF users. As deployments of the various elements of a PaaS environment becomes more automated, adoption of CF in small-to-medium enterprises should increase.

    In the meantime, IT organizations need think through the amount of time and money developers are wasting using alternative approaches. Not every IT organization appreciates the opinionated workflows that are baked into a PaaS environment. But given the length of time it takes to build applications using other platforms—as well the total cost of maintaining those environments—building and deploying applications at a higher level of PaaS abstraction is difficult to ignore. In fact, managing IT at a higher level of abstraction may eventually prove to be the difference between thriving and merely surviving.

    — Mike Vizard

  • Study: CIOs Want a Chief Data Officer

    Study: CIOs Want a Chief Data Officer

    Quick, what does CDO stand for? Before you say chief digital officer, think again. A new study points to the chief data officer as the more important of the two titles, finding 82 percent of CIOs believe there is a compelling case to hire a CDO in most organizations. The survey, commissioned by Experian Data Quality, was completed by 200 CIOs and 50 chief data officers in June and released in August.

    But while the report stresses the importance of the CDO to companies that want to become data-driven, it also reveals severe challenges for some CDOs, including very high expectations, insufficient resources and, despite the C-level title, a lack of authority to get the job done.

    The survey states that the core responsibility of the CDO is “to define a data-management strategy and translate it into tactical, [achievable] steps for the business.” To make data actionable, it needs to be accessible, accurate and standardized. Here’s a simplistic example of why that is important: Let’s say a data analyst needs to create a report that isolates customers based in New York City. If some of them are listed as being headquartered in NY, NY and others are listed as based New York, NY and still others are in the database as New York City, NY, that’s not standardized. The data analyst would need to realize the data is splintered and needs to be stitched together to get accurate results.

    Making your business data-driven is part of the potential promise of digital transformation. CDOs and their ilk face a daunting task. Transforming data into business intelligence is the alchemy of this age.

    Chart courtesy of Experian Data Quality

    The study identifies three main drivers for hiring a CDO: capitalizing on big data opportunities, creating a competitive advantage and reducing risk on data-driven projects. These roles go far beyond the data management and data governance toward enabling business innovation. Over the next few years, the CDOs surveyed predict that their top business challenges will concern data security, keeping pace with technology advances and managing increasing user expectations.

    Perhaps one of the biggest challenges some CDOs face is the inconsistency across companies of the nature of their role and their stature within the organization. Bottom line: They may not have the authority they need to succeed. The survey reveals, for example, that the average tenure of a CDO is only two years. Many CDOs report that despite their C-level title, they are not considered to be a part of the C-suite. Although 37 percent report directly to the CEO, a larger percentage reports to the CIO, CTO or some other part of IT. That can create some friction because it’s important that CDOs are able to bridge the gap between IT and lines of business—and empower the business.

    Tips for Structuring the CDO’s role

    In creating a new CDO position, the C-suite should be advised of these common challenges faced by CDOs identified by the survey:

    • Staying within budget
    • Keeping up with evolving technologies
    • Knowing how to interpret information
    • Finding/hiring people with data expertise
    • Managing ever-increasing user expectations
    • Balancing the needs of business users and IT
    • Having a lot of responsibility with little room for error
    • Getting pulled into the weeds
    • Maintaining data security

    You should consider extending these responsibilities to your CDO:

    • Having significant control of the management and use of company data
    • Playing an active role in digital transformation
    • The responsibility for enterprise-wide governance and utilization of information as an asset
    • Manager of a team of experienced data employees
    • The purview to implement different approaches to managing data as an asset
    • The purview to generate business intelligence that unlocks and supports business innovation
    • The authority to be recognized by the entire company is the person overseeing data strategy and process
    • Recommend: At least a dotted-line report to the CEO.

    — Scot Finnie

  • Sonatype Report Spotlights Software Supply Chain Issues

    Sonatype Report Spotlights Software Supply Chain Issues

    Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.

    The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.

    Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.

    Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.

    The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.

    By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.

    The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.

    — Mike Vizard

  • Survey: Inviting Security into DevOps Promotes Effective Agility

    Survey: Inviting Security into DevOps Promotes Effective Agility

    Two of the biggest trends in business technology are seemingly at loggerheads with one another. Many companies are under severe pressure to digitally enable their businesses. At the same time, the need for hardened application security has never been more critical than it is now. You can deliver apps quickly and you can deliver apps securely but, generally speaking, the two things don’t happen at the same pace. The DevOps mission is aligned more with development efficiency and agility, but it’s also in keeping with the thinking behind DevSecOps. How are enterprises handling the conundrum?

    According to a new survey from identity and encryption enterprise vendor DigiCert, they are handling it quite well. The recently released “Inviting Security into DevOps” survey found that 98 percent of respondents said their companies are integrating their security teams into their existing DevOps methodologies. The survey found that 49 percent of the respondents are in the process of doing so; the other 49 percent have already done so. Those who report having already integrated security with DevOps are 21 percent more likely to report what might seem counterintuitive: They are doing well at meeting app delivery deadlines.

    “Successful security for DevOps requires a combination of culture building and the right technology,” said DigiCert CSO Jason Sabin. “Companies that can do this and bring in security at the start of a project avoid costly delays, because they deliver their project just once rather than discovering security issues late in the process.”

    The methodology for the survey, which was conducted in May, involved 100 DevOps professionals, 100 IT professionals and 100 security professionals with executive management to management titles skewing 3:1.

    The large enterprises polled for this survey agree it’s worth striving for. Some 88 percent of the respondents called security working directly with DevOps somewhat or extremely important. More than 70 percent of the respondents are concerned that if their companies don’t make this change, one or more of these negative repercussions are likely: increased costs, slower app delivery and increased risks.

    Although nearly all the respondents have integrated or are integrating security within DevOps, they’re not saying it is an easy process. Their top challenges include a lack of a champion for the transition, the security team resists the change, lack of relationship skills required to bring the teams together and it takes much more time than expected—an average of one to two years.

    How should you approach this in your company? First, recognize that it’s no panacea. It’s a logical first step, but don’t spend a year planning it, just do it. Start by appointing or identifying a leader for the project. Someone who understands both sides, ideally, and who knows how to get things done. And install a security lead at the DevOps table for all DevOps business. Integrate, standardize and invest in automating baseline security practices within DevOps workflow. Thinking that way will get you the agility you need.

    Then address what comes next. Have the team identify choke points in the application security process and develop ways to work around them or eliminate them. In other words, attack the problem head on with all your best minds. Don’t forget to look for best practices developed by others. It’s a problem a lot of companies are trying to solve, so networking with people from other companies at industry events may give you your best ideas.

    — Scot Finnie

  • Lack of Continuous Testing Mastery Slows DevOps Progress

    Lack of Continuous Testing Mastery Slows DevOps Progress

    Progress in achieving the maximum benefits to be gained from investing DevOps processes appears to be held in check by a failure to master the art of continuous testing. A new survey of 923 IT and testing professionals published this week by CA Technologies suggests that only 20 percent of the respondents could be classified as “leaders” when it comes to implementing continuous testing.

    A full 93 percent of respondents identified testing automation as important, but only 1 in 5 respondents said they achieved a high level (80 percent or more) of test automation coverage. Seventy-five percent said continuous testing is important as well. Unfortunately, most of the respondents continue to rely on manual processes. In fact, respondents attributed continuous testing challenges to the lack of automation in almost every aspect of the testing process, including generation of test cases through test execution to critical activities such as fast, safe and efficient test data management.

    Scott Edwards, senior director of product marketing for CA Technologies, says failure to automate continuous testing will only lead to an increased DevOps divide. Organizations that have automated DevOps processes not only release more code faster, the report find they enjoy advantages such as:

    • 2.3 times more likely to have succeeded in left-shifting testing activity to developers;
    • 2.6 times more likely to reduce defects by more than 50 percent;
    • 2.4 times more confident in quality of output;
    • 1.9 times more confident in speed of delivery; and
    • 3.9 times more likely to be working in an organization exhibiting rapid revenue growth.

    Edwards says those results indicate that organizations that are further down the DevOps process will enjoy a substantial competitive advantage at a time when organizations of all sizes are realizing how dependent they are on software to differentiate themselves. Organizations may be operating in a variety of vertical industries, but increasingly they are becoming software companies that happen to specialize in a specific area, says Edwards.

    Making that shift requires IT organizations to move away from thinking about developing applications as an art to building what amounts to a software factory, he says. The factory approach not only eliminates silos in the DevOps process, it also should ideally allow developers to continuously test their own applications. Of course, the biggest issue with testing may very well be the simple fact that most developers build applications today using notebooks and workstations that don’t accurately reflect the complexity of the data center environments those applications will ultimately be deployed in. However, thanks to the rise of technologies such as service virtualization and cloud-based development environments, it has become easier to more closely mimic production environments.

    The degree to which an absence of continuous testing impedes both the rate at which applications are deployed in a production environment will naturally vary by organization. But the one thing that is almost certain is that organizations that have mastered continuous testing are much more likely to deliver a quality application experience than those that don’t.

    — Mike Vizard

  • Study: Half of Enterprises Have Achieved DevSecOps

    Study: Half of Enterprises Have Achieved DevSecOps

    The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.

    In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.

    In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.

    Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.

    DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.

    It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.

    Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.

    The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.

    The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.

    — Mike Vizard

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Here are some other DevOps Chats you may want to listen to:

    Node.js Becoming More DevOps-Friendly
    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet
    DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • Survey: DevOps Divide Grows a Little Wider

    Survey: DevOps Divide Grows a Little Wider

    The gap between the number of organizations that have invested in DevOps is starting to narrow, and IT organizations that made the transition to DevOps earlier are starting to see accelerated returns on that investment, according to the latest survey by Puppet.

    The annual “State of DevOps Report” finds that out of 3,200 IT professionals surveyed, only 11 percent were part of organizations that could be considered high DevOps performers. High performers are deemed to have higher deployment frequencies, lower lead times for changes, better mean time to recovery (MTTR) and better change failure rates. The higher performers in this year’s survey are deploying applications 46 times faster than the same designated group of higher performers were last year.

    The survey also finds that higher-performing organizations have automated 72 percent of all configuration management processes. Those same high performers spend much less time (28 percent) employing manual configuration processes. Lower performers are spending almost half of their time (46 percent) on manual configuration.

    Just over a quarter (27 percent) of the respondents self-identified themselves as being part of a DevOps team, according to the survey. In contrast, only 16 percent said the same last year. Puppet CTO Nigel Kersten says those results suggest that understanding of the power of DevOps is increasing. It’s also apparent the early implementers of DevOps processes are enjoying a level of IT agility that is much greater than the average IT organization.

    In general, Kersten says that while much DevOps progress has been made, most IT organizations have automated only various pockets of silos. Developers, for example, may have automated some processes on their own, while IT operations specialists may have developed a custom script to automate the configuration of a handful of servers. Kersten notes IT leaders should be cognizant of the technical debt their organizations are incurring every time different elements of the IT organization employ different tools to automate the same basic processes time and again.

    Very few have automated their operations within the context of a continuous integration/continuous deployment (CI/CD) pipeline, says Kersten. That becomes more challenging to accomplish as new computing models based on containers, for example, are added to the enterprise mix. On a more positive note, Kersten says more processes are being well-defined, as they are bounded by an application programming interface (APIs). Those APIs then become the core technology over which IT automation frameworks are then laid.

    The issue many IT organizations have yet to confront is the degree to which they want to stumble toward DevOps versus implementing a concerted plan of action. Much of the DevOps progress to date has been driven from the bottom up inside many organizations. The time is now approaching for IT leaders to imbue DevOps as a part of the IT culture that permeates the entire organization.

    To one degree or another it’s a safe bet every organization will implement some form of DevOps going forward. The challenge  will be figuring out how to transform all those isolated instances into something more akin to an actual IT strategy.

    — Mike Vizard

  • Fear of Being Left Behind Driving IIoT Investment

    Fear of Being Left Behind Driving IIoT Investment

    It’s said that the industrial internet of things (IIoT) will help enterprises improve business performance and enjoy growth from new products, enhanced and new customer experiences and even new business models. The challenge, as we covered in “The Industrial Internet of Things Still More Promise Than Reality,” is that business leaders still don’t have a clear plan forward when it comes to implementing and benefiting from these new connected technologies.

    Dave Murray, director of thought leadership at BPI Network

    With that in mind, we reached out to Dave Murray, director of thought leadership at the BPI Network, which conducted the survey of 350 global IoT leaders that formed the basis of “The Impact of Connectedness on Competitiveness: Creating Business Value From Operational Insight Driven by the Industrial IoT” report.

    Below is our short conversation.

    Leadership Suite: Based on your research for “The Impact of Connectedness on Competitiveness,” where do most executives stand today when it comes to their vision of the IIoT?

    Murray: They are starting to get their feet wet, and are starting the early stages of implementation or their pilot stages. There is just a tremendous amount of interest out there, and I would say, belief that in the next three years the industrial internet of things will have a significant impact on competitiveness.

    At the same time, I think executives are also saying, “We really don’t know what our long-term strategy should be. We haven’t thought through how this is going to change our business models. We don’t have the talent, in terms of technology integration, data integration and analytics, to get the job done.”

    I think there is a certain amount of concern regarding falling behind. So a lot of companies are just starting to incrementally work on IIoT, mostly with their own products. For instance, equipment manufacturers are integrating sensor technology into their products to improve uptime, and preventative and predictive maintenance.

    Leadership Suite: Do you see apprehension among CIOs regarding the IIoT?

    Murray: Over the long term, I think many executives just don’t know where this all leads, and they are concerned that they don’t know.

    There’s also certainly concern about security. We asked, very directly, “What are your top concerns?” The first three are all about security and who owns the data. And the privacy issue about how much vendors are going to know about their customers.

    After those security and privacy concerns, among large companies at least, the top concern is competitive disruption. There’s a concern about what this going to mean for their industry and their company. Am I going to be disrupted by this technology? they are asking themselves.

    Leadership Suite: If I were a CIO, CEO, or executive that would be a big concern of mine: Am I missing something that a competitor is going to see? Am I going to suddenly fall behind a year?

    Murray: Particularly among large companies, that’s a definite concern.

    Leadership Suite: Do you think widespread adoption and related transformation of IIoT will play out as quickly as people expect now, or might it take longer than many assume? An example that I think back to is the mid 1990s: There was a ton of writing about the death of brick-and-mortar retail back then. And a lot of what was predicted to start happening is really just starting to come to fruition in the past couple of years.

    Murray: I agree. I think what we’re going to see is going it’s to be incremental. It can’t happen all at once. They don’t have it figured out. They don’t have the skills and technologies in place to make it all happen, but they are starting to implement. And I think that will just grow over time. There are many issues ahead. There are issues with standards. There are issues with building up ecosystems to create more compelling offerings. But I think that we’re going to see a significant uptake in the next three years.

    I think it was most large companies who said that they thought that it would have a significant to major impact on their industry in just the next three years. Understanding that there is a big different between expectation and reality in technology adaption. I’m not saying that in three years, the world will look very, very different, but I’m saying we will be much farther along.

    Leadership Suite: I suspect we might be further along seeing IIoT capabilities installed in products and applications, and some tactical enterprise deployments rather than big systemic efforts?

    Murray: I think that’s correct. I think we’re seeing that already. That discreet product-level deployment. But I think that as these companies move forward, they’re going to change business models to provide new services, database services. To provide equipment more as a service than a sale. Then I think that over time, you’re going to see very big deployments that change the face of manufacturing.

    We talked to Airbus and they and all the other aircraft manufacturers have deployed sensors into their planes to improve preventative and predictive maintenance. But in addition to that, it will be deployed more across their products, their aircraft, but also Airbus is talking about the factory of the future. The smart factory. IoT is all about the way they are going to design their next manufacturing process in plants.

    Leadership Suite: Based on your survey and enterprise interviews, what’s your advice on how companies should start thinking about IIoT if they haven’t yet? Or, if they have, what should be their focus?

    Murray: My advice is No. 1 that executives need to know that clearly companies are beginning to take action here. And it very well may be a big competitive differentiator over time. I don’t think companies can afford to wait on the sidelines. I think they’ve got to start to deploy this technology and understand how it may change their business models, and how it can affect their business processes. I certainly think it’s time for industrial companies to take action, although on an incremental basis.

    Just as you say, you look at commerce and retail, and you could envision what has taken place back in 1999. But it took many years to get there, but it’s coming. And companies that aren’t prepared and lag behind will suffer competitively.

    — George V. Hulme

  • The Industrial Internet of Things Still More Promise Than Reality

    The Industrial Internet of Things Still More Promise Than Reality

    New survey finds while the majority of executives expect big things from the Industrial Internet of Things they’re not quite yet prepared.

    The Industrial Internet of Things holds enormous promise to transform business in how they manage their manufacturing processes, streamline their supply chains and directly service their customers. But, to date, that’s all it has largely been: a promise. According to a survey-based report released today by the BPI Network, there is broad consensus that the Industrial Internet of Things will provide significant value in the years ahead, but few organizations are ready to capitalize on the Industrial Internet of Things.

    The report, “The Impact of Connectedness on Competiveness,” conducted by the BPI Network in conjunction with the CMO Council, Penton’s IoT Institute and The Nerdery. Based on an international survey of roughly 350 executives, the report includes insights from companies such as Airbus, Balfour Beatty, Embraer, Philips Lighting, GE, Whirlpool, LafargeHolcim, TVH, Hitachi and more.

    Some statistics and predictions cited in the report are staggering: The business consultancy Accenture predicts that the Industrial Internet of Things will be incremental to the global economy to the tune of $14.2 trillion by the year 2030. GE, meanwhile, estimates the Industrial Internet of Things will improve its manufacturing productivity by 1 percent. And according to Juniper Research, there will be more than 46 billion connected Internet of Things by 2021—a 200 percent increase from last year.

    But at the same time, executives are skittish. “We really don’t know what our long-term strategy should be,” said Dave Murray, head of thought leadership for the BPI Network, in an interview with devopsy.kinsta.cloud. “We haven’t thought through how this is going to change our business models. We don’t have the talent, in terms of you know, technology integration, and data integration, and analytics, to get the job done.

    “I think there is a certain amount of concern of falling behind,” he added. “I think a lot of companies are just starting to incrementally experiment and are starting primarily with their own products. For instance, equipment manufacturers are integrating sensor technology into their products to improve uptime, and preventative and predictive maintenance.”

    Top findings in the report include:

    • Fifty-two percent of executives at large enterprises and 41 percent of executives at all companies expect the Industrial Internet of Things to have a significant or major impact on their industry within three years.
    • Some 55 percent of all executives say the Industrial Internet of Things is gaining adoption within their industries, including both pilots and larger-scale adoption.
    • However, just 1.5 percent of executives at large companies say they have a “clear vision with implementation well underway,” while another 57 percent are either beginning implementation, have pilots underway or are committed and in the planning stages.
    • New products and services lead as the area most companies say they will focus their Industrial Internet of Things investments (35 percent), followed by customer touch points (29 percent), and manufacturing (23 percent).
    • More cost-efficient operations (47 percent), product and service differentiation (36 percent) and improved customer engagement and satisfaction (34 percent) are seen as the top benefits of the Industrial Internet of Things.
    • Security and data privacy are seen as top concerns by executives, followed by the cost and complexity of Industrial Internet of Things adoption and the need for new management and workforce skills and training.

    While most of the executives interviewed, 62 percent, see the Industrial Internet of Things as a rising competitive necessity and are very interested in embracing the Industrial Internet of Things for their business—yet only 9 percent of respondents said industry peers are aggressively pursuing adoption.

    Finally, one of the most surprising, if not startling, aspects of this survey is the finding that less than 2 percent of those surveyed said that they have a clear strategic vision with implementation underway. “I think what we’re going to see is that adoption is going to be incremental,” said Murray. “It can’t happen all at once. They don’t have it figured out. They don’t have the skills and technologies in place to make it all happen, but they are starting to implement and I think that [implementation] will just grow over time,” he said.

    — George V. Hulme