Category: Features

  • VMware to Acquire Avi Networks for NetOps Capability

    VMware to Acquire Avi Networks for NetOps Capability

    VMware announced it intends to acquire Avi Networks for an undisclosed price as part of an ongoing effort to close the gap between network operations (NetOps) and DevOps.

    Once this deal closes, sometime between now and August, VMware plans to add a software-based load balancer, along with a web application firewall (WAF) and a service mesh to its network virtualization software portfolio.

    Tom Gillis, senior vice president and general manager for the networking and security business unit at VMware, said the goal is ultimately to make it as simple to deploy applications in an on-premises IT environment as it is on a public cloud by enabling IT organizations to automate the provisioning of network resources exposed via the VMware NSX network virtualization overlay. Avi Networks will extend those capabilities by adding a high-performance programmable load balancer, which eliminates reliance on legacy load balancers based on proprietary hardware platforms that are both expensive and rigid.

    Gillis said VMware will then infuse the WAF technology developed by Avi Networks into its network overlay platform to further secure east-west traffic in the data center.

    Finally, VMware intends to marry the service mesh technology from Avi Networks that supports a high-performance ingress controller with its ongoing efforts to integrate the open source Istio service mesh with NSX.

    Once all that work is completed, Gillis said it should be possible to deploy a workload on any platform with a single click. The challenge organizations face today is that provisioning and securing the network resources required to deploy an application outside of a public cloud computing environment still takes multiple days to sometimes weeks. VMware has already signaled its intention to make NSX network overlays available across multiple clouds and on-premises IT environments.

    Avi Networks CEO Amit Pandey noted that both companies are on a similar trajectory to leverage x86 processors to eliminate reliance on proprietary networking hardware. That shift to software-based networks and security services is driving the biggest transformation in the data center in the last 25 years.

    In terms of leveraging application programming interfaces to automate the provisioning of networks, it’s clear networking technologies have been lagging behind advances made in both compute and storage infrastructure. The challenge and the opportunity vendors such as VMware now see is the ability to more holistically manage IT environments spanning from the network to the application. As part of that strategy, VMware has been making a string of acquisitions to extend its core virtual machine franchise.

    It’s still too early to say whether all those investments will pay off for VMware. Reliance on VMware technologies in public clouds is relatively slight compared to the dominance VMware has today in on-premises IT environments. VMware is banking that its ability to extend the reach of its portfolio to foster the development of hybrid cloud computing, which is strongly anchored around on-premise IT environments that still run the majority of the workloads in the enterprise, will prevail.

    — Mike Vizard

  • CloudBees’ Acquisition of Rollout: The CEOs’ View

    CloudBees’ Acquisition of Rollout: The CEOs’ View

    As Mike Vizard reported yesterday, CloudBees, as part of its mission to build “the world’s first end-to-end automated software delivery system,” announced another acquisition: Rollout, a developer of a feature flag application that allows for simplified testing of new modules within an application.

    Not to repeat the gist of Vizard’s article; you can read it for yourself. But this continues what has become something of an acquisition tear by CloudBees. The company has acquired CodeShip and Electric Cloud, among others, while becoming one of the founding members of the new Continuous Delivery Foundation (CDF), under the Linux Foundation and a sister foundation to the Cloud Native Computing Foundation (CNCF) and the Cloud Foundry Foundation. The CDF is now managing the Jenkins project, as well as Jenkins X, Spinnaker and Tekton.

    CloudBees’ Mission

    Make no mistake: These acquisitions, along with the CDF formation, represent a major change for CloudBees. The team there is clearly trying to separate from the pack of “end-to-end” DevOps contenders. CloudBees CEO Sacha Labourey is pushing hard to raise CloudBees above the noise and the rest of the market. The company announced a $62 million round of financing about a year ago.

    You don’t have to be Warren Buffet to see that CloudBees sees an opportunity here. The company is driving toward achieving scale in product and revenue on the path to some sort of liquidity event (perhaps an IPO?) or market leading opportunity.

    For now, though, back to the Rollout acquisition. I had the chance to sit down with Labourey and the CEO and founder of Rollout, Erez Rusovsky. We discussed what Rollout does, its history and how it will fit into the CloudBees product portfolio.

    It is always great to interview a founder about his company being acquired. What a tremendous feeling of accomplishment to found and build a company, and have another entity value it so much that you are willing to sell it to them. This goes so far beyond validation.

    Congrats to Erez and the whole Rollout team and, of course, congratulations to Sacha, KK and the rest of the CloudBees team. This seems like a perfect fit.

    In the meantime, here is my conversation with Sacha and Erez on the acquisition and more. Enjoy!

     

    — Alan Shimel

  • True Digital Adoption Empowers Humans

    True Digital Adoption Empowers Humans

    True Digital Adoption empowers humans to use use technology which is almost exclusively digital. What are the killer apps that you use all the time? OK, of those handful (for most of you) of apps, how well do you know them?  What percentage of the feature set do you really use? Making better use of the apps we already own is a key factor in transformation.

    Gartner calls this category Digital Adoption Solutions (DAS). According to Gartner, “They assist employees with complex business processes, tasks infrequently performed and change management activities.”  One of the leaders in this emerging category is Walkme.

    Walkme as a Digital Adoption Solution

    I was introduced to Walkme at a recent Insight Ignite event in Iceland. I saw a presentation from Amir Farhi of Walkme. He showed us a demo of how Walkme overlaid on an organization’s Salesforce install made it really easy to use with features that you may not be familiar with. Instantly, digital adoption became real for me.

    Salesforce is, of course, a hugely popular application and in many cases this is a poster child for why digital adoption in general and Walkme in particular is a killer app in and of itself. But Walkme doesn’t end with Salesforce. You can use Walkme on just about any app, both public and your own private apps.  It is a game changer and the bigger your enterprise, the bigger the payoff in using Walkme for digital adoption.

    I invited Amir to join me on a video for Digital Anarchist to discuss digital adoption and show us a demo of Walkme. I am happy to share this with you below. Have a look and listen. I think you will agree that Walkme is one of those rare solutions that is so elementally easy to appreciate, your reaction will be, “Why didn’t I think of this?”

    Here is my conversation with Amir on digital adoption:

    — Alan Shimel

  • Acquisitions to Fuel Programmable Analytics

    Acquisitions to Fuel Programmable Analytics

    Now that Tableau Software has agreed to be acquired by Salesforce and Looker is set to become a part of Google, the rate at which analytics will be embedded within almost every application is about to accelerate.

    Tableau today is relied on by more than 86,000 organizations to surface business intelligence via data visualizations created by professional analysts and line of business executives. That user base accounts for why Salesforce is willing to spend $15.7 billion to acquire Tableau.

    Competition within the analytics software space, however, has always been fierce. The rise of the cloud has resulted in several analytics startups challenging incumbents for a piece of one of the fastest growing sectors of the enterprise software market. One of those startups is Looker, which created a cloud-based analytics platform that Google is now set to acquire for $2.6 billion.

    Google has already signaled its intent to make Looker a part of its expanding Google Cloud Platform (GCP). As such, Google Cloud CEO Thomas Kurian last week noted one of the primary reasons for the Looker acquisition is to add a software-as-a-service (SaaS) offering that will enable developers to embed analytics within their applications by invoking a set of application programming interfaces (APIs) exposed via a cloud service. Today that analytics service runs on GCP alongside the Google BiqQuery data warehouse. Google, however, has also signaled its intent to make Looker available on multiple clouds alongside the rest of its software portfolio.

    Tableau, which will continue to operate as an independent arm of Salesforce, is playing catch up in the cloud. Tableau is deployed widely in both on-premises and public cloud computing platforms, including as a managed service provided by Tableau through which the company manages a dedicated instance of its software on behalf of customers. The merger with Salesforce will create an opportunity for Tableau to add a full software-as-a-service (SaaS) application instance to its portfolio that leverages the same infrastructure that Salesforce employs to deliver customer relationship management (CRM), marketing and customer service applications. Salesforce CEO Mark Benioff this week said going forward, Salesforce fully expects analytics generated by Tableau to drive a raft of digital business transformation initiatives.

    Most of the analytics that will be embedded within applications will manifest themselves in three forms. The first is embedded software that will be updated continuously as new data is entered in an application. The second is embedded predictive analytics modules that will invoke big data repositories and machine learning algorithms to surface recommendations on how to optimize a business process or customer experience. The third—and more ambitious—goal is an embedded prescriptive analytics capability that automatically optimizes business processes and customer experiences in real time based on events occurring, for example, within an internet of things (IoT) application.

    Every provider of analytics capabilities, from traditional Tableau rivals such as Qlik Software and Microsoft to TIBCO Software, IBM, MicroStrategy, SAP, Oracle and host of others, is pursuing all these emerging use cases for programmatic analytics. Most recently, Information Builders revealed it has embraced Docker containers and Kafka messaging platform as a means for achieving that analytics goal.

    The arrival of programmable analytics platforms will, of course, make implementing best DevOps practices all the more challenging. It’s hard to think of a business process that will not benefit to some degree from embedded analytics. The challenge DevOps teams will face is embedding and then continuously updating all the analytics modules embedded within the applications they deploy. The good news is that as organizations move to embed analytics everywhere increases, so too does the need to embrace DevOps to manage it all.

    — Mike Vizard

  • CloudBees Acquires Rollout for Feature Flagging

    CloudBees Acquires Rollout for Feature Flagging

    CloudBees today announced it would extend the reach of the Jenkins continuous integration/continuous development (CI/CD) platform by acquiring Rollout, a provider of feature flag tool that gets employed to simplify testing of new modules within an application.

    Company CEO Sacha Labourey said the acquisition of Rollout would result in a feature flag capability that is more seamlessly integrated with the gates that make up a CI/CD pipeline process. The goal is to make it easier for DevOps teams to apply A/B testing of new application features against a subset of users before deciding to update an entire application environment, he said.

    Feature flagging, also known as feature toggling, enables DevOps teams to hide features from certain users at runtime. In effect, this creates multiple branches from the same source code that DevOps teams need to manage. Rather than having to employ a separate tool based on an entirely different user interface, CloudBees is moving to make feature flagging a core capability of its extended toolchain.

    In theory, feature flagging should be more widely employed than it is today. Many organizations, however, have found it challenging to incorporate separate feature flagging tools within their DevOps processes. CloudBees is now using some of the money it has raised of late to address that issue.

    Feature flagging today is largely confined to testing. However, there may come a day when more organizations will employ feature flagging to make different classes of user experience available to different end users. That approach, in theory, would make it possible to charge different fees for disparate application experiences using the same core application.

    In the meantime, the goal is to garner more feedback concerning new capabilities that might be added to an application before the features are made generally available. Developers often spend months developing new features only to discover end users are not employing those capabilities because of some trivial glitch that could have been discovered easily using A/B testing.

    There currently is no shortage of options when it comes to tools for implementing feature flagging. Labourey said CloudBees elected to acquire Rollout because the team behind it was deemed to have the best cultural fit with CloudBees. It’s too early to say whether other providers of feature flagging tools will be rolled up into other CI/CD platforms—providers of those platforms can either develop their own feature flagging toolsets or move to absorb a third-party provider either by acquiring them or forming a technology alliance. The depth of the toolchain being provided these days often has as much to do with what CI/CD platform ultimately gets adopted as the core integration and delivery capabilities.

    Regardless of the path chosen, it’s apparent that thanks to feature flagging, continuous testing processes will become more sophisticated. That may require some adjustments to existing best DevOps practices, but the days when development teams blindly experiment on end users in the hopes they are building the next killer feature mercifully are coming to an end.

    — Mike Vizard

  • Which Desktop OS Is Best for DevOps?

    Which Desktop OS Is Best for DevOps?

    Which operating system (OS) is best for DevOps engineers to use on their workstations?

    That’s a weighty question. Talk about which OS is “best” for any purpose is always controversial.

    I’m not going to stick my neck out by saying that one OS is definitively better than others when it comes to doing DevOps work. But I would like to consider the strengths and weaknesses of each of the major desktop operating systems—Windows, Linux and macOS—for performing DevOps work.

    Windows

    Statistically speaking, Windows is the OS that most people use. By extension, it’s the OS that most DevOps engineers probably use. (I can’t confirm that fact, because I’ve yet to see a study of which OS DevOps engineers actually use.)

    As I see it, Windows has two main advantages from a DevOps perspective, including:

    • Popularity. This is a strength because DevOps is all about having freedom to pick and choose which tools to use. Given that Windows is so popular, almost everything is compatible with it. OS compatibility problems, therefore, don’t get in your way of doing DevOps as you see fit.
    • The Windows subsystem for Linux, which lets you run some Linux CLI tools on Windows. This feature is handy if you need to do DevOps work for both Linux and Windows server environments.

    The main drawback of relying on Windows is that, well, it’s Windows. Compared to Linux, Windows offers very little opportunity to customize, and that restraint can be a drawback from a DevOps perspective. When it comes to core tasks, such as working from the command line, you’re stuck with the tools Microsoft offers you. And you can’t do very much to harden your Windows system for security purposes.

    Linux

    For my money, Linux is the best OS for DevOps. But I say that only because I’m a die-hard Linux lover and I tend to think Linux is the best for everything.

    But even if you are not a Linux fanboi, you have to admit that it has certain advantages for doing DevOps work:

    • Linux is ultra-customizable. You can choose to set up your system in whichever way works best for your workflow. You can use a wide array of tools. You can make lots of changes to add extra security. Given that DevOps values choice, this is a big benefit.
    • In many cases, DevOps engineers are supporting software delivery pipelines that deploy to Linux server environments. Being able to work from a native Linux environment can make it easier to do things such as test and stage those applications on your local device when it becomes necessary to do so. You could, for example, spin up a Linux container on your local machine, which you couldn’t do with a Windows or macOS workstation.
    • On most mainstream Linux distributions, installing all of the DevOps tools you need is extremely fast and simple using repositories and package managers. It’s not exactly difficult to install most DevOps tools on other systems, either, but I don’t think any OS can beat the package management systems used by Linux distributions.

    Linux’s major limitation is that learning it takes some time, particularly for DevOps engineers weaned on Windows. You also run the risk of needing a tool that doesn’t support Linux, although I’m having a difficult time thinking of any DevOps tools that doesn’t work on Linux systems.

    MacOS

    Last but not least is macOS. Overall, I don’t think macOS is ideal for doing DevOps work. The only strength I can think of is:

    • It gives you a native Unix-like environment. You can’t run your Linux containers directly on a Mac, but you can at least use some native Unix tools.

    Drawbacks for macOS are many. It’s not very customizable. It lacks compatibility with some applications and tools. It comes with its own learning curve if you have never used a Mac before.

    Does OS Choice Even Matter?

    Now that I’ve weighed the pros and cons of Windows, Linux and macOS as operating systems for DevOps engineers, let me state the obvious: It’s 2019, and in many respects it no longer really matters which OS you run on your local machine. Lots of applications—including key DevOps tools, such as IDEs—now run in the cloud as often as not. Plus, there are a plethora of hardware virtualization tools out there that will let you run virtually any OS in a virtual machine within another type of OS. You can run Linux and Windows side-by-side as virtual machines on your Mac, if you want.

    Still, not everything runs in the cloud, and having to switch between virtual machines is not always practical. It’s therefore worth thinking hard about which desktop OS will best serve your DevOps needs and making that the one that controls your bare metal.

    — Chris Tozzi

  • Textbook DevOps vs. Real-World DevOps

    Textbook DevOps vs. Real-World DevOps

    DevOps is one of those things—like Marxism or baking macarons—that is easy to understand in theory, but much messier to implement in practice. Real-world DevOps rarely aligns with textbook DevOps or the DevOps practices that organizations should follow in theory.

    That is true for a number of reasons. Let’s walk through some of the biggest below.

    Your Company Is Not Organized in the Way DevOps Theory Assumes

    According to DevOps theory, every company has an IT department and a development department. Doing DevOps boils down to making those departments work well together.

    The reality, of course, is that not all companies organize their staff or technical operations in this way. Some don’t silo developers and IT engineers by default. Others (especially smaller companies) don’t have developers or IT staff on hand at all; they outsource that work.

    These companies can still benefit from DevOps principles such as collaboration and automation. But they should avoid fixating on DevOps teachings regarding the organization of technical work.

    Real DevOps Skills are Hard to Find (And Expensive to Obtain)

    “DevOps engineer” is now a trending job title. But few technical training programs have caught up with the demand for DevOps.

    Most universities still silo majors and courses in software development away from those that focus on IT. Other types of technical training programs function similarly.

    What this means is that it is more difficult to hire a DevOps engineer, or other technical staff with a broad set of development and IT skills, than it may first appear. DevOps engineers exist, but they are usually experienced staff who learned their real-world DevOps skills on the job. They’re more expensive to hire and difficult to poach from their current gigs.

    Full Automation Is a Pipe Dream

    The DevOps mantra tells us that we should automate everything, from software testing and builds to deployment, production-environment monitoring and incident response.

    Automation is great in theory. But the reality is that you can never automate everything. Human engineers will still need to respond to problems occasionally, or to unanticipated issues that arise during testing, deployment and production management.

    An important point to emphasize here is that even if you successfully automate virtually all of your processes, the mere fact that human engineers must be available to respond when something does go wrong undercuts the idea that you can rely on automation alone. Humans still have to watch the automated processes, even if they rarely need to intervene. The simple act of watching and being available to respond when necessary is a significant burden.

    Agility Conflicts With Simplicity and Reproducibility

    In some respects, DevOps is a contradiction. On the one hand, it prioritizes agility and scalability. On the other, it emphasizes simplicity and reproducibility.

    What this means in practice is that DevOps teams adopt microservices and containers in the interest of maximizing agility. But microservices and containers are much more complex to manage than monoliths and virtual machines.

    I suspect the reality is that most DevOps organizations end up erring toward more complex technologies and architectures. They ultimately find greater value in them than they do in keeping things simple.

    Still, the idea that you can be agile and be simple at the same time doesn’t apply well in the real world. (And sure, automation, infrastructure as code and the like can help in simplifying the management of complex agile technologies, but they only go so far.)

    Most Organizations Still Aren’t Doing DevOps

    If you spend your time surrounded by other people who have adopted DevOps and implemented it successfully, it’s easy to assume that the rest of the world is like you.

    The reality, however, is that we’re now a decade into the age of DevOps, and yet a majority of organizations have made only halting steps toward implementing basic DevOps processes. If DevOps were half as easy to implement as it appears to be when you read the latest book about how to do DevOps, many more companies would be doing CI/CD by now.

    Conclusion

    DevOps delivers real benefits, and it’s important to continue preaching the DevOps gospel to organizations that can benefit from DevOps philosophy and practices.

    However, it’s important to balance the conversation about DevOps with the reality: Real-world DevOps is much messier than it often seems in theory. Not many organizations have the configuration or resources to do textbook DevOps.

    — Chris Tozzi

  • Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    How Red Hat’s Open Innovation Labs have helped accelerate Lockheed’s software development for the F-22 Raptor

    As the key government contractor charged with helping the U.S. Air Force keep its F-22 Raptor jets in fighting trim, Lockheed Martin Aeronautics increasingly values software delivery speed as much as engine speed. So much of the continued evolution of these fighter jets depends upon continual upgrades of the software code powering all of the physical systems built into them, from tip to tail.

    Until a year ago, these jets, which first rolled out of the manufacturing plant in the 1990s, were supported by the waterfall development methods of that same era. Lockheed executives and Air Force brass recognized that the F-22 needed a DevSecOps transformation, and fast.

    “When you have a world-renowned platform like the F-22 Raptor, adversaries are constantly looking for ways to counter it,” said Michael Cawood, vice president of F-16/F-22 product development at Lockheed Martin. “This means we must constantly add capabilities and improve the F-22. And we must do it faster than ever before. We needed to transform our own organization and how we did things.”

    To accelerate that process, Lockheed last year sent a small contingent of engineers through a residency program at the Red Hat Open Innovation Labs to fast-track the process of implementing an open source architecture onboard the F-22 while adopting agile development methodologies and DevSecOps practices. Since bringing back their learning to the organization, these engineers helped to catalyze a faster development process that has helped Lockheed introduce software features for the F-22 years ahead of schedule.

    How Open Innovation Labs Works

    Now in their third year of operations, the Open Innovation Labs were developed by Red Hat as immersive training grounds to help its enterprise customers figure out how to deliver better software, faster. A standard engagement has companies such as Lockheed pay for residency for anywhere between three to six developers and operations staff to get paired one to one with Red Hat employees—engineers, consultants and others—with deep knowledge in DevOps and agile development. They work with them in a time-boxed four- to 12-week engagement to build out application prototypes using DevSecOps practices along the way. The residents are also teamed with a designer and an engagement lead who doubles as an agile coach, typically working with the customer’s product owner for the prototype.

    Obviously, Red Hat has a vested interest in training these people in technology such as its OpenShift Container Platform, getting them up to speed on how to orchestrate and manage containers and microservices. But the labs approach is in a different league than the standard vendor training program. It more closely follows the DevOps dojo model that enterprises like Target and Capital One are running internally to scale up cultural and process transformations across their IT organizations. Like those dojos, the working model is to build real software through a guided learning process that helps participants get hands-on experience in how to change the way they deliver software.

    Red Hat runs the labs either out of a handful of dedicated spaces it runs around the world or within pop-up labs of the customer’s choosing. Besides Lockheed, other notable alumni include the likes of Volkswagen, UNICEF and Heritage Bank. According to a recent analysis by Forrester Consulting, participants in the Open Innovation Labs program are accelerating application development by more than 60%.

    Lockheed’s Accelerated DevSecOps Transformation

    In Lockheed’s engagement with the Open Innovation Labs, the organization sent out a cross-functional team of five developers, two operators and a product owner. They were tasked with building out a new application for the F-22 on OpenShift, using that process as a model for future development workflows. As a part of the process, Lockheed also worked with the labs to help it build out an internal dojo that could facilitate the scale-out of the knowledge gained by its small team across the entire F-22 development team. Six months after the initial residency, Lockheed managed to scale its OpenShift deployment and DevSecOps transformation across its entire 100-person team.

    “By working with the Red Hat Open Innovation Labs team, we changed everything—our toolchain, our process and, most importantly, our culture,” explained Cawood.

    As a result, the F-22 development organization has been able improve its ability to forecast for future sprints by 40%. More importantly, it has cut what was once an onerous five- to seven-year process of rolling out new software capabilities for the aircraft. Lockheed is on track to deliver new communications capabilities for the F-22 this summer a full three years ahead of schedule.

    — Ericka Chickowski

  • Digital Transformation Vital for Business Survival

    Digital Transformation Vital for Business Survival

    Businesses are in a fight for their survival, and they know it. Their direct competitors, large and small, are digitizing their businesses. And those businesses that effectively digitize first have much to gain competitively. However, as we’ve reported in “Digital Transformation: Coming from Behind” and other stories, many organizations are experiencing significant challenges when it comes to executing on their digital transformation strategies.

    To get a sense of where companies are in their efforts, managed SD-WAN and cloud services provider Masergy contracted research firm Webtorials to conduct its 2019 Digital Transformation Market Trends Report. The report is based on a survey of large and small companies in 35 countries, and it found that the early digital transformation wins tend to be among customer-facing investments, such as customer service and customer experience.

    Not surprisingly, the report found 78% of respondents believe that their company’s primary industry is rapidly evolving and that digital transformation is necessary to survive the change underway. The benefits respondents cited (ranked in order) were enhanced customer experience and customer relationship management, the ability to maintain competitiveness, enable new ways of doing business, increased productivity, cost savings, increased revenue generation and enhanced product development.

    With the majority of digital transformation efforts failing to meet their established objectives, businesses are clearly facing no shortage of obstacles. According to the Masergy survey, the challenges respondents cited as barriers to a successful digital transformation effort, in order of difficulty, are budget commitment, executive support, in-house skill sets, organizational buy-in and lack of adequate IT infrastructure.

    These findings paralleled findings from other related and recent surveys, including the “State of Digital Transformation” report from research and advisory firm Altimeter. The report found that CIOs (28%) or even CEOs (23%) typically own digital transformation at an organization. That report also found that enterprisewide support is a leading barrier, with many organizations citing the belief that digital transformation is a cost center (28%), elusive ROI (29%) and resistance to change (26%) also are barriers.

    The survey also found that only one-third of respondents believe they can meet their digital transformation goals without help from a solutions provider. This finding parallels other reports. Earlier this year, IDC found that business services related to digital transformation will grow at a healthy 29% annual rate over the next five years.

    Interestingly, the “2019 Digital Transformation Market Trends Report” from IDC found those looking for outside help prefer smaller service providers (58%) rather than larger providers (43%).

    What technologies most support digital transformation? According to this survey, those that help in migrating to cloud or in improving security, as well as data analytics and AI, mobility, collaboration and emerging technology such as virtual reality and IoT.

    These reports show that while businesses are aware of what is at stake for their enterprises, the bad news is they are having a hard time making headway. The good news is that it doesn’t appear too late, just yet, for businesses to get their digital houses in order.

    — George V. Hulme

  • Technology: Isolation in the Age of Automation

    Technology: Isolation in the Age of Automation

    Dependence on technology makes us more independent overall, but it also makes us more isolated. So, what happens if things come to the point where we depend on machines more than we depend on other human beings?

    Earlier this month I attended a presentation about machine learning on mobile phones at Google IO 2019. Right now Google is spending a lot of time and money developing machine learning models and capabilities that operate solely within the mobile device. No connection to the internet is required. It’s a big deal.

    During the presentation, the company showed a video that featured an illiterate woman in India who uses her phone’s text recognition features to read to her. All she needs to do is point the phone’s camera at a recipe or newspaper and the phone converts the text to speech.

    I found the story inspiring as a technologist and as a human being. But it’s not all peaches and cream. At the end of the video, the woman said something that gave me pause. When talking about using the technology to book a train ticket, she said, “I can book it myself. I don’t need anyone’s help.”

    There’s no doubt the phone liberated her, very much in the same way that the light bulb liberated millions of other people in times past, bringing human activity forward beyond the setting sun. Dependence on a particular technology can create greater independence overall. However, I do wonder what happens when things evolve to the point where we depend on machines more than we depend on others, when we no longer need “anyone’s help.”

    To my thinking, human interdependence is the thread that binds the fabric of a society together. The thousands of little interdependencies that make up the human experience have beneficial side effects. To get along, we learn the basic rules of civility. We learn to say “please” and “thank you.” We learn how to wait in line at the DMV. We pick up after our dog. We open the door for others. It’s all part of the implicit contract that makes living with other people possible.

    But, these days it seems we depend more on machines than the kindness of strangers. The fact is, you don’t have to be nice to a machine, even for a self-serving purpose. You can yell at your cell phone. You stick your tongue out at the ATM as it accepts your deposit. Whether you’re nice to it or not doesn’t matter. Your deposit is not going to be processed any faster or slower. Your cell phone isn’t going to disconnect you because you were rude to it.

    Take away these simple rules of civility and strange things happen. It’s interesting that road rage is common, yet sidewalk rage is rare. Maybe wrapping ourselves up in a piece of silicon-powered transportation hardware predisposes us to a hostile attitude when interacting with others in the same situation.

    As I stated earlier, depending on technology makes us more independent in the big picture. But, it also makes us more isolated. Whereas in the past, talking about the weather with a stranger might be a prelude to another conversation that’s more meaningful, today the stranger next to me usually has his ears plugged up listening to his own interests. And, if I really want to know about the weather, I can ask Alexa.

    Modern technology gives me help on demand. I no longer ask a stranger for directions to the train station, I use my phone. It seems as if I need the help of others less during those small, random moments of vulnerability. A machine is but a voice prompt away. And, thus, the thread that binds me to the world at large gets a little bit looser.

    Now don’t get me wrong—isolation is nothing new. Five hundred years ago most people never traveled far from where they were born except on very special occasions. Village life is a case study in group isolation. But, while villages were isolated from the outside world, inside the village it was a different story. The social fabric was dense; the threads were tight. Being shunned by the group was a matter of life and death.

    Today we’re all over the place, literally. But we move in our own domains in which we end up wishing happy birthdays to people we’ve never met but who somehow have meaning to us by way of LinkedIn, Facebook and the plethora of other social platforms brought to life and sustained by something other than human labor.

    Is this such a bad thing? Dunno. I like it that my phone is now my personal stenographer. It helps me think better. But, I’m not sure that Google Assistant will ever be a good best friend. What’s even stranger is that a time might come when I don’t even need one. It will be just me and my mobile device. Then I won’t need anyone’s help, ever.

    — Bob Reselman