devopsy.kinsta.cloud

Category: DevOps Practice

  • In Service Management, AI Is Still Aspirational

    In Service Management, AI Is Still Aspirational

    Artificial intelligence (AI) has become a matured concept, the excitement of which is bearing results for a number of sectors and it holds a good deal of promise for a bright future. AI is the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, ultimately leading for more complete automation in many traditionally man-powered processes. Computers can be “trained” to accomplish specific tasks, process data and recognize patterns in the data.

    While the use of service management solutions escalates, so do the potential uses for AI approaches in the sector. Because of this, there are advantages to discuss as well as examples of how AI can help to improve the service management operations of your organizations. But AI is a broad and far-reaching concept that’s often misunderstood and difficult for those that don’t work with the technology to understand its full capabilities.

    Is AI All Hype or Is It Actually Helpful?

    Based on the 2018 Interop ITX AI: Hype or Substance report, in a survey of 182 technology professionals, almost two-thirds of these respondents’ organizations are currently working on AI products or evaluating the technology. However, only 12 percent are using AI in production today. For those who responded during 2018, 6 percent of those using the technology said their budgets for it were set to decrease. The outcome, per the report, is that AI interest is high, but the ability to execute is low.

    Are AI Expectations Too High?

    The return on investment of AI is not clear and nearly one-third of organizations say they lack the budget they need to move forward, Information Week reports. Additionally, despite the desire for AI initiatives to reduce manual processes, these tasks must still be carried out by talent in the organization. A lack of expertise is often cited as a barrier to AI initiatives because there is not enough expertise to push the efforts forward. Alternatively, of those surveyed, more than a quarter said they haven’t defined a business case yet and close to half said they “have no idea” what effect AI may have on their businesses.

    Part of the problem with AI is the broad nature of its concept. Much of what we thought we knew AI was is now standard practice. For example, early AI efforts like IBM’s chess computer, Deep Blue, is part of our computing world now. Currently, demand or desire for AI capabilities is still aspirational, but usually is conflated with “machine learning”—where a computer or programming provides examples for how a machine can “learn” how to complete said task. Machine learning has huge potential to help societies automate previously manual systems. Through this, new economies will be developed and work (and workers) will evolve. Certain jobs, eventually, will become minimized and even discontinued in favor of new process and “ways of doing things.”

    We have seen these cycles before. In the United States, from a macro level, there’s been a major shift from a farming/agricultural society to one of more urban-based manufacturing/industry; into the post-industrial; then global-focused; and web-connected economies. These can be drilled down further but the point is made—major variations in our economies and jobs have taken place in a relatively short period of time. Based on these changes, we’ve had to change; jobs and workers have had to change. Machine learning is another disruptor for the new global economy that will force change.

    Hyped Up

    The hype of machine learning—a technology with huge potential—may not actually be overhyped. That said, how will this technology actually impact our everyday lives, and will machine learning change the work we do in service management? Perhaps we’re now starting to get a better idea of what those realities may look like.

    As far back as 2017, Gartner said that machine learning hype peaked, but expectations remain high. For service managers, there’s going to be more than intelligent chatbots to worry about but for now, much of the anticipation likely will continue. Machine learning can be a beneficial tool for identifying trends and changes in trends. In service management, machine learning means quick responses can help recognize when there is an above average number of calls logged, for example, or an unusual number of calls within one category, which can be acted upon.

    For most pressing trends—a specific cloud service that may no longer be available, for example—meaning machine learning-driven technology can recognize this breakdown by sending a signal to a specialized member of the service team, who can then react to this issue. Long-term problems also can be addressed through machine learning technology, spotting urgent disruptions. This may be particularly important during problem management. A labor-intensive process, machine learning has the capability of being able to recognize patterns in these calls, making the discovery of structural problems much easier.

    Misconceptions About Machine Learning

    Misconception surrounding AI and machine learning is rampant from replacing most of our jobs and replacing massive amounts of humans in the workforce to their surpassing our pre-programmed uses for the technology, in which the machines rise up and enslave us all. The more realistic version of things is a bit more benign. The most common current misconception is that chatbots and virtual assistants will make service desk employees redundant in short order. But this won’t likely be the case for the better part of a half decade or more because the technology isn’t sophisticated enough. Most chatbots are pretty expensive and don’t always work well.

    For now, machine learning will likely only help “answer” direct questions more quickly. More complex issues must still be handled by people. The realized benefit here is that because machine learning technology can help solve the easiest questions service desks face, there’s more time for service desk team members to solve the more complex calls.

    Someday Soon …

    Soon, machine learning technology will become better at finding the right information and offering solutions that actually benefit humans. Then, service desk employees will be able to focus more on the overall customer experience in ways that machine learning likely never could.

    While AI is maturing, excitement surrounding this experiment may need to be tempered for a bit. The technology is in the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, but more complete automation in many traditionally man-powered processes is still needed.

    — Nancy Van Elsacker Louisnord

  • Why You Need DevOps and the Cloud

    Why You Need DevOps and the Cloud

    DevOps and the cloud are not only two of today’s biggest tech trends, but are inextricably linked. Research from DORA’s 2018 Accelerate State of DevOps Report and Redgate’s 2019 State of Database DevOps Report outline a clear correlation between cloud and DevOps adoption, with the two working together to contribute to greater business success.

    For example, in the DORA report, those companies that met all essential cloud characteristics were 23 times more likely to be in the elite group when it came to DevOps performance. Similarly, Redgate found that 43 percent of organizations that have adopted DevOps have server estates that are all or mostly cloud-based. This compares to just 12 percent of organizations that have not yet adopted DevOps or have no plans to.

    Looking into the link in more detail, research shows that there are four common factors that underpin DevOps and the cloud:

    Cultural Openness to Transformation

    Adopting DevOps is not just a technical or process change, but one that requires a certain type of culture to be in place. The renowned sociologist Ron Westrum famously categorized business cultures into three groups in his seminal paper A Typology of Organizational Cultures:

    • Pathological: Power-oriented, with low co-operation, a culture of shooting messengers bearing bad news and the crushing of novelty.
    • Bureaucratic: Rule-oriented, with limited co-operation, a neglect of messengers and a suspicion of novelty.
    • Generative: Performance-oriented, with high cooperation, messengers encouraged and a focus on learning from mistakes and embracing novelty.

    It’s no coincidence that DevOps and cloud adoption both thrive best in a generative culture that is open to innovation and is focused on collaboration and continual learning and improvement. In fact, the DORA research found that a generative culture correlates with elite performance when it comes to software delivery, and that this group is 1.8 times more likely to recommend their team as a great place to work.

    Building this open culture requires team members to feel safe about taking risks, rather than continually covering their backs, as well as good communication from leaders. This psychological safety underpins the continuous improvement mantra of DevOps and the innovation that the cloud delivers.

    The Importance of the Cloud to Enabling Faster Software Delivery

    As the DORA report found, cloud users are more likely to be elite performers when it comes to DevOps. But the research also highlights that there is a lot of confusion about what “moving to the cloud” actually entails. The National Institute of Standards and Technology (NIST) defines cloud computing as having five essential characteristics:

    • On-demand self-service
    • Broad network access
    • Resource pooling
    • Rapid elasticity
    • Measured service

    Just 22 percent of DORA respondents agreed or strongly agreed that they met all of these criteria. Those that did were 23 times more likely to be elite performers when it came to software delivery. This shows that simply moving to the cloud alone doesn’t lead to DevOps success—the switch needs to be implemented professionally, in a planned way. This goes back to culture—the same openness to innovation has to underpin both, DevOps and the cloud, to realize their full benefits.

    Breaking Down Barriers

    One of the key points of a generative culture is openness to collaboration, which is clearly essential to DevOps and, in particular, incorporating the database into DevOps flows. In the past silos, rivalries and even animosity built up between application developers and database administrators (DBAs). In many ways this isn’t surprising—developers are focused on getting new code out of the door, while DBAs are seen as protecting data and databases and ensuring uptime.

    However, for DevOps and the cloud to succeed, teams need to take a holistic view that breaks down team barriers. Redgate’s research shows that this is now happening, starting with the working relationship. Sixty two percent of respondents characterized the relationship between DBAs and developers as either good or great, up from 58 percent in previous years. This is heartening—only 13 percent said the relationship was poor with DBAs completely siloed, unaware of what’s happening in development, and deploying database changes to production in isolation.

    In teams that have adopted DevOps across all projects, the great and good collaboration rises to 76 percent, with 41 percent stating great collaboration—almost double the overall average.

    This collaboration is also reflected in daily activities. For example, over three-quarters (77 percent) of application developers are also responsible for database development and building database deployment scripts. In 47 percent of companies, developers are also responsible for the deployment of database changes to production.

    Putting in Place the Right Tools

    The collaboration behind successful DevOps and cloud adoption requires companies to introduce common practices and common tools across the entire process. This is reflected in figures from the Redgate research, with a growing adoption of the same tools within application and database development. Version control is now used by 83 percent of respondents for application development, and 55 percent for database development, rising steadily from 81 percent and 53 percent respectively in 2018. Particularly encouraging is the significant uptake in continuous integration—a cornerstone of DevOps—which is now used by 53 percent of respondents for application development and 27 percent for database development, up from 40 percent and 21 percent in 2018.

    All of this is leading to increased usage of third-party tools across DevOps processes. The most substantial year-on-year change is the use of third-party provisioning tools—which has doubled from 12 percent for the application and 8 percent for the database in 2018 to 25 percent and 15 percent respectively this year.

    In increasingly competitive markets, companies rely on software and data to differentiate themselves and drive success. And this, in turn, is underpinned by DevOps and the cloud, which provide the agility, speed, quality and flexibility to develop and deploy software more quickly and safely than before. Businesses therefore need to adopt both if they are to achieve elite performance across their software operations.

    — Matt Hilbert

  • Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report

    Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report

    IT recruiting is at an all-time high and organizations want T-shaped professionals with cross-functional skill sets to join their teams. While “T” represents an individual’s core competency, and the top of the T represents a broad range of related knowledge, there has been little clarity on which skills are the most important across a wide spectrum of possibilities—until now.

    DevOps Institute launched the Upskilling: Enterprise DevOps Skills survey in 2018 to focus on the human element of skilling. The feedback from more than 1,600 individual responses echoed the notion that regardless of vertical, organizational size, geography or role, DevOps practitioners need data-backed skilling statistics. As the focus within the enterprise, DevOps community shifts from “What is DevOps?” to “How do we do DevOps,” this demand is more crucial than ever. After all, “how to” requires “know-how” and “know how” requires a new set of skills. But which skills?

    According to DevOps Institute’s Upskilling: Enterprise DevOps Skills Report:

    • Soft skills and technical skills are equally important
    • IT operations knowledge received the most “must-have” votes as a functional skill in DevOps
    • Cloud and analytical knowledge are the top technical skills
    • DevOps Engineer emerged as the most popular job title (see below for figure N=812)
    N=812

    The report was developed in partnership with veteran research analyst Eveline Oehrlich, formerly of Forrester Research. This comprehensive data provides indications of which functional, process, technical and automation skills are “must-have,” “nice to have” and “not important.”

    This is particularly significant for IT professionals who are confused about where to focus their personal skills transformations in their journey toward the “T.”

    Should developers work on upskilling their testing, automation, process and/or security skills? Should operations professionals learn to code, test or explore more about machine learning and AI? What about project management and systems administration? The Upskilling: Enterprise DevOps Skills Report can be used as a snapshot of critical enterprise skills that are important to successful digital transformation.

    The Upskilling: Enterprise DevOps Skills Report was released March 4 and is now available for download. On behalf of Platinum Sponsor Electric Cloud, Gold Sponsor CloudBees and Silver Sponsor Lenovo, industry influencers and international DevOps community, we hope this data will help shrink the skills gap and support the transformational goals of both individuals and organizations. We’re already looking forward to the launch of DevOps Institute’s Upskilling: Enterprise DevOps Skills Survey 2020 to continue meeting the demand for ever-evolving skilling trends in the DevOps community—stay tuned!

    — Jayne Groll

  • DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    In this DevOps Chat we speak with Cyara CEO and co-founder, Alok Kulkarni, about how DevOps is helping in the customer experience arena. Cyara has carved out a leadership role in bringing DevOps to CX. Alok is a delight to speak with and very wired into this space.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.


    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Alok Kulkarni, CEO and Co-founder of Cyara. Alok, welcome to DevOps Chat.

    Alok Kulkarni: Hey, Alan. Great to be here.

    Shimel: It’s our pleasure to have you here. So, Alok, let’s—before we jump right into what I wanted to talk about today, I think the first thing we should do is a little level set. Maybe we have some folks who are familiar with Cyara, maybe we have some folks who are not. Why don’t you give us kind of a quick background on Cyara?

    Kulkarni: Sure, Alan. So, Cyara is a customer experience assurance platform, which allows customers to accelerate their CX development right from the design through to testing and all the way through to customer experience monitoring for customers’ journeys end to end.

    And so, what’s different about us is, we support the entire software development life cycle from the design through the functional integration testing right through to user acceptance testing, including load testing and production monitoring. And, in the CX world, we’re able to do this from an end customer perspective across all the different channels that the customer might be interacting with the organization. So, that’s just a brief summary of what we do.

    Shimel: Sure. And you are the Co-founder and CEO.

    Kulkarni: Mm-hmm.

    Shimel: And just, while we’re here—

    Kulkarni: Yes, and—

    Shimel: —give us a little bit of your own personal journey. How did you come to be the co-founder and CEO at Cyara?

    Kulkarni: Sorry, go ahead.

    Shimel: Oh, I’m sorry. I was going to say, if you can give us a little bit of your own personal journey, how did you come to be the CEO and Co-founder of Cyara?

    Kulkarni: Oh, great question, Alan. Sorry, I lost you there for a bit. I was working at another software company, which is currently the leader in customer experience management technology, and one of the things I found in those days—this was in the late 2000s—was, every time we put the technology in production, the customers, the end customers used to deal with this new technology and the enterprises would be sitting there with white knuckles hoping and praying that it would all work—because there was no platform in those days which would enable them to test and monitor the technology that they were putting in for the customers from the outside in. So, essentially, it was like playing Russian roulette.

    So, I felt, being an architect at this company and managing the solutions engineering group at this technology company called Genesys that, there had to be a better way. And one of the—the idea came to me when we were rolling out a large implementation for an Australian government organization when it failed. I thought that there must be a better way of doing this.

    So, hence, I felt—imagine if there was a cloud-based platform that was technology agnostic which enabled enterprises to just use and simulate customers from the outside in to be able to test and monitor, not only the infrastructure, but the applications from an end to end customer journey perspective. It would really take the risk out of deploying new and innovative solutions in the market. And so, that’s how it all happened. So, I got together with my buddies and we built Cyara.

    Shimel: Excellent. So, you know, in so many ways, there’s so much DevOps there, if you will, Alok. And first of all, the idea of—and we see this in security, we’ve seen it with other forms of QA—the idea of waiting ‘til after something is deployed to see if it works or not, you know, that white knuckle moment? Why?

    Kulkarni: Mm-hmm.

    Shimel: I mean, why, in this day and age, do companies still want to do stuff like that, right? And this is, especially when we talk about sort of the modern software factory and CI/CD pipelines and so forth, right? We shouldn’t let software out there that hasn’t been fully vetted and tested. Why would we let software and things in the wild, where we haven’t already tested what our customer response, and our customer experiences are going to be and whether they will work?

    It just seems like such a no-brainer. Why do you think it took so long for people to come to this realization?

    Kulkarni: So, I think that’s a great question, Alan. And, you know, when we were sitting there noodling on whether we should start this, I remember going to my co-founder, Bonny, and asking him, “Hey”—because he wasn’t from the industry, and when we came up with this idea, he goes, “Surely, there’s somebody doing this.” Because it’s exactly what you said—it’s a no-brainer. And I said, “No, there’s actually no one doing this.”

    And I think the reason for that is, one is, I don’t think people in the—if you’re not in the industry, you don’t even know that this is a problem, that’s one. Second thing is, even if you were in the industry, it is so complex. I mean, there are so many different moving parts, so many technologies. Then you have enterprise processes and systems and systems integrators and so forth.

    So, by the time you’ve put that whole, all those components together, it becomes very difficult to build something simple that would solve these problems. So, when we did it, it just took off. And now, like you say, I think customers are realizing that there is a technology or a solution out there that can help them. So, we’ve had a tremendous, I guess, following of customers who actually just continue to expand what they do with Cyara and we’re signing new customers on as we go along.

    So, just this last quarter, we signed about 25 Fortune 500 companies to our platform. So, I think it’s catching on, and now, what we’re seeing is the next wave, like you mentioned, this whole DevOps wave that’s really taking firm hold in the way that more and more organizations are putting out a software or capability. And I think in the CX world, that’s changing as well. So, I think, we’re also creating awareness that you can bring DevOps to CX and although the tool set might be a little different, you can actually do it. So, we’ve had a tremendous amount of traction in the market with that.

    Alan Shimel: Absolutely. You know, Alok, it talks to something else that we’ve seen in DevOps. When we first started devopsy.kinsta.cloud on March 11th of 2014, I think it was, so it’s almost five years now—the whole, “What is DevOps?” argument was raging. And there was a large percentage of the community that had a very orthodox view of DevOps, that if it wasn’t purely about software development and deployment in terms of operations and APM, it wasn’t DevOps, right? That’s what—there was a very narrow definition of DevOps.

    We’ve seen that expand, right, to what I call DevXOps now.

    Kulkarni: Mm-hmm.

    Shimel: We’ve seen DevSecOps, we’ve seen DevBusOps, we’ve seen DevSalesOps. It’s really taking that DevOps mindset that DevOps can do and applying it to everything.

    So, really, we’re almost seeing here DevCXOps, right, if you will.

    Kulkarni: Yeah, totally. Yeah, I think we are in that era now of DevCXOps, just like you mentioned. Because, just like software organizations were putting out new capabilities in a rapid manner, I think customers were expecting customer facing technologies, and the way they’ve been—the way that they’re interacting with organizations to change rapidly as well. Because everyone’s time poor, they need the answers as soon as something goes wrong or if they want to buy something, they’re impatient, because we all have things to do and we’re on 24/7.

    So, it’s imperative for companies providing customer experience to keep up with that. And I think DevOps provides a great framework to do that, and it’s aligned so, as you say, if you’re already in DevOps and the digital world, you can bring it to the CX world. And I think it’s really catching on.

    Shimel: I don’t disagree. I think another thing, Alok, and you hit on it there, is customer expectations. You know, one of the sort of forgotten heroes or the forgotten catalyst behind all of the DevOps kind of movements is what really—people don’t go fast just to go fast. Well, maybe some do, right? There are speed freaks, right? [Laughter]

    But, you know, people who adopt agile DevOps and these sorts of frameworks and methodologies do so to be more responsive to customers. And that’s really—and it’s nitty-gritty. That’s what it’s about. Because that’s why companies do things, to serve their customers better. And that’s really the guiding principle behind CX as well, right? How do I respond to customers better, especially in a world where customers demand more? They want 24/7 support and response, and they want it right away, and they want it now and they want it to work, right? There’s a low tolerance if your cellphone coverage is not good, or your internet—as we spoke about—your Internet at 30,000 feet on a plane is not working, and people get really upset about that now. And in so many other ways, customer demands are driving this. Correct?

    Kulkarni: Yeah, totally. And you know, what’s sad is, we’re fickle. You know, we’ve been conditioned to now have choice. So, if we don’t like the service a particular company is offering, you know, we switch, and switching is so easy, because it’s very easy to find another provider who provides a similar service and offering and then if they have a better customer experience, you think when you actually have that moment of need where you actually need help and they’re providing it to you promptly and they’re resolving your issues quickly and they’re doing it how you want to be treated, maybe it’s a late night chat or a phone call because it’s super urgent or it’s complex. Or maybe it’s like, “I don’t want to talk to anyone today, but I need the information for my support, because one of these technologies that I’ve got isn’t working, so I need a knowledge base that I can refer to.”

    Any of these customer-facing technologies play a very important part in customer loyalty and thereby, shareholder value for the company that they’re dealing with.

    Shimel: Agreed, agreed. So, Alok, if you don’t mind, I want to talk a little Cyara—I’m sure you don’t mind. [Laughter]

    Kulkarni: [Laughter]

    Shimel: So, do you offer this as more of a Platform as a Service or as a SaaS based offering?

    Kulkarni: Yeah, it’s a SaaS-based offering, so we have a cloud infrastructure environment which spans, which goes across the globe. Just last year, we placed 4.4 billion call seconds’ worth of synthetic interactions to assure customer experience around the world, and some of the largest brands of the world use it.

    So, some customers, they use our platform to provide the whole design experience—like, the design, the customer experience in Cyara is able to, as a result, get a full automation and regression test suite that they can run as part of their DevOps factory, and then we have a real time customer experience monitoring platform.

    So, for example, if you put something out in production, our platform actually is able to generate synthetic customer interactions from the outside in. So, we can actually emulate, Alan, contacting an organization on your behalf and actually see what experience you’re going to get, whether your interactions or your calls connected on time, whether the web chat gave you the right responses, whether the screen froze or not, and you can do this all in real time.

    So, customers have a direct feedback loop that they can implement. So, as soon as something goes into production and it doesn’t work, before a real customer is able to have a poor experience, we’re able to detect it early on and the customers can then roll back the technology that they had implemented and then roll the previous last known good version out so that they maintain the sanctity of the customer experience.

    So, it just—to me, that just goes hand in hand with the whole DevOps paradigm.

    Shimel: I agree. It certainly does. So, Alok, if I ask you to kind of peer into your crystal ball of the future, where do you see this going now?

    Kulkarni: So, as you mentioned, Alan, there’s a lot of companies out there who are not even aware that they can apply the whole DevOps—they can bring CX to DevOps and, as you call it, DevCXOps, and make it happen. So, I feel, over the next two years, we’re going to see a tremendous wave of customers adopting this framework, because they’ve already done it on the digital side and the CX side tends to be—I think they’re in an adjacent area and I think they are moving to this new model.

    So, we’re going to see a lot of customers offering it, and I think we’re going to see a lot of new, innovative technologies coming out with integrated solutions for that. So, I think for Cyara, we want to support our customers as they go on this journey. So, we’re integrating with a number of platforms out there that enable the whole CX DevOps pipeline scenario. For example, we’ve just integrated with Splunk, we’ve integrated with ServiceNow. So, in Cyara, you can actually get real time incident notification of any technology that you’re implementing and automatically create service requests so that you’re able to keep ahead of the whole customer experience pipeline.

    And the other thing that we’re doing is also investing heavily on the design aspect of it. So, we’re working with companies like Amazon and so forth to offer a platform that is able to take customers that are moving to the cloud or moving to cloud contact centers, which is becoming, which is a new wave that’s still catching on and enable them to essentially drive this whole assurance through to all their customers.

    Shimel: Excellent, excellent, excellent. Well, Alok, as we—I think I told you before we started, the time goes really quick. We only have a few minutes left. I wanted, also, I’d like to finish up with kind of wrapping this whole thing back into the DevOps, back into what Cyara is seeing from customers.

    Companies I’ve been involved in, and I’ve founded a few, you know, we had sort of a customer support, a customer help team. It was separate from developers, it was separate from Ops. It was part of the engineering team, but it was almost a red-headed stepchild within that engineering/IT team. Is that still the case? Is that a problem? Is that something Cyara runs into when you’re talking to folks? What’s the story?

    Kulkarni: So, I think you, again, Alan, are right up there with it. So, I think one of the decisions organizations that we deal with are grappling with is, do they make engineers who understand software and make them CX developers, or do they make CX developers who have real code domain expertise and bring them onto the DevOps world?

    And I think that’s a question a lot of companies are asking themselves—like, do we need to really understand this space from top to bottom, or do we get developers? Is it easier for developers to learn this versus the other way around?

    And I think that’s currently in the experimentation stage. So, a lot of companies who have tried the old model feel that it’s just very hard to change the mindset of the old engineering folks to—you know, who’ve been traditionally used to waterfall and doing large scale implementations and using systems integrated to put those out to really just come onto this whole new, you know, go fast, break things mentality versus getting those guys to understand CX.

    So, I think there are two horses running right now, and I think we’ll see the results of that in the next year or two. But what I am seeing is a lot of companies trying to get their developers onto the CX world, because they’re finding that that seems like a much easier path.

    Shimel: I don’t disagree with you. Crazy. Interesting times.

    Kulkarni: Yeah.

    Shimel: Anyway, Alok, I know we’re doing some other, you’ve published some more—well, not you, but Cyara has published some nice articles on devopsy.kinsta.cloud lately, we’ve done some other activities.

    Where else can people find out more information, though, about Cyara?

    Kulkarni: Well, they can obviously come to our website, so Cyara.com, that’s C-Y-A-R-A dot com. And I think we have, we’ve built a huge library of resources thanks to our fantastic team that we have at Cyara, and they can also—I think over there, there’s a whole library of collateral that they can view. We’ve got a YouTube channel that they can subscribe to.

    And we also have Cyara Academy. So, as part of that, they can go in and if they want to actually get trained on Cyara, we offer that on demand as well. And you don’t—I think there are some courses where you don’t have to pay. So, I think you can, if you’re new to this space, I think it’s a great place to get scaled up, because I think this is a very exciting space. Because, as you’ve said, Alan, every company, to be successful, needs to really deliver a superior customer experience to their end customers and I think it’s just the core of any fundamental for any company to get this right.

    So, come on over to Cyara.com and get yourself educated.

    Shimel: Cool. Well, Alok Kulkarni, CEO and Co-founder of Cyara, thanks for being our guest on this interview, on this episode of DevOps Chat, and we hope to have you back on again soon.

    Kulkarni: Thanks, Alan. Would love to come back.

    Shimel: Alrighty. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    These days, it’s not enough for companies to offer quality products or services; they must deliver an exceptional customer experience. In fast-changing environments, continual innovation on the front lines of customer service requires an agile and nimble approach.

    How important is the automation of development and monitoring for accelerating customer experience (CX) innovation? I recently posed this question to Dr. Nicole Forsgren, research and strategy expert at Google and former chief scientist at DevOps Research and Assessment (DORA). Her response:

    “I would say that, today, this is almost just a given to operate effectively. DevOps is definitely more than tooling, but you can’t do it without strong technology solutions that provide automation, monitoring and visualization to people throughout the value chain. This gives visibility to key stakeholders, so you can ensure you are delivering value and your feedback loops are happening.”

    This is not a simple concept to execute well. The diverse array of applications and systems that organizations deploy to engage their customers is complex and spans many different technologies, platforms and channels. Ensuring all those applications and systems work together seamlessly to enable customers to consistently accomplish their goals is a daunting challenge. What’s clear today is that how customers perceive their interactions with businesses, shapes brand loyalty.

    It’s interesting then, that while most companies recognize the importance of providing an outstanding experience, many have yet to embrace an automated approach for the development of their CX applications. Those enterprises that have successfully accelerated their CX innovation share a common attribute: They have automated both the testing and monitoring of their CX development projects.

    DevOps + CX = Faster Speed, Higher Quality, Fewer Failures

    Customer-facing applications, such as call center technology, websites, SMS and even chatbots, are the central artery of customer experience. If these applications are not designed, built and deployed properly, it will be costly. To ensure success of CX innovation projects and reduce the risk associated with development/deployment, we must build solutions with testing and monitoring in mind, automate deployment and configuration, and use test data in production to accurately monitor variance from the design.

    What’s holding your organization back? There are four important steps organizations can take to boost the speed and quality of CX software development, while reducing their failures.

    1. Strive for automation, anywhere you can find it

    Aim high—strive for 100 percent automation and take a creative approach to integrating different phases of development. Whether it’s JIRA, Bamboo, Udeploy, Cyara or any other technology that helps automate different parts of your software delivery life cycle (SDLC), have a vision that automates and integrates wherever possible. Success here will deliver smooth and seamless movement of work and deployments into various environments.

    2. Don’t underestimate the importance of the feedback loop

    In order to improve our CX, we must first understand what challenges customers are encountering right now. This requires real-time monitoring of the actual customer experience—but from the customer’s perspective, not from a hardware perspective, as is traditionally done. If you can monitor and measure customer interactions in the moment and capture them concisely, then you can channel this critical information back to business decision-makers, so changes can be implemented quickly. It’s one example of a feedback loop, and if you can repeat it over and over, you can significantly improve and refine your CX.

    3. Take the time to reflect, align and improve

    Instill a culture of learning and humility—not finger-pointing and blame. For example, I recommend teams adhere to well-defined Agile Retrospectives, a ritual that enables teams to create a continuous improvement culture in which they reflect on past experiences and define future actions. Retrospectives are only one of the many ways to instill an open-minded culture, constantly focused on improving collective capabilities.

    4. Integrate business objectives and measurements with the technology side of the house

    I see this as a two-way street. First, help ensure the technology teams understand the impact of their work and give them access to the metrics that are important to the business team, through regular progress reporting. Second, make sure the business team shares their goals and key objectives with the technology teams, rather than simply specifying a requirement. I think it’s important that developers and operations teams understand the business impact of success and failure—and, therefore, the importance of their work. This is a great motivator. Plus, more visibility and tighter integration with business objectives can also result in more creative problem-solving from the innovative thinkers on the IT side.

    A Parting Thought: Find Your Anchors

    The right decision or strategy is not always clear, but finding two or three pillars as your anchors can be clarifying during decision time. In the CX innovation space, I find two anchors are particularly helpful:

    • The customers are the reason why we are in business. Are you prioritizing the end-customer experience in this decision? Are you improving it, understanding it better or measuring it more effectively?
    • What is the business goal you’re aiming to attain? No matter how granular the technical change you’re making, there is almost always a business reason driving it from the top down. Do you know what that driver is? How, exactly, will your change move you closer to that business goal?

    — Amy Hudson

  • Is Your Digital Product Ready for International Prime Time?

    Is Your Digital Product Ready for International Prime Time?

    When a digital product is developed in and for a particular geography and market, the enterprise and developer/architect function is focused on getting it to market first. Once it matures and receives greater engagement, enterprise is then looking to continuously add and develop a stable product that is feature-rich, scalable and robust. So, when the opportunity to take the product global arises, the design and development of the product encounters a whole set of challenges that is not accounted for in the initial stages of development. This is when the localization-versus-internationalization challenges take root.

    We have compiled a few quick hacks that you can use as your checklist for a smoother transition.

    Let’s first define internationalization and localization. As per the World Wide Web Consortium (W3C), localization is defined as “the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a “locale”).” Internationalization is defined as “the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.”

    So, what are the typical factors that teams of designers, architects and developers need to first establish, foreseeing internationalization?

    Legal and Regulatory Guidelines

    Different regions, geographies, countries and markets have different regulatory guidelines that can extend to several facets including organization practices, trademark requirements, currency repatriation, tax compliance, regulatory compliance, duties and corporate agreements and contracts, currency repatriation and so on. If you’re working on a product that you need to go-to-market in China for instance, then it is important to understand the legal and regulatory framework within which you can operate.

    Hosting Location, Global Distribution/Content Delivery Network Infrastructure

    Different geographies, different networks and different internet speeds are factors one must consider when taking your product global. How can a product be designed to ensure that it “loads” quickly for customers across regions? Should there be a central database or should it be distributed? Who, where and how will distribution of data be managed? These are critical questions to ensure there are no customer drop-offs.

    Unicode Support

    Today, Unicode allows support in most of the world’s writing systems. Enabling its proper usage that can support local, regional or even cultural context is critical. For instance, supporting special characters from different languages that are outside the ASCII boundaries (defines 128 characters in a typical English keyboard) is extremely important. Unicode defines 221 characters (characters from all recognized languages in the world), thus, UTF-8/16 encoding format should be supported when you’re planning to release your product in different geos. This is a crucial requirement for database, DB connection, build setup and server startup options—just to name a few.

    If you’re fond of hard coding text, think again. Creating text and media that is easily editable, gives you the flexibility to easily localize and adapt your product for different regions.

    Multi-Lingual Support

    English may be one of the most spoken languages in the world, but that doesn’t necessarily mean every region or market thinks, reads and speaks English. For instance, if you’re releasing a product in Japan, China or even India (with its plethora of scripts for different languages), multi-lingual support for your product is essential. Here are a few things to follow:

    • Maintain language-specific resource files for each support language (eg. en-us.properties, ar-sa.properties) with key value pairs—the key is used in the code to place the text, and value is the language specific translated text.
    • All text on the screen, messages and label text must be sourced from resource files, and there should be no referencing of text directly in the code.
    • Choose to keep the resource files at the back end/front end. Front end is recommended as it helps improve performance, and by avoiding calls to the back end and toggling, it moves fast.
    • UI framework should support translation features.

    Think about text expansion in different languages, in terms of number of characters and how it can affect the UI and UX of your product. The same holds good for languages that are written from left to right, as well as translations.

    Scalable Framework for Geo-Specific Customization

    Development framework must consider the UI/UX, branding, orientation and size of the product when going i18n. For instance, the color red could mean different things in different countries and cultures—in China it could mean endurance, in India it could mean purity, in Europe it could mean self-sacrifice or in South Africa it could mean grief and sorrow. Therefore, it is extremely crucial to understand different nuances of cultural significance while designing the UI for a great UX. A few other factors to keep in mind:

    • Tag-based framework for content picks up where the content is tagged to language/country, and gets picked for users having matching profiles, for the tag values. This way, you may have content for various languages, but a user in Spain gets to see only the Spanish content just by setting his language preference in your system.
    • Orientation and sizing adjustments—specific CSS to handle alignment/size specific customization.
    • Navigation (left to right), enable/disable certain options through CSS customization.
    • Localization-based content.
    • Language-based content.

    Developing a framework for rapid transition to international markets requires a thorough think-through from a product enablement perspective, keeping in mind operational efficiency without impacting product behavior. Using this checklist will help you save time, money and rework when you finally decide to go i18n.

    — Ruchi Vaidya Tomar

  • Digital Transformation Technology and Process: More Similar Than You Think

    Digital Transformation Technology and Process: More Similar Than You Think

    Right around this time of the year, the gym starts to get a little less crowded. Throughout January, it’s packed to the gills with folks freshly motivated by their New Year’s resolutions to get in shape. But by mid-February, the commitment seems to have all but dissipated.

    Why is it so hard to just commit?

    During my last workout, it occurred to me that the set of vacant treadmills next to mine was eerily reminiscent of the state of enterprise DevOps. According to Forrester, 50 percent of digital transformation efforts stalled in 2018. It seems commitment and follow-through are difficult in both personal and professional arenas. Admittedly, adopting and scaling DevOps is no easy feat. While reflecting on what does work, I found some parallels between the transformation process and DevOps itself.

    What Success Looks Like

    According to DORA’s “2018 State of DevOps report,” organizations with the highest level of DevOps execution, as measured by throughput and stability, also achieved the highest level of business performance in terms of profitability, market share and customer satisfaction. In a true case of going fast without breaking things, elite performers realized impressive performance gains:

    • 46 times more frequent deployments (throughput)
    • 2,555 times shorter lead times (throughput)
    • 7 times lower change failure rate (stability)
    • 2,604 times shorter time to recovery (stability)

    These metrics underlie a key tenet of DevOps transformation, which is breaking up large chunks of work into many small pieces.

    Shrinking the Change

    Smaller changes mean getting work out faster, with less risk. They take less time to plan, less effort to execute and are easier to troubleshoot. But, smaller code changes alone aren’t meaningful unless they are coupled with shorter release cycles. In essence, agile without CD doesn’t work.

    Stockpiling a few months worth of agile code iterations into a single monolithic release reintroduces an enormous amount of risk and negates much of the work done to adopt agile software development in the first place. Big queued-up releases often mean someone is stuck working the weekend to iron out all of the things that inevitably go wrong and no one should be stuck with weekend release duty. As Jez Humble put it, “The most important metric for continuous delivery is the number of person hours spent outside of business hours doing releases… and the goal for that is zero.”

    In practice, CD is what brings agile development to fruition; it’s why Gartner finds that 40 percent of IT departments have already invested in CI/CD with a full third planning to invest in 2019. CD is all about small pieces. In the same way agile enables smaller code changes, CD enables smaller releases.

    Not Just Smaller, but Iterative

    At GitLab we use the phrase, “just commit” as a shorthand for continuous delivery and deployment. The idea is that when you have a completely automated CI/CD pipeline, all a developer needs to do is commit code to their branch, and everything else needed to get that code running live in a production-like environment—from containerization to security testing—is automated. Similarly, getting code to production is as easy as merging the feature branch back into trunk with the entire production deployment automated. The message to the developer is, “Just commit your code and let your DevOps tooling do the rest.” This is CD in a nutshell.

    With this type of automation in place, the cost of making a change significantly decreases. This means the cost of getting started is very low, but so is the cost to keep going. Instead of spending a massive effort to map an entire path to your solution, you simply need to figure out your next step and keep iterating. According to GitLab’s “2018 Global Developer Report,” 67 percent of developers report the top challenge to getting work done is unclear direction. By shrinking the change, business leaders will find it easier to set direction for the next step without having to map the entire path. This brings us back to digital transformation.

    Commit to Digital Transformation

    Just like a monolith being decomposed into microservices, the practice of breaking large chunks into small pieces applies to driving digital transformation as well. Like Creighton Abrams said, “When eating an elephant, take one bite at a time.”

    How can enterprises shrink the change?

    For most organizations that achieve successful digital transformation, the initiative usually starts with a single team or innovation unit. This group proves the success for the rest of the organization. It develops that culture, tools and processes that other parts of the organization can then adopt. One example of this principle in practice is the transformation that Chris Hill, Head of Systems Engineering, Infotainment, led at Jaguar Land Rover. When Chris came on board, only three build engineers had the ability to release to production and it took four to six weeks to complete each release. Chris gradually scaled a CI/CD platform, step-by-step over two years, until every team across the organization was able to complete a release in less than 30 minutes. Today, the Jaguar Land Rover completes 50 to 70 deployments per day. This iterative pattern is seen over and over again with enterprise digital transformation. It’s encouraging because it means successful digital transformation can be driven by either executives top-down or engineers bottom-up.

    Keep the Fuel Burning

    According to Argyle, “91 percent of companies have at least started on digital transformation, but only half have created an organization-wide strategy.” This seems to align with Forrester’s metrics on half of the organizations that stall.

    So, how can organizations keep going and avoid the stall out?

    If I can make a confession, I am also one of those New Year’s resolution makers who just started working out in January. How it is that I’m still hitting the gym while others have dropped off? I have found that taking a “DevOps” approach is a key to my success. Instead of broad sweeping changes, I make small incremental improvements one day at a time.

    It turns out the strategy for getting started—“just commit”—is the same strategy to keep going.

    By starting small with a single project and gradually expanding scope in iterative steps, an organization can continue to improve over time at a rapid pace. Small, single-commit code changes coupled with CD increase throughput and stability. In the same way, small, incremental process improvements bring about the greatest success with digital transformation.

    — William Chia

  • 5 Questions to Ask Remote Web Developers

    5 Questions to Ask Remote Web Developers

    Great web developers are waiting to be hired. Your company could seize upon the opportunity—but only if you’re willing to be patient, dedicated and a little creative.

    Don’t scare away qualified remote web developers with a few poorly worded questions or a mistimed probe. Ask direct and concise questions that can help you understand the candidate.

    Be sure to include the questions listed below to ensure you’re interviewing a remote web developer to the best of your ability:

    1. Have You Worked Remotely Before?

    Remote work is different from many traditional forms of work. For a company to properly manage a remote web developer, the web developer must have a solid understanding and knowledge of remote working environments.

    If an exceptional web developer candidate hasn’t telecommuted before, it doesn’t bar them from the pool of qualified candidates. However, it is easier to onboard and retain remote web developers who have had the experience of working remotely beforehand.

    2. Are You Familiar with Popular Web Development Frameworks?

    Remote web developers, like any other web developer, must stay abreast of the latest trends and advancements in the web development field. To master their craft, they must keep a running knowledge of the latest tools, frameworks and web programming languages.

    An experienced web developer should, at the very least, be aware of a large and robust framework such as Bootstrap. They should be able to explain how the framework works, why web developers use it (it’s much better to utilize a framework to save time, in most cases) and the drawbacks of utilizing a premade framework.

    3. How Much Experience Do You Have with Web Programming Languages? Are You Familiar with Server-Side Languages?

    Every web developer should be proficient in HTML and CSS. Scripting languages such as Angular.js, Express.js and JSON are important, too. JavaScript adds interactivity to websites. HTML acts as the skeleton and CSS acts as the design.

    Preferably, an experienced remote web developer candidate will have three to five years of experience with these languages.

    It’s also important to ascertain whether the web developer you’re interviewing has the ability to code the back end of websites. Do they know how to set up a database? Do they understand how to store values in a website’s database?

    4. Which Content Management Systems Do You Use?

    A content management system (CMS) helps streamline organizing, adding and managing content for a website.

    One of the most popular CMS is WordPress. Web developers leverage CMS to utilize built-in structures and architectures to create dynamic blogs and alluring corporate websites.

    Setting a website up with a CMS also makes it easier for writers, marketers and designers to tweak already-developed websites. They can add content without needing the web developer to intervene.

    5. Are You Comfortable with Regular Phone and Video Meetings? Do You Have Experience with Telework Software?

    Remote work has unique challenges. One of the most challenging aspects of working remotely is maintaining communication. Miscommunication can occur more easily for remote workers, so it’s important that you keep communication lines open and stress the importance of speaking clearly and confidently.

    It’s much better if a candidate already has experience with telecommunication software such as Zoom, Skype or Slack. Knowing how to interact via these technologies will lessen the chances of miscommunication in telework environments.

    Conclusion

    How you conduct a remote web developer interview is entirely up to your organization. There are several methods for conducting technical interviews, telework interviews and startup interviews. Each one of them is effective in a unique way; very few are ineffective or harmful. Adding a few questions to your interview script could help make whichever strategy you employ more effective.

    Ask remote web developers about their experience working remotely. Remember to ask about experience with certain telework software programs and telecommunication applications. On the technical side, be sure to ask about programming skill, familiarity with web frameworks and their experience with CMS.

    Companies that seek to hire remote web developers should take note of the interview questions listed above. By asking these five questions, interviewers can gain a great deal of insight into a web developer candidate’s habits, passions and challenges.

    Using these interview questions should make the vetting and hiring process easier for everyone, helping interviewers assess a candidate’s adaptability, experience and dedication.

    — Anthony Coggine

  • Full-Time Employment in the Age of Automation

    Full-Time Employment in the Age of Automation

    Back in 1930, the economist John Maynard Keynes wrote a short essay, “Economic Possibilities for our Grandchildren,” in which he predicted that in a hundred years the 15-hour work week will be commonplace. Keynes made this assertion based on two factors: first, the increase in capital due to extraordinary yields from the compound interest that was made possible by increased foreign (global) investment; second, the growth of technological achievement made necessary by the competitive forces of capitalism and made possible by the availability of excess capital.

    Keynes pointed out that these events are recent in terms of the entirety of human history, taking place over the last 500 years. Before that time, things were stagnant. Gold reserves remained static until the opening of the New World and technology, save for a few episodic breakthroughs, was pretty much unchanged. For example, the way cloth was made during the time of Joan of Arc, around 1400 AD, was not that different than the way it was made when the Roman emperor Hadrian had a wall built across northern England in 100 AD.

    But, the growing availability of money and technology changed everything. By 1920, the more affluent in the population wore factory-manufactured clothing bought in a store. Those of lesser means might still be making clothes at home, but the cloth from which the garment was made came from a factory.

    Mass-market capitalism powered by technological innovation increased human productivity on a scale unique in the human experience. Abundance on a global scale seemed a real possibility within a few generations. According to Keynes,

    “If capital increases, say, 2 percent per annum, the capital equipment of the world will have increased by a half in 20 years, and seven and a half times in a hundred years. Think of this in terms of material things—houses, transport, and the like.”

    Yet, today most people work 40 hours a week, if not more. Considering that Keynes was essentially a quant who lived and breathed data, how could he get it so wrong?

    My thinking is not so much that Keynes got it wrong, but that we’re having a hard time accepting that he might have gotten it right.

    Allow me to elaborate.

    The Facade of Productivity

    I have a theory: For the average contributor-employee in a medium- to large-size corporation (with 500 employees and more), of all the tasks he or she performs during a 40-hour week, only about half—20 hours’ worth—actually add value to the enterprise. The rest is organizational overhead. Thus, there is a good argument to be made that when you do the math, what we can call real full-time employment is closer to Keynes’s prediction of the 15-hour work week than not. The remaining time, which I call “organizational overhead,” is really just a facade of productivity.

    This theory occurred to me a while back, when I was sitting in a sprint planning meeting observing a project manager and tech-leads do task assignments. The first thing the project manager did was to determine how much time each member of the project team had available to work on the project’s tasks. The agreed-upon number was 20 hours a week.

    The 20-hours a week number struck me as strange. All members of the project team were completely dedicated to the project. They had no side work. The project was their one and only focus. What were they doing with the other 20 hours?

    I asked the project manager and he answered, “Well, they have to do things like answer emails, go to meetings and sometimes there’s some firefighting to be done.”

    Oh.

    The Amazing Ability to Absorb the Cost of Organizational Overhead

    I wish I could say that the project manager’s response was unique. But, in my experience, it’s not. I’ve been in more than one company in which meetings, email and firefighting occupy at least half of a full-time employee’s work week. And, I’ve got to tell you that, except in the rarest instance of mission-critical firefighting, most of these situations have marginal productive value.

    Granted, my theory is based on experiences that are anecdotal. The actual numbers might prove me wrong. Obviously, a thorough, quantitative study is needed. Still, whether it’s five, 10, 20 or even 35 hours a week, what’s amazing is not that employees spend a lot of time in activities that have questionable productive value, but rather, that businesses can actually operate profitably despite these ongoing time-sinks. Why? Because of automation. Machines and software are allowing people to do more work in less time—and it’s not only confined to IT.

    The Dirty Little Secret of Working on an Assembly Line

    Doubling up has always been the dirty little secret of automotive factory work. Ben Hamper revealed the details of technique in his 1986 book, “Rivethead: Tales from the Assembly Line.” Here’s how it works: Imagine that you and I work in a GM plant and do jobs at the same location on an assembly line—say, putting headlights and taillights in a car. Your job is to put in the headlights; my job is to put in the taillights. One day I notice that I can probably put the headlights and taillights in a car in the same amount of time it takes two of us to do the tasks separately. So, I propose a deal to you: I’ll do your job and my job for four hours a day in exchange for you doing the same for me. This way we can both work half time for full-time pay. We might have to pay the line foreman a small bribe to look the other way, but what the heck? The benefits are obvious, so we do it. Win-win, as the saying goes.

    How can we pull this off? Simple: as stated earlier, automation.

    Without the technology of the assembly line, we just couldn’t double up. The car needs to be brought to us for us to increase productivity to the point where one person can do the work of two. The automation of the assembly line effectively reduced our work week while maintaining our productivity, just as Keynes predicted.

    As you can see, the 15-hour work week is quite possible—and, in many cases, quite real. It’s just that the facade of productivity, which exists in larger companies, hides its existence. But, what about the smaller companies such as construction companies, law firms, small manufacturers, dental offices and software startups that employ fewer than 100 people? These types of companies cannot afford a lot of non-productive activity. How do these companies get to the 15-hour work week? Is it possible?

    My answer is yes, but the world that will need to exist to make the 15-hour work week possible will look dramatically different than the one we have today. What will that world look like? Allow me to illustrate using my neighborhood cafe, the C&M, as an example.

    The Real Implications of the 15-Hour Work Week

    My favorite neighborhood cafe is the C&M. It’s a hangout sort of place with good food, good coffee and Wi-Fi. The C&M is usually staffed by two employees during its business hours—7 a.m. to 5 p.m., seven days a week. Between them, they take orders as well as make the food and deliver it to the tables.

    Let’s do the math. Let’s figure that the actual working day at the C&M is 12 hours—10 hours of operation time and two hours of setup and cleanup. That comes out to 84 hours a week. Thus, excluding the owners’ time, the number of employee hours needed to run the C&M is 168. (two employees at 84 hours a week.) This comes out to around four people required to staff the business using the current 40-hour work week model, again excluding the owner’s time.

    Now, let’s say the business is quite profitable and the owner can afford to pay employees $20 an hour, plus health insurance. Adding in payroll tax and workman’s compensation (more than $5 an hour) plus the cost of health insurance ($400 a month, for illustration purposes), the weekly cost of each employee working 40 hours is $1,100, which translates into a total weekly labor cost for the C&M of $4,400.

    So far, so good.

    This time, let’s interpret the C&M labor situation in terms of the 15-hour work week. To cover the 168 hours per week that the C&M is operational, at a 15-hour work week per employee, the C&M needs to employee 11 people—actually, it’s 11.2 employees, but I rounded down. So, under Keynes prediction, if each employee is entitled to the established full-time compensation of $1,100 as calculated earlier, the weekly payroll for the C&M goes from $4,400 a week to $12,100—an almost three times increase, which is not an affordable number. Even though the number of employees has gone up, the odds are that the actual sales will remain the same. Instead of having to employ four people producing $14,000 a week in sales—$2,000 a day over seven days, again for illustration purposes—now the owner of the C&M will be employing 11 people to produce the same amount. Bankruptcy is imminent.

    Clearly, the C&M cannot tolerate 11 people working 15 hours a week for a full-time wage under current conditions. So much for the 15-hour work week. Well, not so fast. Let’s reimagine the scenario from a different angle: Suppose that the number of employees stays at four, but instead of working 40 hours a week, each employee works 15. What could we add to the mix to make this scenario possible? Give up? OK, I’ll tell you: robots.

    Imagine that instead of having two people on hand to set up the cafe, take orders, make the food, bring it over to tables, bus the table and then clean up at the end of the day, we had one person on hand to do what we’ll call human essential work. All the other work gets done by robots. Then, the typical interaction looks like this: Customers enter orders directly into an iPad, the robotic coffee maker gets the order and makes the double espresso, a robot in the kitchen makes the food, with the intermittent help of a human when necessary, and a robot delivers the food to the table. The one human on hand interacts with customers and picks up the slack work the robot can’t do. You can think of the scenario as the restaurant equivalent of a driverless Uber ride.

    Is such a world possible? Yes. In fact, it’s happening as you read this article. There’s already a chain of waiterless sushi restaurants in Japan. As the technology drops in price, more restaurants will make the transition.

    The 15-hour work week could indeed become a real possibility provided that two conditions exist: affordable robotic technology with a high degree of manual dexterity is available, and the employer is willing to pay the higher wages necessary to support the model.

    In the past, workers such as Ben Hamper used their ingenuity to take advantage of the reduction in labor that automation made possible. Sadly, such efforts were clandestine and deceitful. All that GM needed to do to realize a better return on labor was to speed up the assembly line. Yet, when you think about it, back then GM wasn’t doing that badly when Hamper was doubling up. 1984 was a record-setting year in sales, despite his shenanigans. Speeding up the line would undoubtedly increase GM’s bottom line. But, would it double Hamper’s take home? Probably not. (Author’s Note:  GM’s sales dropped 26 percent in 1986, but profits were still a healthy $1.06 billion.)

    So here are two questions to contemplate: As companies, large and small, adopt robotics to increase productivity, will they indeed share the benefits of the increased productivity with the average worker so he or she can enjoy a 15-hour work week? And then, should the 15-hour work week indeed become standard, what will the average person do with all this newfound leisure? As the saying goes, idle hands make fretful minds. According to Keynes:

    “Yet there is no country and no people, I think, who can look forward to the age of leisure and of abundance without a dread. For we have been trained too long to strive and not to enjoy. It is a fearful problem for the ordinary person, with no special talents, to occupy himself, especially if he no longer has roots in the soil or in custom or in the beloved conventions of a traditional society.”

    For those of you that think about such things, I will leave up to you to answer these questions. As for me, I can’t wait for the robots to take over so I can go back to my studies, full-time.

    — Bob Reselman

  • IoT Future-Proofing for the Long Haul

    IoT Future-Proofing for the Long Haul

    Think about this: The IoT application your DevOps team is developing right now, if successful at scale, will likely be the longest-living application in your shop. It may even outlive the tenure of many of your team members with your company. Is IoT future-proofing possible over a life cycle of 10 years or more? Yes, with some insight for the long haul borrowed from industrial and defense computing experience.

    That may sound counterintuitive for DevOps because those industries aren’t exactly known for agile processes. They’re designed around minimizing change and containing risk in mission-critical situations. IoT technology is evolving rapidly and it’s difficult to say what things may look like in a year or two, much less 10. What IoT applications have in common with industrial and defense systems is that they are often complex. Your operational technology (OT) people probably appreciate how complex their existing production environments have been. IoT applications add elements of wireless connectivity, cloud architecture, real-time performance, end-to-end security and algorithmic sophistication.

    At-scale IoT applications will require mastery of complexity, and lessons learned can help. The objective is not to avoid change but rather to “build the airplane while flying.” The core DevOps concept of continuous application release and testing needs to extend beyond just the application code. Teams will need to be detail oriented, looking at device configurations, interoperability, data integrity and how analytic insights evolve as data accumulates.

    Device Configurations

    Buying an enterprise server usually means selecting a commodity: Pick a processor model and frequency, memory size, number of Ethernet and USB ports, storage interfaces and packaging. In the cloud, selections in elastic instances are even easier. As long as the box fits and runs the desired operating system, the details of what’s inside aren’t that important. If you have to buy another one in two or three years, there are likely higher performance choices available.

    In long-lifecycle computing for IoT applications, boxes aren’t commodities. Real-time performance drives differences in processor and board architecture. If you have to buy another one in two or three years, that could be a problem. Vendors often offer industrial and defense customers revision control services, ranging from notification of changes to extended availability of specific configurations. Assuring supply sometimes means a lifetime purchase of components, perhaps as bonded inventory for a customer.

    Interoperability

    Even simple IoT devices, such as wireless sensors, can present a problem on a 10-year scale. Connectivity specifications evolve, with both major changes and minor revisions. Cellular standards reach sunset as mobile subscribers leave them behind. Vendor support for older gear is often given reluctantly, frequently expensive and sometimes non-existent unless an upgrade is executed.

    Choosing interoperable frameworks with robust ecosystems will be critical for success in the long haul. Teams should be prepared with a “plan B” if a vendor is acquired and stops offering a specific configuration, or if they cease operations altogether. Devices with over-the-air (OTA) programming help keep pace with specification changes and alleviate security concerns as they arise.

    Data Integrity

    Teams won’t be able to just stop the IoT plane and work on it. Data collected on day 1 will be just as valuable as data collected on day 3650, if it’s handled correctly through IoT future-proofing tactics. Often, IoT devices connect to networks easily. The real test of an IoT application comes when data starts flowing, perhaps from thousands of devices. Is the data from an authorized device? Is all the data in the correct format? Is it time-stamped properly? Is it checked for errors and missing frames?

    Presumably, when an IoT application succeeds, the temptation to scale quickly sets in. Suppose a new group of sensors is added with the same class of information in a slightly different format. The system should abstract formats and sanitize data at the edge, so all data reaching the cloud is ready for algorithmic processing. For example, JSON is one tool that can help with abstraction. Edge computing may also use generative models to reduce data transmitted to the cloud, forwarding only out-of-bounds conditions for further analysis.

    Analytic Insights

    At the onset of an IoT project, teams have an idea of what they have set out to accomplish. Inevitably, as projects mature new insights come out of analytics. The architecture may not be optimized to deliver those insights in real-time, and changes may be necessary to speed up delivery of algorithmic results. Workflow optimization is an ongoing process for IoT teams. This is the ultimate instance of rebuilding the plane while in flight, extracting more value from an in-place system.

    The Ethos of IoT Future-Proofing

    IoT future-proofing is possible by embracing both the longevity and the complexity of the application. Shifting your team ethos from maintaining a static configuration to developing a living application architecture, helps overcome events certain to happen over a 10-year life cycle and beyond.

    — Don Dingee