Tag: DevOps

  • Techstrong TV: Scratching the Surface of Testing Through AI

    Techstrong TV: Scratching the Surface of Testing Through AI

    Mark, Torsten and Alan discuss the findings of the “Disrupting the Economics of Software Testing Through AI” report. The report identifies critical factors that hinder software engineering and DevOps teams including the escalating costs of quality control, and growing complexity associated with the increasing release velocity, number of smart devices, operating systems, and programming languages. The video and a transcript of the conversation are below.

    Announcer:                 This is Digital Anarchist.

     

    Interviewer:                Hey, everyone. Welcome to another segment here on Techstrong TV. I am really happy to tell you, introduce our guests for this next segment. First of all, he’s a returning guest with us. He’s from our friends at Applitools. It’s Mark Lambert. Hey, Mark. How are you, man?

     

    Interviewee 1:             Fantastic. Thank you, Alan. Great to have you – for you to have me on. Yeah, great to talk to you.

     

    Interviewer:                Absolutely. And then joining Mark and I today is Torsten Volk. Torsten is – I just drew a blank – EMA, right? Enterprise Management Associates?

     

    Interviewee 2:             Yes, exactly.

     

    Interviewer:                Yep. And we were talking off camera. Torsten is actually a friend of our friend, Andi Mann, who he knew or was his predecessor at EMA 11 years ago.

     

    Interviewee 2:             Yeah.

     

    Interviewer:                And, Torsten, welcome to Techstrong TV. It’s great to have you on.

     

    Interviewee 2:             Thank you very much. It’s awesome to be here.

     

    Interviewer:                Thank you. So, guys, look, Applitools, leader in visual testing. We’ve had, beyond Mark we’ve had many Applitools people on over the last almost two years now of doing Techstrong TV, so I think our audience is familiar. But just in case people aren’t, Mark, how about a little quick Applitools backgrounder?

     

    Interviewee 1:             Sure, yeah. So Applitools is known for inventing Visual AI, so helping software development teams accelerate their releases by mimicking the human eye and brain and how we as humans analyze computer screens, highlighting differences and issues within your UI so you can do not only visual testing, but also fundamentally change and modernize your functional test automation. So it’s really the glue that plugs right into your existing practices, so Selenium, Cypress, we support over 50 SDKs. There’s a free account as well, so you can get in there and get going, kind of feel the water, so to speak. But what we’re seeing is that it’s helping leading brands accelerate their digital experiences, and really it ties directly into the research obviously that Torsten’s been doing around AI and how that can help organizations disrupt the economics of software testing.

     

    Interviewer:                Love it. And, Torsten, look, I know EMA from before 2010 even, but for those folks who maybe, you know, a lot of our audience are technical people. They may not necessarily follow the analyst beat. Why don’t you give them a little EMA background?

     

    Interviewee 2:             My boss describes it always as the industry and analyst firm for enterprise grade solutions, and in the beginning – I’ve been here for a while. In the beginning I was always a little bit wondering, you know, what does that really mean? And what it at the end of the day means is we have all of those emerging technologies coming up, especially in the area of artificial intelligence and cloud native applications and intelligent automation, and what we are looking at is really how can we leverage those capabilities within an enterprise setting. So once the dust has settled and we’ve all gorged ourselves, you know, by consuming the leading edge of all of those tools, the question then is how do I expand that footprint of those tools across the enterprise so that the enterprise as a whole is more competitive in the end. So basically projecting those constraints of all of those cool new products and technologies into the enterprise, that is really what EMA is all about. And my specific practice is focused, as you can see in the background here, as one of my research graphics is focused on looking at machine learning, deep learning, reinforcement learning, and how those capabilities can enhance the enterprise.

     

    Interviewer:                I get it. Great use of the background, Torsten. Thank you. All right. So, Mark, we’ve got all that out of the way. Let’s jump into what we really want to talk on today, and I’m gonna let you kick it off if it’s okay.

     

    Interviewee 1:             Yeah, I’d love to. Thank you. So yeah, so recent report from EMA, and Torsten is the author and I’ll kind of throw the ball to him very quickly, obviously, but really talking about how artificial intelligence and machine learning is revolutionizing the software testing space, and is really important right now because there’s so much buzz around AI, machine learning, and kind of where it comes in. You want to understand where does the rubber meet the road? What is impactful today? What’s impactful for the future? And then what’s, what are the drivers that are getting us there? So I mean, Torsten, I’ll turn over to you, and maybe kind of like talk about some of the capabilities that you talk about in the report and the challenges that they, that you’ve seen come into play.

     

    Interviewee 2:             We started that report by looking at the key pain points, like we start almost all of our reports. Right? What is not sustainable anymore in a specific discipline, and in this case it’s test engineering. And we have pressure factors. One of them is that we, the business needs us to release software a lot more often, and in a really granular manner where somebody’s asking for a feature capability and the software development team is expected to release that thing very quickly, ideally in an ongoing manner. So that is one part, and the second part is that the end users are very, have become very much more diverse than they even were in the recent past, where we have multiple charts where we show the escalation of the number of devices with different screens, different processors, a different network connection, different interfaces for your fingers and for voice control. And all of those things make testing much, much more difficult, and one of my favorite parts always is the little war stories that you get told. Right?

    So in the beginning when we look at al the material that we have, we talk to a lot of developers and test engineers and DevOps guys, and my war stories or their war stories always started with, “Oh, yeah, regression testing, Torsten. That is really not doable anymore. This is kind of a dreamland that you are living in as an analyst if you think that we can regression test all of those releases. It’s just too much, and it would take forever to be able to do that.” So if we can’t regression test, we are running a significant risk, Mark, that something goes awry. Right? We always are sure that in theory things should work, but in real life there are combinations of technologies, of code functions, that they then don’t work. And that’s where we start with artificial intelligence and this whole pair of eyes, Mark, that you are describing, right, where you say, “Oh, yeah, my test engineers don’t have to be that pair of eyes that check through dozens of boxes and just say yes, yes, yes, yes, yes everywhere, and then also overlook some things.

    But that pair of eyes is something more. It’s something that has a certain degree of – when I say understanding, I think I’m gonna embarrass myself, but it has a certain degree of ability to comprehend – maybe that’s the same word – but to pick up things of a similar character and to categorize and cluster things in a manner that makes sense for human beings then to review, Mark. Right? And that is –

     

    Interviewee 1:             Yeah.

     

    Interviewee 2:             – where a tool like Applitools is very interesting, and also unique in the marketplace, right, where it’s a pair of eyes that you guys are building.

     

    Interviewee 1:             Yeah, and I think that talks – I mean your research touches on several different areas where AI comes in, and visual inspection, which is obviously where Applitools fits, is really a highly impactful and the most impactful today of those techniques because it does so many different things. So first of all, obviously there’s the streamlining of the manual review effort. Right? So I’ve got this explosion of devices. How do I check them all? Well, because of the high level of accuracy of Applitools Visual AI, and it’s been trained on over a billion images and has got four nines of accuracy, so what that means is as a human I don’t have to review tens or hundreds of screenshots. I’m just focused in on a very small subset. But that’s just the first part of it, because then you layer on top of that and this explosion of release velocity, increasing device combinations, and as well as the, just the complexity of the application and so many things out of your control, you need help in reviewing the volumes of data and really saying, okay, all of these things kind of look like the same.

    So and then bringing them together. I talk about basically sorting your visual review into different stacks of paper, so for example I might have 76 screens that have a visual defect, but I can break those down into two categories of 40 and 36. And those types of techniques go beyond just the basic pixel dipping approach, which is the one that would be a traditional visual testing technology, and really the ability to categorize that you talk about, Torsten, is the key driver that, or the key foundation that all of these things get built on top of. So it’s a really powerful technique, and as I said earlier plugs right into existing, so you don’t have to rip and replace. That’s one of the things that a lot of AI technology today is say, okay, it’s great, but you have to build it all new in this track. The thing that is really powerful with Applitools is we plug right into your existing frameworks, open source as well as third-party commercial tools, and then we elevate the process with the dashboard to really enable cross-team collaboration. So it’s not just your testers or your test automation or developers that are engaged. Your domain experts, even other parts of the team like UI, UX design, for example, get to be involved in that collaboration process.

     

    Interviewee 2:             Yes, and we see often that communication is key, and it’s not happening in testing where we have those more and more decentralized product teams that are doing their own thing with their own toolkits and pipelines, but they’re not really benefiting from what other teams are finding. And so coming back to that horrible list approach, right, where you have, you check those boxes or you don’t check them. Right? So it’s a very monotonous affair as a human being to review this, but then once you’ve reviewed it usually it comes back to you again and again, and then it comes back and hits other people in that organization because there is no communication and there’s no unified platform to retain that knowledge. Right? And with reinforcement learning, you can teach the system what it needs to come back to a human with, and then what it shouldn’t. So if one team makes decisions, all the other teams are benefiting from that and it’s less and less of this toil type of task where you just also as a human tend to make mistakes and it’s just not scalable. Right? So that whole scalability aspect is an interesting one that deep learning and reinforcement learning brings us there, Mark.

     

    Interviewee 1:             Yeah, you hit on the key things. Right? You’re scaling to meet the current demands of release velocity, shorter release cycles. But the other thing I always think about when I think about AI machine learning and how it can help us from a software quality perspective, it’s an assistive technology so you’re reducing or removing mundane and repetitive tasks, which in themselves are error prone. Humans are great at creative work. We’re terrible at boring, monotonous things  because we miss stuff. Whereas leveraging AI, and especially Applitools Visual AI, it’s highlighting those things. So that same example I talked about, 76 screens, you’re gonna miss stuff. If you’re looking at them all and you’re like, oh, it’s the same. It’s the same. It’s the same. But the Visual AI will identify key differences between the 76 images to really kind of like focus and improve the efforts.

     

    Interviewee 2:             Yeah. And that gets even when you look a little bit into the future, Mark. I know that you can’t share roadmap items, but that whole idea of having a Visual AI can go even beyond just user interface testing, right, where you can do sanity checks in certain areas, where you say, “Oh, yeah, no, that number can never be a billion because of what I know about the data in the background.” Right? And a lot of the things that come through that we continuously see coming through when you release and then you don’t want to be the one in the test team to hold off a, to hold back a release in the middle of the night.

    It’s funny that when I was young and had a ton of hair still, that was what happened, and it’s still happening today just as much, right, where people think, “Oh, no. I shouldn’t be the one who says that. I think it’s all fine. Let’s sign off on that.” Right? So the release data kind of getting mushy and mushy and mushier in those areas, and that ability to say, “Oh, yeah, I had somebody look over it, and something horrible had happened,” some compliance violation or some crazy numbers in the shopping cart that can never add up. Can be even simple things where it’s, oh, this cost a billion dollars, or it’s euros instead of dollars but we are in a certain country. Those are things that you can catch more and more.

     

    Interviewer:                Fair. Guys, I feel like you didn’t let me, I didn’t get much of any words in here –

     

    Interviewee 1:             We feel the same way.

     

    Interviewer:                – but it’s okay. You know, I would – but I try to be a good host and let the guests talk, and you guys had it. Right? This is something, Torsten, you’re obviously very, very passionate and involved in and, Mark, it’s kind of, it’s your life. Right? And so I let it go. However, we are just about out of time, believe it or not, and we went on here for 15-plus minutes on this. But –

     

    Interviewee 1:             Can I just let people know where they can get the report? Would that –

     

    Interviewer:                That’s what I was going to ask you.

     

    Interviewee 1:             Sorry, I just wanted to make – yeah. So –

     

    Interviewer:                Go ahead.

     

    Interviewee 1:             – yeah, go to applitools.com/ema and you’ll be able to download the full report and access all the information there. So yeah, thank you, Alan.

     

    Interviewer:                Thank you, Mark. So it’s applitools.com/ema.

     

    Interviewee 1:             Yes.

     

    Interviewer:                Which also happens to be where Torsten works, at EMA, Enterprise Management Associates. Guys, it sounds like it was a really worthwhile research project here with some really good results and really good findings and insights. Look, this whole, there’s a reason Applitools has been as successful as it has. The whole idea of AI and testing is like peanut butter and chocolate in some way, and we can – but we barely scratched the surface in a lot of ways, right? There’s so much more yet to be done, and looking forward to hearing more about it in the future.

     

    Interviewee 1:             Yeah.

     

    Interviewer:                All right.

     

    Interviewee 1:             Thank you, Alan. Look forward to talking again soon.

     

    Interviewee 2:             Thank you.

     

    Interviewer:                All righty. Excellent. Torsten Volk, EMA, of course Mark Lambert from Applitools here on Techstrong TV. We’re gonna take a break and we’ll be right back with our next guest.

     

    [End of Audio]

  • Developer-led Landscape & 2022 Outlook

    Developer-led Landscape & 2022 Outlook

    Tyler leads the firm’s developer-focused investments and publishes the industry’s most comprehensive market landscape each year. He discusses the developer-led landscape and the 2022 Outlook. The video is above and a transcript of the conversation is below.

    Interviewer:                This is Digital Anarchist.

    Hey, everyone. Welcome to another Techstrong TV segment. I’ve got a first-time guest on Techstrong with us, but he’s a guy, you know, a gentleman who has his kind of finger on the pulse of what’s happening. I want to introduce you to Tyler Jewell. Hey, Tyler, how are you?

     

    Interviewee:                Ah, good morning, Alan. It’s good to be here.

     

    Interviewer:                Cool. Tyler, you know, I said you have your finger on the pulse, but I purposely didn’t give your whole title, affiliation, background, ’cause I was kind of saving it for you. Why don’t you introduce yourself to the audience.

     

    Interviewee:                Oh, I’m happy to do so. So, Tyler Jewell; I am a managing director at Dell Technologies Capital, which is the VC arm of Dell Technologies. We invest about $300 million a year across disruptive companies in the datacenter and enterprise space. You know, previously, I spent 25 years as a product operator and software executive in developer tools companies, including at Stenset, Red Hat, Oracle, and being a CEO of three different startups that have all gone pretty well. And I’ve been an investor, as an angel and VC, for 15 years, across 15 different companies, again, in the developer tools and developer landscape. And starting in 2009, I built a database around companies that make products for developers, and I published it online in 2019, and it now has 1,100 companies in it.

     

    Interviewer:                That’s fantastic. And what is that database, by the way?

     

    Interviewee:                We call it the Developer-Led Landscape, and, you know, we show you the trends in which segments are happening in the developer tool space, which products are gaining steam, which ones are losing steam, and, you know, general insights about how the market is shifting and evolving.

     

    Interviewer:                I love it. What’s the URL? If you don’t mind [crosstalk].

     

    Interviewee:                Oh, it’s at my Substack, so tylerjewell.substack.com.

     

    Interviewer:                Excellent, and that’s a great resource – people should check it out. So, you know, it was interesting, Tyler, I spoke to a few CEOs, already, this week, and a common thing – and a few VCs, I might add. And a common thing I’m hearing is, are we seeing a change in the market conditions, right before our very eyes? One of the large, you know, public PE firms or – you know, we live in a world, today, where the distinction between VC and PE is increasingly blurring, right? It used to be very clear what was a VC and what’s a PE, but one of the large VC/PE firms, look, they took a big hit, this week, on their stock price, right? What effect is that gonna have? Is that gonna put a chill?

    By the same token, Tyler, last week, I interviewed four startup CEOs who all raised $150 million or better, and achieved unicorn status, right. So, it was the best of times, it’s the worst of times, right? [Laughs] I don’t know, look, if I knew, I wouldn’t be sitting here, I’d be off on some, you know, South-Pacific island or something. But, you know, where are we headed? What’s going on? Are we seeing a changing of the landscape? Is it to be expected, an evolution? What’s your take?

     

    Interviewee:                Well, you know, let’s deal with some hard math, to begin with. First, there’s well over 900 companies that have achieved a unicorn status on paper. But when you look at the past year, there was only a handful of companies that were able to get an IPO, in a year, arguably, where the demand for IPOs has been one of the hottest in a long time. And, you know, and then when you look at the global PE market, again, there’s only about appetite for maybe a dozen PE acquisitions in that unicorn range. So, you know, if you’ve got a hot market and 30 companies can get liquidity, really, either through a strategic buyer, an IPO process, or private equity, and you’ve got 900 companies at that valuation range, you’ve got a 20- to 30-year backlog for all those companies to get their liquidity. Or, you know, you’re gonna have, potentially, a correction if those companies need to raise some more cash.

    Now, the flipside of this is that there’s a tremendous amount of cash on the sidelines. Most of these VC funds, private equity funds, have recently raised significant amounts of money; their goal is to deploy that money. They oftentimes have deadlines by which they can deploy that money, and so, there is, you know, a valuation and sensitivity that comes from those companies that, you know, need to deploy the money into what they perceive to be high-quality companies or early-disruptive companies. Now, what we do at Delta Capital, you know, we think of ourselves as early-stage venture capitalists, you know, seed through Series B is our first check-in, and, you know, for us, it really matters that is it gonna be a high-quality team, is it gonna be an emerging and important market, is the product heavily differentiated.

    And in that situation, I think we’ll be a little bit less – we are more valuation-sensitive, meaning, you know, we’re not gonna be as insensitive as some of the others who have a large amount of money to deploy. ‘Cause we don’t have any minimums, you know, so we have the ability to look for quality deals and to, you know, pay what is appropriate given the market conditions that are out there.

     

    Interviewer:                Yep, agreed, you know, I don’t disagree with, frankly, anything you said. You know, but when one hears that number of 900 unicorns in a market of 30, you really get to see, you know, it takes me back to when I first started doing startups in the venture world, right, where, look, nine out of ten venture-backed startups, or eight-and-a-half out of ten, you know, didn’t succeed. They were lucky to get some of their money back, right? [Crosstalk]

     

    Interviewee:                Well, I mean, venture is definitely a boom-and-bust cycle, you know, when you’ve looked at the history of it over the past, you know, it’s been 35 years that we’ve now got a venture capital out there. And taking it back down, you know, to more narrow, what happened in the developer landscape, you know, we were speculating on the potential that we’ve hit peak dev ops as a market condition here. And one of the datapoints that we cited is, last year, in the 1,100 companies that we track, which just, you know, make products for developers, they had, collectively raised $16 billion, last year, across all those companies. And at the same time, that same cohort only had $35 billion in liquidity.

    Now, you could sit there and go, “Okay, well, $35 billion out is better than 19, you know, the $16 billion in,” but really, that number should’ve been 5 times larger, if these things were in balance. You know, that $16 billion maybe purchased, you know, 10 to 15 percent of those companies. And in that $35 billion in liquidity, that was only a handful of IPOs, and the rest was, you know, like, 23 of that 35 was from IPOs, and the rest were from acquisitions. And a lot of those IPOs have been underwater, now, at the beginning of this year, right? So that $35 billion number might actually be a lot closer to 17, at this point in time.

    So, you know, the math just doesn’t add up; something’s gonna have to give at some point in time. You know, that’s certainly one factor. The other factor, you know, facing the developer landscape in particular, when you _____ _____ _____ companies, is that it’s just gotten really complicated to build software, over the past two decades. And, you know, it’s a confluence of a number of factors that are out there. One, you know, the wage growth for software engineers hasn’t grown as fast as the demand for software. It’s pretty remarkable, you hear about all these software engineers who are supposedly making a lot of money, but when you look at the Bureau of Labor Statistics, you know, from the federal government, on what engineers make, it’s been a pretty steady four or five percent linear increase, for the past two decades, on that, and it really hasn’t changed much.

    And as a result of that, there’s been a pretty linear increase in the number of engineers available to work. So, programs aren’t spitting out more talent, companies generally aren’t hiring more talent. So there’s a disconnect between the demand for software, which has been, arguably, on a logarithmic exponential curve, and the supply of people who can do it, right, which is [crosstalk] on that front. So the intersection of this is, “Hey, let’s have a bunch of tools. Let’s have 1,100 tool company out there, to try to help with the productivity of all this.” And as a result of that, we’ve created an ecosystem and an industry that’s really complicated. You know, agile processes are complicated, microservice architectures are complicated, cloud, cybersecurity, you know, huge surface area of attack. And then you’ve got a talent population with only linear wage growth, and this is gonna be an issue, here, this is not sustainable.

     

    Interviewer:                So I gotta play devil’s advocate, if you don’t mind.

     

    Interviewee:                Be the devil, that’s okay, I’ll be the angel.

     

    Interviewer:                [Laughs] Right? It’s a good role. So, number one, I think things have grown more complex, and I think, you know, that is due to an evolution, you know, the continuing development of this whole software development universe we live in, things tend – you know, as you build more things on top of more things, I don’t know if they necessarily get simpler. I think they do get more complex. I also think that the needs of the – the requirements put on the applications that we’re developing, the requirements for what we need this software to do have grown exponentially. And so, as a result, that’s part of that complexity, too. But certainly, developing an application on a microservices architecture deployed via Kubernetes and the cloud is, you know, when we talk about things that are hyper-scalable, right, there’s sort of the mainframe stuff, which is very hyper-scalable, right, probably the most, one can argue, you know, penny for penny, dollar for dollar.

    And then, you know, the scalability offered by these architectures, you know, and you can get into the thing that it’s only the unicorn, you know – I mean the real unicorns: Google, Facebook, Twitter – that need that really hyperscale, right, there’s a handful. But clearly, these are the architectures that do that. And in terms of the amount of developers, I mean, look, unless GitHub is blowing smoke up everyone’s butt, you know, they – something, I think it’s almost, like, 50 million GitHub accounts, today, that developers, if they were a separate country, would be the fastest-growing country on earth. You know, not just US, obviously, you know, I’m talking about global. And then, in terms of compensation, look, I’m not a big believer that the Great Resignation is due to the money being paid to software developers, or cybersecurity people, or dev ops folks, or what have you.

    But I know enough of those people to know they’re making good livings, Tyler. You know, my friends who are CTOs and VP of engineerings are paying good software developers a quarter-of-a-million dollars, and more, and more. And not just those guys in Silicon Valley. New York, Boston, Austin, down here in Miami – you know, we’re in Boca, but –

     

    Interviewee:                There is, you know – you know, first of all, I think GitHub has something like 78 million repos now, right, [crosstalk] probably even claiming 50 million accounts. You know, but there is a massive disconnect between the data that Microsoft and GitHub gets to report and what the BLS statistics, you know, share, right. Which is, you know, the indication of people who are professionally paid, you know, who give themselves some sort of software engineering title.

     

    Interviewer:                But maybe the proliferation of titles says something – I know, Tyler, in our mailing list, you know, we try to mail based on title, sometimes. If I showed you the titles people have, it’s crazy.

     

    Interviewee:                Yeah, you know, look, there could be some title proliferation, but the BLS doesn’t let proliferation, you know, proliferate. And also, it doesn’t reflect international trends, as well. But just in general, when, you know, there’s a lot of struggles and there’s a big gap that exists between people who are professionally paid as talent workers to create software, you know, versus an even larger population of people who aren’t, you know, who have software development skills. And they may contribute to opensource and they may contribute to GitHub, or they may even contribute to some project, you know, but they’re not being compensated for the work that they’re doing, and, you know, they’re doing it for some other motivations, right. So that can explain a huge portion of the disconnect.

    But generally, you know, the software that’s produced to satisfy the demand of consumers, right, or businesses on that, it’s usually gonna be a team, that’s under compensation. Because sustainability of that software, maintainability of that, holding against the SLAs, you can’t depend upon people who are not under contract with you to achieve that. You know, and generally the case, yeah, I think that, you know, a lot of software has gotten so complicated, and the media has definitely portrayed a lot of people who have got, you know, outsized compensation, you know, because maybe they have a unique type of software engineering skillset, or they’ve, you know, risen to some sort of CTO or VP of management position. And I think those stories are gonna continue to persist.

    But when you look at the data in aggregate, you know, for people who identify as some sort of quality assurance engineer or a software engineer or a cyber _____ professional, the aggregate data across the United States hasn’t, you know, been on the same curve as what the storylines would suggest on that. And –

     

    Interviewer:                Yeah, but, you know, to be first-world, you know, first-world problems, let’s be clear, for my audience out there, our audience is developers and engineers and so forth. But when you go down the block to your neighbors and you say, “Woe is me, I’m only making a buck-and-a-half a year, you know, as a cybersecurity admin,” or something like that, and the guy next to you is doing something physical and, you know, making $75,000.00 a year, you gotta be careful, you know?

     

    Interviewee:                Look, I think we’re putting the spotlight on the wrong thing, right. I think the bigger spotlight, here, is that there is a $50 billion revenue industry around the dev tools, right? So those 1,100 companies that we track, they generate $50 billion of revenue a year. That’s going up 23 percent, year over year. That’s $10 billion increasing, a year. And I look at most of that revenue, most of those sales, as companies who are trying to provide forms of automation to compensate for the fact that the global size of the professional engineering pool isn’t large enough, right? Now, you know, and this market has gotten _____ fragmented. You know, 5 years ago, there was only half, there was only 550 companies.

    So, you know, that market’s a lot more fragmented, there’s a lot more competitors, that’s adding to the confusion and the issues that are plaguing productivity and the engineers. Now, on the flipside of it, you know, I would also argue that we’re not doing nearly enough on advocacy, in that we should have three to four times as many professionals working in the software space. And there’s a lot of reasons why people are unable to become professionals in the software space, as well. It has to do with STEM education, there’s misogynistic and discriminatory behaviors that keep people out of the space. It’s also the complexity of the technology; there’s still a high degree of math and science that tends to be required.

    And those things are also acting as barriers, here. And so, the flipside of this is, that’s why we have this $50 billion industry, this cottage industry, around trying to make people more productive, because we’re compensating for the fact that there’s just not enough people, and we’re not doing enough to get more people into the industry.

     

    Interviewer:                I don’t disagree wholeheartedly, there. Here’s my take on it, though. There’s two ways of approaching the issue of we need everything – every company’s a software company, right, and we need more software. Either we’re gonna have more people doing software, which is, you know, a big shift, lift and shift, or we gotta, you know, to paraphrase Matt Damon _____ _____, we gotta automate the you-know-what out of it, right? Probably, we need to do both, right? But I would say, also, when you look at – let’s take opensource software, right? You and I have both been around a long time. I remember, you know, talking to doomers at army bases who told me that they were never gonna – you know, they don’t allow opensource software onto the network.

    I’ve been in enterprises where I was told that. Today, 90-plus percent of enterprises are probably running opensource, you know, somewhere in the network. But more than just, like, running Linux or something like that, so many of the components of today’s software are, you know, opensource-based. And you’re right, there’s not a professional opensource – well, maybe there is – is there a professional opensource engineer community today? Is it enough to support it? I mean, I don’t know.

     

    Interviewee:                You know, look, are there individuals who can just be professional opensource contributors and make a living off that? In some pockets, there are, particularly the people who focus on identifying bugs and security vulnerabilities, you know, [crosstalk] a different thing.

     

    Interviewer:                Yeah, that’s a subset. No, but I’m thinking, like, Tyler, look at CNCF, for instance, [crosstalk] Linus Foundation.

     

    Interviewee:                Yeah, but almost of that is professionally paid people, and anybody who, you know, works on a major project, even if you do it for free, at some point in time, there’s probably gonna be a commercial entity supporting that. And that commercial entity is gonna wanna hire the top contributors to that project, right? So there is, effectively, a professional path, you know. Now, whether that individual does not wanna be associated with the commercial entity, that’s more of a, you know, societal or a personal issue that they deal with, there. But, you know, but back to the complexity thing, you know, and a little story, here, for you, you know, it’s great that we – you know, 20 years ago, only 15 percent of software was opensource, right, 85 percent of what was built was coded, 15 percent was composed.

    Now, the statistics show that 85 percent is composed and 15 percent is just, you know, the glue layer that pulls it all together, so it’s a wonderful thing. But, and you talked about that trend of, like, “I’ll never have opensource in my environment,” but the natural conclusion of all this complexity is that we – you know, we are of the mindset that there’s gonna be a bit of a crumbling of the dev ops market as a whole. Because the software process and the architecture has generally gotten to be too complex for a human to reason about the impact of a change. There’s too many moving parts, right? It’s like asking somebody, “What will happen if I walk up to this ant hole and I stick this stick into it? What will occur?” you know, you just can’t predict it, right?

    And so, the only way to reason about that complexity of change is that you have to give it to a machine. You know, machines have the ability to reason about those sorts of changes. So the natural evolution of – and the last thing I’ll say with that, too, on the complexity front is that the prevailing paradigm for how software teams should be organized, for the past 20 years, has been agile. And the fundamental premise of agile is that quick changes and quick feedback make for a happier team and happier end users, right? Well, if you take that to its natural conclusion, you know, you’re making changes all the time, you’re getting feedback all the time, which in theory, you know, gets everybody to be happy. But what ends up happening is that the team gets burnout, _____ _____ gets overload, and then, you know, it turns into this frenetic energy that is not sustainable.

    So, agile is a fundamental part of the program, you know, that we’re gonna lead up to. And instead, we need to focus on a way to have sustainability of the development team, and that we remove the complexity by focusing on machines who do the automation for us. And so, I think that what will happen is, much the way that, in the industrialization, you know, we turned an agricultural society into a machine society, the same thing in the software industry is that we’ll go through a software industrialization, where most of the engineers who are writing code, i.e. they’re farmers of code on that, will turn into orchestrators of machines on that. And so, we’ll have to step back, as an industry, and we’ll be programming bots who will actually write the code, make the changes, give us the feedback.

    And that means, you know, machine learning throughout this whole industry. And then, you know, retooling the software engineering community as we understand it, to become orchestrators of the system, as opposed to, you know, farmers of the code.

     

    Interviewer:                You know, it’s funny, I remember speaking to Luke Kanies. Luke is the cofounder of Puppet. He said there’ll be a day when software writes its own software, but he thought it was 25 years ago, and that was maybe 5 to 8 years ago. Tyler, we gotta run, but here’s what I’d like to do, ’cause this topic needs a wider playing field to play on, and we need more opinions. We do a video show called Dev Ops Unbound. It’s 45 minutes to an hour. We put together a panel of people, anything related to dev ops is fair game. If you don’t mind, I’m gonna have our people reach out to you. Let’s get you onto Dev Ops Unbound. I’d like to get some proponents, opponents, let’s really kick this around.

     

    Interviewee:                Sure.

     

    Interviewer:                ‘Cause I feel terrible we don’t have enough time to really dig into this the way I’d love to, but I think we got people in the waiting room. [Crosstalk], hey, for people who maybe didn’t catch the beginning of this, where was your repository of the dev tools [crosstalk]?

     

    Interviewee:                It’s at my Substack, so tylerjewell.substack.com. You see the Developer-Led Landscape, there. And also, you know, we’re active investors in this space, you know, come check us out at Dell Tech Capital.

     

    Interviewer:                Yup, and Tyler Jewell, for those who wanna know, T-Y-L-E-R, obviously, J-E-W-E-L-L.substack.com. Go check that out. Tyler, we’ll be in touch with you. Let’s continue this conversation.

     

    Interviewee:                Yeah, see you later, Alan. Thanks for having me.

     

    Interviewer:                Thank you. A pleasure. Tyler Jewell, Dell Technology Ventures, here on Techstrong TV. We’ll be right back.

     

    [End of Audio]

  • Applying TestOps to Cultivate a Quality Culture

    Applying TestOps to Cultivate a Quality Culture

    Quality assurance is a universal concern, especially when it comes to application development. Enterprise applications are faster and more reliable than ever before. However, in addition to performance, application developers also must consider data security, regulatory compliance and cost-effectiveness, among other things. Organizations are embracing quality engineering (QE) as a foundation to create a software quality culture to address these challenges. Creating a quality engineering or TestOps environment is not simple, especially when QE departments must test for hundreds of applications across multiple enterprise environments. Whether it is a solution provider or a multinational corporation, applications often need to be tested across platforms, industries and geographies.

    TestOps encompasses a broader concept than just QE. With TestOps, there are testers and engineers using automated and manual testing to validate software for flawless application performance. In enterprise DevOps, the TestOps team serves as the bridge between development and deployment since they have a good understanding of the applications and a better perspective on the context and variables that can affect performance.

    Continuous testing is an integral part of any software development cycle. Quality engineers must be brought in early as part of Agile development to keep development on track and head off any problems that could escalate or become harder to resolve later. In Agile, testing becomes more crucial and frequent to ensure flawless performance.

    It pays to think horizontally when setting up a TestOps approach. For example, testing should be performed across different vertical environments such as media, manufacturing and finance. The goal is to create a test environment that can accommodate various industries.

    TestOps Across Environments

    In the age of SaaS and universal data access, it is essential to test across multiple platforms. In addition to ensuring enterprise performance, mobile web and remote data access must be tested. For streaming services, it is vital to test across mobile platforms, over-the-top (OTT) platforms such as Roku, Apple TV, Android TV and Fire TV, and even gaming consoles like PlayStation and Xbox.

    When shipping software updates, geography matters (especially when shipping across time zones), as one may never know when the software will be used or have control over the environment where they plan to use it.

    For instance, consider the challenges a leading mortgage lender faced with mobile application testing and how geography was a factor. First, Google Analytics was used to assess specific device and user requirements and ascertain performance in various parts of the United States since different regions use different carriers. Testing was then done across mobile platforms such as iOS, Android and combinations and across carriers since most banking and mortgage applications required one-time passwords (OTPs) and SMS-related capabilities. Further tests were implemented for new identity authentication strategies such as biometrics and facial recognition. Finally, performance testing by geography was conducted to determine whether a new feature or version would create issues.

    Testing for Geographies and Regional Compliance

    Localization testing is important since every region and every country has unique compliance issues and laws. To ensure proper localization, it is essential to perform complete testing, including lower environments and production systems.

    In any TestOps environment, the philosophy of continuous testing should already be part of the design environment, including understanding the nuances of production. Release readiness does not mean there are only a few known bugs in certain regions. It means the application has been tested for compliance in every geography where it could possibly be utilized.

    Testing Across Industries

    Testing application performance in specific industry settings brings along its own set of unique challenges. In manufacturing, for example, each sensor in an IoT device must be modeled against a conformance specification to determine if it can be automated using simulations. In media, one needs to test for different platforms, content management systems and business workflows.

    To accelerate time to market, one would want to support a dual-shift development lifecycle to gauge the consumer experience and get continuous feedback and also need a test environment with multiple automation tools such as Selenium, Appium, Cypress, Tricentis, UiPath, Test Complete and Winium.

    Artificial intelligence (AI) plays a larger role in testing, shortening time to market, and ensuring superior quality software. AI-driven test tools are optimized for domain-specific applications, such as testing for industries like media, manufacturing and fintech. AI can fill in the gaps to achieve optimization and offer a quicker turnaround with limited manual intervention.

    Any organization cultivating a TestOps culture needs to have specific technologies and tools in place. When assessing your testing technology stack, it is important to create an end-to-end testing ecosystem. This means the environments must be inclusive and capable of incorporating testing for unique applications, environments and scenarios. To support the needs of today’s Agile application development environment, one must plan for an agile testing infrastructure to keep development on track.

  • Techstrong TV: Value Stream Management & Value Creation

    Techstrong TV: Value Stream Management & Value Creation

    Lance Knight, ConnectALL President and COO, joins us directly from the Agile 2022 conference. Lance discusses the concepts of value stream management and value creation. The video and a transcript of the conversation are below.

                                         

     

    Mitch Ashley:            I have the pleasure of being joined by Lance Knight. Lance is COO and president of ConnectALL. Lance, good to be talking to you.

     

    Lance Knight:            It’s great to talk to everybody here again. It’s great to meet you as well.

     

    Ashley:            Nice to meet you. I know you’ve had a lot of conversations with Allen and great opportunity for me to have a conversation with you, too. For folks that might not know you or have seen you before, tell us about yourself and of course ConnectALL. Tell us a little bit about that.

     

    Knight:            Well, you know, I hardly ever done that before, told anybody about myself. But anyway, I’m Lance Knight. I’m president and CEO of ConnectALL. And you know, we’ve been around ConnectALL for a while. We’ve been spearheading in maybe in the forefront of this value stream management market and we’re excited to be part of this fun ride that’s value stream management. It’s been an interesting ride for me for years. I’ve been in this space since even before it was value stream management for years now. Just excited to see it grow and excited to be a part of___.com and we recently got nominated. It’s part of the 12 for value stream management solutions. So appreciate that. Yeah.

     

                                     As for myself, more about myself, you know, I’ve got a wife, a kid. I’ve got three kids. I’m just kidding now. But lots of cool things happening in our industry now.

     

    Ashley:            It’s fascinating I think one of the things that is fascinating about value stream management is it’s emerging but it’s been around for a long time. It’s not like it’s new. It’s in the manufacturing and you go back to the goal and all. You know, a lot of other things and Toyota. So it isn’t a new concept, but it is as we apply it to software. What do you think it’s now is the time for value stream management? I’m really curious. Obviously you made a big decision of you’re CEO of this company and that’s what you’re focused on. Why is now the time you’re going to be able to make this happen?

     

    Knight:            First, you know, you’re so right and I’ve said this quite a bit, is, you know, I started my career in manufacturing, dong value stream management work, understanding leans, systems thinking, all of those things to improve how manufacturing happened. And what I think is now as you take a look at what happened with Agile, what’s going on with DevOps, and the way that people are developing software, they’re thinking how do I make this even better. And I have a whole bunch of opinions why now. One of those is maybe a little controversial, is the goals, aims, and means, and the great vision of what an Agile transformation was supposed to do with my organization was never truly achieved.

     

    Ashley:            You mean it got overhyped and oversold?

     

    Knight:            Overhyped, oversold. It only really talked about how developers to work better. It never, you know what I mean?

     

    Ashley:            Oh, I totally know what you mean.

     

    Knight:            My organization has spent millions of dollars on these coaches and transformational people, and now you want me to do that with DevOps too and build a community and feel good about it, and sing Kum-Ba-Ya.

     

    Ashley:            [crosstalk] solve that for us, didn’t- Agile solved that for us too before that and you know, this succession.

     

    Knight:            Yeah, right.

     

    Ashley:            It’s an evolution, right.

     

    Knight:            And I see a little of that bleeding into value stream management, but I think why V.S.M right now, because it makes you look at your end to end flow. It makes you understand how you’re deciding what to do. Makes you look at how co goes through things. It’s a little more logical, not that those other ones aren’t. But it’s more specific. It’s got an age old set of things. And business people, the ones that make decisions on things can wrap their head around it. All right, so someone puts a request in here, it goes here. It goes through our agile processes. What do mean? I can finally get these reports to tell me how efficient my teams are? I think that’s what’s driving a lot of it. And ConnectALL we call it see, measure, automate. I can see my value stream now. I can measure and I can automate.

                                       

                                     And I think that’s just one reason why it’s taking off. And I think there’s some other ones. You know, well, we do agile, DevOps, value stream, what are we doing and how does this relate? And at ConnectALL we say this all the time, so it’s really interesting. Value stream management is a human thing. It’s a human endeavor. We talked earlier it’s been around forever with manufacturing. We didn’t have machines and computers out there measuring our value stream. We went and did that. We improved the flow. We looked at how parts moved around the shop floor. We mapped it. And we had some tools to help us. And a value stream management platform that’s what they’re there to do, help humans be more effective with managing requests to code in production, connecting it and automating the processes within it.

     

    Ashley:            yeah, there’s this phrase I heard, I don’t know where from. You know, you want to work on the business not just in the business. In other words, you have to sort of, that’s about continuous improvement, whatever that might be. But you have to understand it first. You have to be able to measure first. Where do we go improve. Another thing I wanted to run by you is I think one of the reasons why value stream management gets a lot of attention is we’ve elevated the value, the strategy behind software and how much that is importance of that to businesses, how much they’re counting on our ability to deliver. But you know, gone are the one year, 90 day whatever projects where you know, we think we’re going to get this spec, but we never do and something else pops out. And now we’re doing lots of little smaller races. How does a business know if I put a quarter in here I’m going to get my quarter’s worth of what I thought I was going to get there and how we can manage that process to help achieve those results? Is that fair do you think?

     

    Knight:            That’s fair too. And I think that’s another reason why it’s taking off right now, right. You know, my controversial point, but then there’s this other point of I’m never- I’m an executive. I’m over an organization. I’ve never seen what I’ve had move quick enough, move through. What are the bottom numbers? It’s invisible to me. Right? I have an initiative and I know I need these capabilities. I need this software. I need all these things. And as I’m saying that I’m watching just this initiative that’s an artifact in some system, I don’t know if that’s moving forward. I don’t know if I’m blocked. It’s a black box to me.

     

                                     And value stream management kind of opens some of that up as you kind of look at flow. And then also like you said earlier, how am I prioritizing that? I’ve got technical done. That’s really important to repair. But how do I prioritize that rather than somebody saying I need to fix this technical debt. Where you could look at it and say, not yet. This is more important than that. This new capability to make me competitive in the market is more important than if I fix that technical debt today. And those decisions aren’t able to be made at the right levels. And it’s also strategy execution where I can go and to sign my outcomes I want and my initiatives. And then have those get executed across all the organizations, because we have all this visibility and track it.

     

                                     So that’s the see part. And also the measure part where you talk about measuring. I can say, all right, now I’ve improved our processes by 25%. So now I can move quicker. The only thing that I think value stream management we have to be careful of is I don’t- and I’m seeing some of the other analyst firms do this. It’s not DevOps value stream management. It’s value stream management. And DevOps things are a part of that value stream.

     

    Ashley:            We have a value stream whether you’re doing DevOps or not, right?

     

    Knight:            You know, at ConnectALL my head of products says there’s a value stream now. Every company has it. You may not be aware that that is a value stream, but it is.

     

    Ashley:            I think it’s just been more elevated to our consciousness, right, because of DevOps.

     

    Knight:            Or more aware of the flow of value through it. Right. So, it’s interesting as it takes off and goes next stages of it and so on. I just want to make sure it stays the highest level thing from an organization perspective and that’s your value stream, right. You have DevOps tools of course and those are part of your value stream also. I just did a speaking slot somewhere about value stream management is not a feature and I went into that whole thing about how value stream management isn’t a feature of a tool or another tool. It4 is what you do and the tools and the platforms how you be more efficient. So it’s a different take I think than a lot of organizations have on it as they try to figure out how to build the best value stream feature in their product.

     

                                     So ConnectALL we have value stream management platform. It lets you see, measure and automate but if you’re not educated on systems thinking, lean principles, we can do some little stuff, but you would have to map it, use area waste principles, lean principles to think it through, right. I’ve got some mooda, if I used the word right. Maybe we’ll get some text about he said that wrong, which I probably did. Which anyway, that’s waste. And then you could go figure out how to fix that. Why am I having these things?

     

                                     So yeah, I mean I think it’s going to take off pretty well in organizations need to do this now because software is no longer that thing that that guy in the corner called Lance programs so that you’re more efficient in some of the manufacturing stuff you’re doing.

     

    Ashley:            Reminds me of, well, Jim and I first worked together in security. Security we evolving from sort of the people nobody knew that did this thing behind the scenes and couldn’t talk to them because they didn’t know what it was about, to more everyday people, system administrators, network administrators. And so you had to really think about the barrier to entry, right. Do you have to be a lean expert to do value stream management? Or can you step your way into it so there’s the whole idea for barrier to entry for your products? And how do you make that lower to get people started? And I know you had I think an announcement recently for ConnectALL. Can you tell us about that?

     

    Knight:            Yeah. So first, so you don’t need to be a lean expert to do it. Just have to maybe read a little white paper on it. And understand just the basics of it and it’ll help you through. So what we have done if you’re referencing to the fact that, and one of the reasons why we wanted to do this is that ConnectAL is going to offer a free online value stream management visualizer, designer where you can log in, put all your tools on there, draw the boxes of flow, decide what kind of flow loops you want, and just lay out your whole value stream, that’s actually yes, that’s’ what we have. That’s our big announcement coming next week is the free online value stream design. And it’s a nice little drag and drop environment where I can just drag on my tools. It’s going to have all the different tools on there, and then I can draw lines between them. I can set up my swim lanes, my boxes. We can do all kinds of things in order for you to lay out your value stream. You can name the links. You can name it so it’s personalized. You can put notes in there. And then it’ll give you a  PDF view of your value stream that you can export, you can go around and share that with your manage- here’s how our workflow works. And it comes from the years that I’ve been doing value stream management workshops on a big whiteboard, but we’re not getting together these days for these big whiteboard sessions. So you know, it’s got these different pallets and you can do all these things so that you can actually get a good vision to see your value stream and how things are flowing. And we’d be happy to help you lay that out if you wanted to get on with a session with one of our session architects to walk you through it. You can save them because maybe multi-session thing. Export them and share them with other people that can load it into the free value stream from their computer. And we’re really excited about it because I think it’ll really help people understand how they can use just this one part of value stream management.

     

    So you know, at ConnectALL we’re all about helping the humans be more effective at this, right. And it’s just a great opportunity for anybody’s interested in getting involved in value stream management to have a place where they can go just lay it out. It’s pretty robust. There’s some cool things. Yesterday I was messing with it. I drew a turkey in it. So, you know, Thanksgiving’s coming. So, we drew this little turkey in there, right. Somebody will probably do a Christmas tree as well. But the cool thing is I know some people will probably be like well, I can do that with this tool and this tool. That’s true you can. However, this one’s also free and we’re going to have all of the images and icons of the tools and the flow icons and all of those things preloaded so you can just drag and drop on there. And you’re off to the races of being able to start to tell the story around how you can improve value stream within your ___.

     

    Ashley:            Looking at things systemically, even if you think you know the system, the process really well, at least my going through things like that, you just go, I don’t really know what happens here. I kind of do but I don’t really know. So you can learn that or figure that out or somebody who’s mapping this out. And then to your point is once you’ve got that, now you’ve increased your understanding of what we do or the flow of what we do, where do we work? Right, you’re going to go with the theory of constraints and let’s look for a bottleneck. Let’s look for you know, we need a future over a technical debt is where value is. And you start to connect it into a system of creating software, which is I imagine more of your- the paid version of ConnectALL.

     

    Knight:            Well, so paid version will operationalize your connections. We can actually, you’ll see the flow of work and we do the integrations, the connections, the triggering, the capturing. We offer all the tough stuff the V.S.M. platform can do at ConnectALL. And normally for these talks I don’t talk much about our great product which is really, really great. We got a brand new release, 2-11 coming out that has some great- I’m using platitudes by saying great, but it has some really great features coming out in the future.

     

                                     Usually when I talk I want to help the industry. I want to help the space. And that  helps me of course. But here this free tool will get you up and running. You can see, measure, you can do some measurement stuff in there. And actually you can put your measurements in there and actually tell a story to your boss. So I was on a conference recently and someday said, well, to do value stream management you need to you know, go talk to your boss and have him approve the project and build a little community and figure out how you’re going to adopt value stream management principles and do all this stuff. And I started to feel like here we go again with community and adoption and the feel good part of it.

     

                                     And all of that is really relevant when you think about agile, when you think about DevOps, that is relevant. DevOps is a culture shift. And a culture shift, I’ve spoken on this before, is transforming operations and DevOps to work so well together and when operations is normally commanding control, right, can’t have access to those servers because this reason. I used to be that guy, so I can speak to it with great understanding. And having people change that mindset and culture so they can collaborate better, this is not. This is value stream management. You map the value stream. You look for waste. You point it out. You try to figure out how to remove it. And you work with people to do it, don’t get me wrong. But there’s no sprints. There’s no ceremonies. Once you’ve done it, you look at it, figure out how to improve it. You improve it. You modify your map. And by the way you can save these and come back. And then you look for the next place to improve flow. I’m for the other stuff. I’m just saying this is not. This is value stream management. It’s lean thinking. It’s been around forever. Doesn’t require all this other stuff, go do it.

     

    Ashley:            I think from an end user perspective I would think that now having a way of dipping my toe in the water, maybe more than that to really understand what’s going on. And I can decide. Now I can decide to go to the next place, whatever that looks like with ConnectALL.

     

    Knight:            Yeah. I go map it out and then I can talk about it.

     

    Ashley:            Not making a big bet that this thing is going to do stuff for us, but I just don’t know. Right. You know, you’re going to get value unintended.

     

    Knight:            So we’re really excited about it.

     

    Ashley:            Well, congratulations. When this airs actually I think it’ll be when this is released. So, how do folks get ahold of this? Is this ConnectAll.com?

     

    Knight:            Right, ConnectAll.com you’ll see a link there in the home page to go to designer and it’ll come up. We’re not looking for tons of lead information. We don’t want to know how many people run your company and you know, got control over that. I mean all we want is maybe an email and you’re off to the races and you can save them and do all the stuff. And just use it to take that first step. And we have some partners who are using it to run consulting sessions and different things like that. So, I think it’s something that nobody’s done yet. I think it’ll really help move value stream management forward.

     

    Ashley:            Great. Well, congratulations on the launch of this entry point, the value stream designer. And definitely I’m going to check it out. So, appreciate-

     

    Knight:            I’d be happy to walk you through it. I’ll send you a quick copy of the turkey we made.

     

    Ashley:            I would love to see the turkey. All right, Lance. Lance Knight, CEO and president with ConnectALL. Thanks for joining us today, Lance.

     

    Knight:            Thank you.

     

    Ashley:            Take care.

     

    [End of Audio]

  • EP 29: Bringing Data Integrity to DataOps – DevOps Unbound

    EP 29: Bringing Data Integrity to DataOps – DevOps Unbound

    In DevOps, we frequently use a variety of tools to help manage the entire software development lifecycle. But with an immense amount of data coming from so many different sources, this introduces a question of integrity of the data. DataOps is key to efficiently detect changes faster while minimizing risks and ensuring data quality and security. Host Mitch Ashley is joined by Curtis O’Dell (Tricentis), Arun Moolchandani (Narwal), Divanny Lamas (Transposit) and Andrew Hughes (Trimedx) to explain how DataOps helps organizations speed up development, reduce the cost of deployment and monitor their data’s integrity, ensuring the transparency of data operations and maximizing productivity and efficiency in the business.

  • CPRA for Developers: Road to CCPA 2.0 Compliance

    CPRA for Developers: Road to CCPA 2.0 Compliance

    California voters passed the California Privacy Rights Act (CPRA) in November 2020. It replaces the 2018 California Consumer Privacy Act (CCPA) and is often described as a cousin to the EU’s GDPR law. The law applies to all for-profit organizations within the state. It also requires compliance from anyone doing business in California or collecting data from the state’s residents.

    Since the CPRA focuses on data protection, it applies to developers who deal with customer data or develop websites handling customer data. Building good-looking apps and websites that deliver a great user experience is no longer enough; data privacy must also be part of the equation.

    With that in mind, let’s look at everything developers need to know about achieving CPRA compliance.

    CPRA Compliance Checklist for Developers

    Here are the main compliance points organizations need to adhere to:

    • Have a process that allows customers to exercise their right to correct personal information.
    • Have a process that enables easy opt-out for customers regarding advertising and data sharing.

    Before or during consumer data collection, organizations must disclose:

    • The categories of data gathered and whether the data will be sold or shared.
    • How long the organization plans to keep the data gathered.
    • How the data will be used for targeted advertising and how users can opt out.

    Organizations mustn’t keep personal or sensitive information longer than necessary to achieve the disclosed purposes.

    These are just some of the compliance checkpoints. For more details on the CPRA responsibilities for businesses, visit the Californians for Consumer Privacy website.

    The Risks of Non-Compliance with CPRA

    CPRA compliance is costly, but non-compliance can lead to even heftier penalties. The California Privacy Protection Agency (CCPA) is a new agency responsible for enforcing the law. It will give out fines of $2,500 for inadvertent non-compliance and $7,500 for intentional non-compliance. The penalties will increase significantly for abusing data belonging to persons under the age of 16.

    Apart from financial losses, non-compliance is risky from a reputational and consumer trust standpoint. In the event of a data breach, these factors may even be more damaging than the fines.

    The Importance of the CPRA for Developers

    App and web developers have long prioritized deadlines, user experience and other factors over security. This is because they tend to focus on elements that improve engagement and keep users coming back. The CRPA puts a significant limit on data gathering, not only for customers but also for employees. That significantly changes a developer’s approach. 

    The new law requires developers to take a privacy-first approach throughout the software development life cycle (SDLC). This requires a complete mental shift for most developers, and it will take time to attain. Security is no longer a client request; it’s a mandatory requirement.

    Security, privacy and transparency must become focal points for software developers. These elements should influence every decision they make throughout the SDLC.

    For existing systems, the CPRA means operational and system updates relating to data gathering and storage, security and governance. Developers will have to adjust systems to gather the bare minimum of data, as the law encourages. 

    Data anonymity capabilities are also required. Data that isn’t crucial for app or website functions should be anonymized to reduce the risk of a data breach.

    Developers should focus on creating apps that:

    • Track data throughout its life cycle.
    • Anonymize data when possible.
    • Get rid of old, unused data.
    • Allow for easy data sharing across the organization.
    • Incorporate CPRA compliance best practices for developers.
    • Perform a gap analysis.

    Gap analysis is the process of determining whether the current system satisfies the desired or mandated requirements. A gap assessment will give developers a clear picture of any existing compliance gaps. For non-existing systems, a gap analysis will help determine how the new system can fulfill requirements. 

    A gap assessment will also determine whether the CPRA applies to your organization. For instance, if your organization doesn’t collect consumer data, the CPRA may not apply to you.

    Set Clear Timelines for Reaching CPRA Compliance

    Reaching CPRA compliance can be a long process, as developers have many requirements to meet. Doing everything at once with no clear plan is a recipe for failure. Instead, create a compliance roadmap with target dates for meeting each requirement. Follow the roadmap rigorously, but also leverage your company’s existing efforts to reach compliance. 

    Existing efforts may include significant changes like raising the cybersecurity budget. They may also include smaller implementations such as a VPN for remote workers or stricter access control.

    Identify and Update Privacy Notices by January 1, 2023

    Privacy notices to customers are an integral part of the CRPA. The law requires that privacy notices are updated at least once every twelve months. Businesses can no longer set-and-forget their notices.

    App developers must identify the existing notices in the system and develop new ones that are in line with the policy changes brought by the CRPA. Notices for employees, job applicants and others must not be forgotten during this process.

    Provide Additional Security to Sensitive Data

    Not all data has the same value. Consumer data and confidential company documents are examples of sensitive data. Developers must work with other IT employees to separate the sensitive data and provide additional security to ensure its confidentiality.

    Some additional security solutions are data encryption, restricted access, two-factor authentication and strong passwords.

    Quality Assurance and Testing

    When it comes to cyberthreats, you can never be 100% secure, even if you follow all the best practices and regulations. That’s why having additional help from automated logging and testing software is necessary to maximize security.

    Develop a process for continuous self-monitoring and quality assurance. Automated penetration testing is a great way to find holes in your system. It’s also very affordable.

    Conclusion

    The CPRA was instituted in November 2020. The law requires all for-profit businesses in California to comply with data protection standards. Other states throughout the US are also implementing the same or similar legislation to protect consumer data.

    Now is the time to reevaluate your data security practices. Developers must take a privacy-first mindset and start thinking about security implications throughout the entire software development life cycle.

  • Future of DevOps: Trends to Watch

    Future of DevOps: Trends to Watch

    Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.

    According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.

    DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.

    Serverless Computing

    DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.

    Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.

    Microservices Architecture

    Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.

    DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.

    Low-Code/No-Code Applications and Platforms

    To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.

    Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.

    DevSecOps

    Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.

    More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.

    Kubernetes and GitOps

    Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.

    GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.

    AI and ML

    Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.

    Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.

    Conclusion

    DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.

  • Case Study: Transforming Health Care With DevOps

    Case Study: Transforming Health Care With DevOps

    Today, there are new and mounting expectations when it comes to the health care experience. Patients want digital options for everything from appointment reminders and communications to telehealth visits and pharmacy experiences. In fact, 70% of consumers are more likely to use a provider that offers digital reminders and follow-up care. 

    Health care organizations with digital transformation success reap the benefits—53% of consumers are more likely to use a provider that offers telemonitoring devices. Organizations committed to DevOps, like City of Hope, have not only experienced accelerated implementation of digital strategies but also achieved massive gains in productivity while maintaining security and regulatory requirements throughout their IT transformation. 

    Digitalized health care services were highlighted by the pandemic in 2020. Unprecedented changes drove organizations toward an entirely new set of benefits and challenges with cloud-based computing. As of August 2021, 73% of health care organizations had adopted DevOps. 

    That said, unfortunately, DevOps success can be difficult to achieve. According to Gartner, “75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change.” However, the benefits far outweigh the challenges, and with a dedicated organizational shift, DevOps benefits all—from the health care organization to the consumer.

    The Benefits of DevOps in Health Care

    Patient engagement skyrockets with modern conveniences like fast online check-in systems, health-related notifications, easily accessible patient portals, electronic pharmacy options and appointment availability monitoring. By automating software delivery management (via CI/CD pipelines), health care organizations deliver better features and solutions faster with higher quality and security posture—and they stay competitive in the market.

    DevOps expedites the development cycle, addresses bugs and rapidly deploys updates. CI/CD pipeline automation reduces bottlenecks and alleviates unnecessary expenses. With DevOps toolchains in place, the organization optimizes performance and drives a culture of collaboration between developers, operations, security and quality teams. As organizations become more data-driven, they can outpace the competition through enhanced insights and analysis. While the benefits are clear, some organizations cite concerns over regulatory and security as reasons for not yet adopting DevOps.

    DevOps for Regulatory Compliance and Security

    Regulatory compliance and security are essential to highly regulated industries—including health care. While the organization must maintain industry standards, delaying DevOps adoption can be more of a disadvantage. 

    Regulatory agencies often pressure organizations to close security gaps and vulnerabilities fast. New software releases to address these issues can take months to complete. DevOps (and DevSecOps), however, automates the most time-consuming processes and allows the health care organization to close security gaps rapidly and effectively. Further, with a shift left approach to security (static code analysis, dynamic code analysis, threat vulnerability management, DevSecOps, etc.), security is built into the CI/CD pipeline. 

    When organizations leverage their DevOps approach to automate configuration changes, they can establish a repeatable and standardized process. DevOps also provides visibility across the pipeline that allows organizations to scale and monitor compliance and identify risks effectively.  

    Accelerate Release Velocity With DevOps

    With DevOps, teams become substantially more productive and improve release velocity without sacrificing security. Better speed to market offers many advantages, especially if an organization wants to be the first to introduce a new concept or offering. It also keeps consumers satisfied with timely releases and updates.

    However, better release velocity almost always requires organizational change. When process, tools and collaboration among previously siloed teams are overhauled by a DevOps transformation, release velocity has the opportunity to skyrocket. Health care organizations like City of Hope have seen significant improvements in release velocity through implementing DevOps.

    How City of Hope Successfully Adopted DevOps

    City of Hope, a top cancer research and treatment center, underwent a DevOps transformation starting in 2022. Like many health care organizations, City of Hope is not a software organization at its core. However, as a research organization, it owns massive amounts of data about treatments and outcomes that need to be analyzed.  

    To keep pace with the digitalization of the health care industry, City of Hope’s engineering team created a new software development process from scratch. It needed custom software applications for ongoing and timely data analysis in the precision medicine data and systems division. 

    Like many health care organizations undergoing a DevOps transformation, City of Hope encountered common challenges it had to overcome as part of the process, including siloed development, operations, security and quality teams; slow releases and approval cycles and little-to-no visibility into velocity, performance and security. 

    The transformation also had to be achieved without hiring DevOps engineers or consultants. Looking at the future of digitalization among health care organizations that do not consider themselves ‘traditional’ software organizations, City of Hope modernized and elevated its offering through no-code DevOps orchestration without the manual coding processes that can significantly delay an organization’s entry into the digital space.

    City of Hope’s DevOps transformation helped accelerate software delivery, and a no-code approach reduced the barrier to entry for those unfamiliar with DevOps engineering. No-code DevOps orchestration rapidly improves the speed at which an organization can reach DevOps maturity and scale across all apps and business units. It removes the time-consuming coding process of the CI/CD pipeline while allowing an organization to track governance and shift left for safer software delivery. 

    City of Hope successfully developed a DevOps pipeline capable of being built and managed by the City of Hope IT staff. 

    The results were substantial, including: 

    • Developer productivity increased by 25%
    • An 80% increase in productivity with the ability to build a holistic and integrated DevOps pipeline in 30 minutes versus 2.5 hours 
    • The initial pipeline was up, running and providing value in just two months

    Now, City of Hope has access to real-time insights that allow the team to resolve any issues quickly. While it has documented noticeable improvements within the IT organization and the pace of software development, DevOps has notably given teams time back to do what is most important at City of Hope—deliver innovations that will help make cancer a thing of the past. 

    As health care organizations move toward more cloud-based offerings, they need the right combination of tools, processes, skills and a cultural shift focused on digitalization. With these in place, City of Hope successfully achieved DevOps transformation with 80% faster releases and visibility across the entire pipeline. 


    Gorkey Vemulapalli, senior director, precision medicine data and systems at City of Hope, contributed to this article.

  • Resolving CI/CD Permissions Issues to Address Delivery Needs

    Resolving CI/CD Permissions Issues to Address Delivery Needs

    Security concerns and DevOps process issues can stall CI/CD operations. DevOps teams are familiar with the frustrations plaguing their pipelines, whether regulatory or process-based. Operational hurdles are all too common in DevOps pipelines, leading to miscommunication between team members and the broader organization. One of the leading operational issues DevOps teams encounter is permission issues. Permission issues are a seemingly small yet significant roadblock to smooth CI/CD pipelines. Fail to address them and the result is a lack of cohesion between development and organizational objectives.

    Here’s how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.

    Review Pipeline Tools for Permissions and Access

    The DevOps life cycle often contains multiple tools, all with different access needs and permissions. As such, this situation is a security nightmare. Jeremy Hess, head of DevRel at secrets management platform Akeyless, called this a “secrets sprawl.”

    “The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare,” he said. “For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions.”

    There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Because these tools communicate with other pipeline tools, credential details can often be present in configuration details.

    Developer passwords are not visible on the frontend but could accessible from the system backend. Any user with ‘configure’ permissions could request any credential and then inject them into agents. The result is that AWS keys, Git credentials and/or passwords are at risk.

    To mitigate this issue, the first step involves deleting hard-coded secrets from CI/CD tool files. Distributing secrets between multiple tool configuration files also reduces the possibility of attack while easing developer and engineer access. Password managers are also a good choice, but validate them for security before implementing a solution.

    Practice Least-Privilege Access 

    Access and permission issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority of users, regardless of members’ roles or job functions. While this situation encourages rapid development, it also creates massive security issues.

    Balancing security with CI/CD needs is tough to get right. That’s where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.

    While most teams put this principle into practice, they make the mistake of leaving their process intact. The lack of access audits creates DevOps frustration, not the level of access. CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly.

    For instance, embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.

    Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member understands their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.

    Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.

    Implementing OTPs and other authentication factors is also a good idea when validating user access to secrets.

    Review OSS Projects

    Open source software (OSS) projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.

    “Often, the company that initiated and that owns a popular OSS project continues to employ the core contributors,” he said. “They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else—anyone who occasionally might contribute a fix or a feature.”

    As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project. However, CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring permissions—and who can place requests and roles that review them—will ensure a good level of security.

    Establishing machine identity is also critical, given the degree of non-human access pipelines face. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.

    It’s also a good policy to destroy containers and VMs after they’ve been used.

    Streamlining DevOps Operations is a Top Security Priority

    DevOps is critical to every organization’s success. Access and permission-related issues are common occurrences, but are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.

  • Armory Demo