Category: Blogs

  • Enterprise ML Investments on the Rise

    Enterprise ML Investments on the Rise

    The second wave of enterprise artificial intelligence and machine learning (AI/ML) adoption is building, and is expected to crest in 2021, as many organizations increased and accelerated their investments in tools and people.

    That was one of the unmistakable conclusions of our 2021 enterprise trends in machine learning report: 83% of the companies we surveyed said their AI/ML budgets had increased year-over-year, and we found that the average number of data scientists they employ has increased by 76% year-over-year. These changes came even as many organizations tightened their overall spending and refocused their strategic priorities amidst all of 2020’s disruption and uncertainty related to the COVID-19 pandemic. These companies aren’t simply moving forward with their AI/ML initiatives in spite of the pandemic; they’re doubling down on their investments because of it.

    Many organizations have begun to understand just how critical ML is to remaining competitive in uncertain and rapidly evolving conditions. When we ran a separate survey during the summer of 2020 to find out how businesses adapted to the pandemic’s impacts, it revealed a renewed sense of urgency around AI/ML investments: 43% of respondents said that AI/ML mattered “way more” to their business than they’d previously realized.

    Our independently conducted 2021 report included input from more than 400 leaders and practitioners across a diverse mix of technical and business functions, all of whom have a stake in their organization’s AI/ML strategy. They’re not just increasing their spending and staffing, either – they’re accelerating their pursuit of a growing number of enterprise ML use cases, with customer experience and automation leading the way.

    You need to be doing this, too. The second major wave of enterprise AI/ML adoption is underway, and you can still capitalize on the immense opportunities ahead. But the time to act is now. Organizations that take a “wait-and-see” approach are at risk of being left behind, particularly as so many other companies are scaling up their investments. Not only are your competitors increasing their AI/ML budgets (evident in the 83% YoY increase mentioned above), but they are moving their initiatives to the top of their strategic priority lists. Approximately three out of every four respondents (76%) in our 2021 report said they are prioritizing AI/ML over other IT initiatives, with 28% reporting that it is their top priority overall. These companies have realized that their success is directly tied to their ability to adapt to rapidly changing business conditions — and that AI/ML is the key to doing so.

    This is no longer the sole purview of elite technology companies. Companies of all sizes, across just about every industry, can get up and running with AI/ML, thanks in large part to the spread of easy-to-use tooling. The opportunities are more accessible than ever. You don’t need a ton of time or resources to get started — and it’s absolutely crucial that you do so soon.

    Your competitors are actively pursuing AI/ML initiatives today, regardless of your specific industry. We’re seeing many longstanding enterprises begin to drive huge transformations of their businesses and industries with AI/ML. More and more use cases are being pursued in legacy industries, from insurance to agriculture, healthcare to financial services and more. The bellwether financial firm JPMorgan Chase, for example, has even built an entire AI research program and data platform. There are virtually no industries where this is irrelevant. So, you need to act with urgency, as this second wave of enterprise adoption intensifies.

    You also need to build for operational efficiency and scale. We think of this as industrializing your machine learning operations (MLOps). While easy-to-use tools reduce the barrier to entry, they only get you partway to your destination. Invest in repeatable, automated processes or you’ll hit a wall of technical debt and other potential issues. MLOps paves the road to tightly integrated, well-aligned technology stacks, processes and teams that make it easier, not harder, to deploy more models in the future. This isn’t something you can wait on; if you’ve manually bootstrapped the deployment of even a handful of models to production, you need MLOps. Without it, you’ll quickly accrue unnecessary technical debt that will inevitably hinder your organization’s ability to scale and deliver meaningful business value.

    This is already a significant issue. Our 2021 report found that, while many organizations are increasing budgets and prioritization, it’s taking them longer to get models into production. Data scientists are still spending too much of their time on operational tasks, a problem that worsens as the number of models in production increases. This tells us that even as many organizations increase their spending and hiring, they’re actually allocating more of their growing resources toward manually scaling their AI/ML initiatives instead of investing in the operational efficiency that will maximize results.

    There’s a better way. Organizations no longer need to take a DIY approach to MLOps. There are robust solutions that can simplify many of the complex issues involved in scaling your AI/ML initiatives in production. Our report found that companies that use third-party MLOps solutions see improved outcomes compared with companies that go it alone and build and maintain everything themselves. They spend less on infrastructure, deploy models to production faster and tie up less of their data scientists’ time on model deployment.

    The pattern here is clear. Regardless of your particular industry, more and more businesses are identifying a growing list of use cases for AI/ML that can help transform their businesses and boost their competitiveness. They’re industrializing their AI/ML initiatives with MLOps to ensure their technology stacks, processes, and people are well-aligned. And, by doing so, they’re positioning themselves to rapidly adapt to and act on changing signals in their businesses.

    Don’t make the mistake of thinking AI/ML doesn’t apply to you or your industry. Doing so would mean missing out on potentially massive strategic opportunities, from new or growing revenue streams to increased efficiencies throughout your business operations. Your competitors are doing it; it’s easier than ever to get started and third-party MLOps solutions can help minimize technical debt and other operational complexity that will otherwise limit the positive business impacts of your initiatives.

    You can absolutely get in on the second wave of enterprise adoption, but the time to act is now. You can’t afford to wait.

  • BMC Tightens Integration Across DevOps Tools for Mainframes

    BMC Tightens Integration Across DevOps Tools for Mainframes

    BMC has extended its BMC Automated Mainframe Intelligence (AMI) and BMC Compuware portfolios as part of an ongoing effort to make mainframes just another platform for DevOps teams to build and deploy applications on.

    John McKenny, senior vice president and general manager for Intelligent Z optimization and transformation at BMC, said the DevOps technologies that the company gained last year with the acquisition of Compuware have now been fully integrated with the rest of the BMC mainframe portfolio.

    The BMC Compuware continuous integration/continuous delivery (CI/CD) platform has been integrated with Visual Studio Code, a free tool from Microsoft that is employed widely by developers, he added.

    The BMC Compuware ISPW solution integrates with Visual Studio Code to enable developers to compile changed code on the mainframe with a right-click.

    In addition, the BMC Compuware Topaz platform for applying DevOps practices to the development of mainframe applications has a new command-line interface (CLI) along with support for multiple application programming interfaces.

    A BMC Compuware File-AID 21 tool now makes it possible to reduce the time required to search billions of transactions and log files on a mainframe, while the BMC AMI Security tool has been integrated with the BMC Helix IT service management (ITSM) platform.

    Finally, the BMC AMI Ops Insight tool has been updated to provide diagnostic capabilities to more easily identify the probable cause of an issue, while the BMC AMI SQL Performance for DB2 tool now includes a plug-in for the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    McKenny said the goal is to integrate mainframes with any DevOps workflow as part of an effort to either deploy new applications or modernize legacy applications already running on the platform. Modernization of mainframe applications is being driven by the need to add application programming interfaces (APIs) to mainframe applications that need to be integrated with a much broader array of distributed applications, he noted.

    Much of the demand for those APIs is being driven by digital business transformation initiatives that require applications to be able to access backend transaction processing and analytics applications running on mainframes, added McKenny.

    It’s not clear at what rate IT teams that build and deploy applications on mainframes are moving away from waterfall-based processes to embrace best DevOps practices. However, McKenny noted, the rate of changes being made to mainframe applications has accelerated significantly over the last few years.

    While large numbers of applications have been migrated off mainframes over the last decade, the number of enterprise IT organizations that continue to rely on the venerable platform to process transactions remains considerable. Many organizations aren’t convinced that it’s worth rewriting the applications they have relied on for decades when it’s easier to make them more accessible to other applications by adding an API. In effect, McKenny noted, mainframe applications are becoming just another microservice that can be invoked by a developer.

    Regardless of the motivation, it’s clear mainframe applications will continue to run well into the next decade. The challenge IT teams now face is finding a way to make those mainframes just another platform on which to deploy applications at the end of a DevOps toolchain.

  • GitLab Survey Surfaces Advances in DevOps Education

    GitLab Survey Surfaces Advances in DevOps Education

    As more organizations clamor for employees with some type of DevOps education, higher education is responding in kind, according to survey findings.

    A survey of 843 students and teachers at various academic institutions who have had some exposure to the GitLab continuous integration/continuous delivery (CI/CD) platform suggests the number of individuals with DevOps skills graduating from these programs soon might increase significantly.

    The survey, which was conducted by GitLab, identifies the top four use cases for the platform as learning (28%), teaching (22%), research (20%) and information technology/professional use (19%). Nearly a quarter (22%) also indicated they had a secondary use case on campus.

    Certification (57%) was ranked highest in terms of interest, followed by e-learning (49%) and virtual instructor led-training (35%). Students and graduate students are more interested in certification at 58% and 67%, respectively, while administration, faculty and staff were more interested in e-learning.

    The primary benefit of teaching and learning GitLab was identified as the ability to teach operations competencies (57%) and the ability to teach with an end-to-end tool for learning DevOps competencies (51%). For students specifically, the top benefit cited was the ability to teach operational competencies (49%), followed by the ability to build a portfolio and record of contributions (45%). Workforce readiness was cited at 40% and 46% of students and faculty, respectively.

    Dr. Christina Hupy, senior education program manager at GitLab, said the teaching of best DevOps practices within an academic environment is critical because it takes on average six years for IT professionals to master DevOps in the workplace. To help increase the overall pool for DevOps talent, GitLab has been making its software available for free via individual licenses to students and teachers. That program is now being extended to include a GitLab for Campuses offer, which makes the GitLab platform available to multiple users at a reduced price.

    In general, higher education programs have not been meeting the needs of organizations that are looking to hire IT professionals with proven DevOps skills, noted Hupy. Since launching the GitLab for Education Program in 2018, GitLab is trying to help fill that void, issuing more than $2 billion worth of GitLab software licenses in more than 75 countries. In 2020, the organization added 340,000 seats across 250 institutions to the program.

    More than a third of survey respondents (37%) reported they had access to a GitLab subscription at their institution and used it. The most common use case for GitLab cited was source control management (55%); followed by verification, also known as continuous integration, at 36%; planning, at 30%; and management and release, also known as continuous delivery, at 27% each.

    There is also significant use of GitHub among survey respondents, with 85% reporting using it. A distant second was Jenkins (21%), followed by BitBucket (17%), Travis CI (11%) and GitHub Actions (15%).

    IT organizations, of course, have a vested interest in helping educational institutions develop DevOps programs as the number of application development projects being launched simultaneously continues to increase. Otherwise, they will find themselves paying top dollar for DevOps talent that is difficult to find and retain. The challenge, of course, is identifying the institutions that have access to the DevOps tools and platforms that are going to be a pre-requisite for a successful DevOps career those students might eventually enjoy.

  • DevSecOps: Rethinking and Reengineering Cloud Security

    DevSecOps: Rethinking and Reengineering Cloud Security

    Organizations are embracing the cloud to modernize legacy applications, create more resilient business infrastructures and to support remote work. In fact, Deloitte’s “TMT Predictions 2021: Cloud Migration Trends and Forecast” report suggests that, spurred by this growth, cloud revenues will likely continue to remain above 30% through 2025. While cloud migration is predisposed to embrace an agile development methodology enabled with DevOps, many organizations still leave themselves open to risk when modernizing and migrating applications to the cloud by neglecting to embed security into their development operating model, architectural design and processes.

    When migrating to the cloud to modernize applications, DevOps and DevSecOps, as an architecture process, can enable organizations to rethink and rearchitect the security model with a “security by design” approach. If done right, organizations stand to create more secure and agile applications that balance the need for continuous releases in an evolving threat landscape with building customer trust.

    DevSecOps Requires a New Operating Model

    DevOps is a demonstrated approach to achieving better value, sooner, from IT programs and is seeing new developments in an increasingly distributed work environment. Previously, organizations may have relied on a shift-and-adopt strategy for incremental cloud replatforming. But, today’s rapidly shifting business strategies demand fast reaction time and resilient solutions, as well as flexible and agile solutions supported by DevSecOps to help development and security move at the same pace as the business.

    Importantly, DevSecOps requires an integrated team of cross-skilled cloud and cybersecurity specialists working under a shared operating model. A modernization and migration center of excellence (CoE), often led by the digital transformation leader, can help bring together cloud and cyber specialists from across the business with external cloud service providers via a shared responsibility model. Through collaboration, cross-teaming, cross-skilling and a shared operating model across cloud developer and security functions, organizations can achieve better outcomes.

    Embracing “Security by Design”

    DevSecOps, then, is about more than moving existing security processes earlier into the development process. It is about elevating, embedding and evolving your organization’s risk response, as well as rethinking and rearchitecting the way applications are designed with security as a guiding factor in the architectural decisions. Secure by design means setting up a whole DevSecOps capability to make sure security is embedded early on in application architecture design and then further safeguarded through strategies like segmentation, zero trust and attack surface management.

    Before the migration begins, DevSecOps would have developers and security specialists considering data flows, functional requirements and work streams related to workload protection, secure landing zones, operating model, network segmentation, access/controls to be implemented in a zero trust environment, attack surface management and more. An organization, for example, might use microservices to segment application access for internal versus external users to achieve enhanced security through system design.

    DevSecOps Requires Process Innovation

    DevOps and DevSecOps bring the security and application teams together with shared processes and communication to quickly, securely and efficiently roll out products from concept to production at pace. During the pandemic, teams have pushed their use of communication and collaboration tools to better support distributed teams, including the use of ChatOps, to enable real-time knowledge sharing and knowledge management, increased DevOps automation through incorporation of cloud artificial intelligence (AI)/machine learning (ML) services and reimagining traditional roles to embrace more of an IT-as-a-service operating model.

    DevSecOps

    As DevOps continues to shift left beyond DevSecOps to embrace operations, governance, and customer support, developers will need to work on increasingly integrated teams. These foundational communication leading practices can be valuable as a model for agile working across functions.

    Rethinking Cloud Security and Development

    DevSecOps can help support cloud migration and agile development programs that require speed and resilience by rethinking the development operating model, architecture approach and collaborative processes to improve security and compliance and enhance customer trust. Security specialists must understand the demands placed on developers for fast migration and continuous releases and developers need to work with cyber professionals collaboratively to make applications designed to be secure and resilient. A security-by-design approach to cloud cyber collaboration can help organizations to rethink and re-engineer their DevSecOps approach. Security specialists should also work toward making their services easily consumable in the DevOps process to enable frictionless security.


    Vikram Kunchala, Deloitte’s Cyber Cloud leader and Principal, Deloitte & Touche LLP, and Amod Bavare, Deloitte’s Global Cloud Migration and Modernization leader and Principal, Deloitte Consulting LLP contributed to this article.

  • Low-Code Makes API Testing More Accessible

    Low-Code Makes API Testing More Accessible

    APIs are rising both in quantity and business value. But with that growth comes an increasing number of vulnerabilities, which could affect cloud service dependencies and internal APIs. Functionality and uptime could also suffer as cloud services evolve their APIs with new versions. Thus, API endpoint testing is critical to ensure a reliable back end. With growing interest across the organization to stabilize these integrations, how do we test APIs in a reproducible way that non-developers can grasp?

    Low-code platforms — tools that enable workflows with visual programming models — are opening doors for citizen developers to construct applications in a visual mode. Similarly, the low-code concept could aid API testing by providing an easier method to create API tests to verify functionality and uptime. This could arm quality assurance, DevOps and site reliability professionals with an easier means to test high-value integrations and their UI representations.

    Amid a growing headless movement, APIs are now powering many end-user experiences. However, during a developer drought, it may be challenging to find talent with integration know-how.

    I recently met with Dan Belcher from Mabl to discuss combining low-code and API testing. Here, we’ll uncover why it’s difficult for non-engineers to conduct API testing and consider what API testing must address to ensure today’s software meets tomorrow’s digital innovation demands.

    A Low-Code Approach to API Testing

    The software landscape has evolved rapidly in recent years. “Many forces have combined to create an incredible amount of change,” said Belcher, citing DevOps, CI/CD, the API economy and agile enterprises as examples. In this era, applications are becoming more dynamic, disrupting the way teams conduct end-to-end quality testing.

    API-based cloud services are part of this new frontier, becoming popular building blocks within modern applications. Yet, integrations require upkeep as cloud services evolve and version. Without continuous testing of API-based cloud services, organizations could easily suffer from breaking change and poor usability.

    Unfortunately, as it stands, typical QA teams aren’t well-equipped to handle ongoing regression testing for APIs. Instead, “developers, historically, have been the only ones that understood API testing,” explained Belcher. For years, API testing has been relegated to the realm of developers, who use tools like Postman to perform unit-level testing. But why is API testing so difficult for others?

    What Makes API Testing Difficult?

    Well, to start, non-engineers are typically more accustomed to UI-based testing. These environments use a structure designed for anyone to consume, making it easy to locate fields and confirm values, Belcher explained. When it comes to API testing, you often must handle massive chunks of JSON responses to match fields and surface issues. Testing API responses typically requires writing code, parsing JSON and writing it to variables, Belcher explained, which may be difficult for non-developers to implement.

    Or, difficulties could arise when testing asynchronous endpoints, Belcher added. Asynchronous APIs often involve background server processes that take a while to respond. This comes at a moment when event-driven architecture (EDA) is a growing trend. Take AsyncAPI, a standard API specification for EDA APIs, which recently joined the Linux Foundation. A recent report found AsyncAPI production usage tripled from 5% in 2019 to 19% in 2020. According to Belcher, testing such asynchronous services requires an infrastructure for continuous testing to anticipate these emerging scenarios.

    Four Crucial Areas For API Testing

    So what should API tests be focusing on? Belcher highlighted four areas that warrant close examination throughout the API testing process:

    • Functionality: This is the core functionality. Does the API do what it promises? Does it return the correct data?
    • Uptime: What is the API’s availability? Are all endpoints available in production?
    • Speed: This ensures cloud dependencies meet SLAs. What is the latency? Is there drift in API performance over time? Though API monitors like Api.expert help aggregate industry performances, they might not always reflect your specific customer-level realities. Belcher recommends not placing faith in supposed performance and instead, clocking your own.
    • End-to-End: Belcher stresses the role APIs now play across customer-facing presences. An end-to-end workflow should involve API endpoints, how they interact with one another, and the resulting visual representations. “Just like we have end-to-end testing for UIs, we should have end-to-end testing for APIs,” he said.

    API testing isn’t always combined with other parts of the user experience, but Belcher believes, going forward, end-to-end testing will be critical to ensure all workflows function in concert. For example, if a user profile is created within a browser, teams should verify the user profile has been created at an API level, as well.

    Low-Code API Testing and Shift Left

    APIs are beneficial to avoid reinventing the wheel. However, 100% operational uptime is impossible. Applications will inevitably encounter API problems, including outages, technical failures and functional misrepresentation. Developers also often come to rely upon production behaviors that may not be officially documented, an effect known as Hyrum’s Law. This can cause unstable integrations as APIs version over time.

    Thus, for these reasons and more, it’s a good practice to adopt continuous API testing. With the surging interest in site reliability engineering, spotting API errors early on will become an important aspect in reducing mean time to recovery (MTTR). Testing third-party APIs could also expose production latencies to inform cloud investments.

    “As the pace of change is going up, how do we deliver great quality to our customers?” Belcher asked. API testing is one answer to address this rapid change, and is growing in importance for the software delivery life cycle. It especially rings true for headless frontend experiences, where the API-driven backend isn’t transparent to QA testers.

    Low-code capabilities for API testing could help tear down silos inherent in the development process, enabling more people to participate in testing integrations. Belcher also stresses the importance of improving the usability of API testing for developers and non-developers alike. “We need to integrate with tools developers are already using for verification,” he added.

  • AlmaLinux Foundation Delivers on CentOS Promise

    AlmaLinux Foundation Delivers on CentOS Promise

    A nonprofit organization launched this week to oversee future development of AlmaLinux, a distribution of Linux based on code originally contributed to the open source CentOS project.

    At the same time, CloudLinux, which created AlmaLinux in response to a decision by Red Hat to pull financial support for CentOS, announced that a stable version of the operating system is now available. CentOS itself was based on the Red Hat Enterprise Linux (RHEL) distribution that is made available via a subscription.

    Jack Aboutboul, community manager of AlmaLinux, said AlmaLinux is the result of the $1 million that CloudLinux committed toward creating a distribution of Linux based on a CentOS project used by hosting providers, such as CloudLinux, to run RHEL-compatible applications at a lower cost. AlmaLinux OS is a binary compatible fork of RHEL 8, which the foundation pledged to update to maintain that compatibility.

    AlmaLinux is one of two distributions based on CentOS that have been created. The other, RockyLinux was created by Gregory Kurtzer, one of the original creators of a CentOS project. Red Hat, in the meantime, has moved to make RHEL subscriptions available for free to individual developers.

    Aboutboul said AlmaLinux is more mature than RockyLinux, because it is based on a Linux distribution that has been battle-tested by IT service providers. AlmaLinux also added a SecureBoot capability as well as support for VMware and the Amazon Web Services (AWS) public cloud, noted Aboutboul.

    The AlmaLinux Foundation also decided to publicly share errata about the ongoing development of the operating system, to make it easier for IT teams to troubleshoot issues that might arise in a production environment.

    It’s not clear yet how much support either AlmaLinux or RockyLinux have. However, at this juncture, forks are becoming fairly common across the open source community. Those disruptions, however, don’t seem to be dampening enthusiasm for open source software. A global survey of 1,250 IT leaders conducted by Red Hat finds nearly 80% of respondents expect to increase their use of emerging open source software technologies over the next two years, with the top three use cases being infrastructure modernization (64%), application development (54%) and digital transformation (53%).

    As Winston Churchill famously said, democracies are messy, and the open source community is no exception. Passions run high. At the same time, the various business models that spring up around open source projects often conflict; because of animosity, greed or differences of opinion, it is not uncommon for multiple forks of an open source project to emerge and evolve over time.

    Despite that issue, IT organizations remain committed to open source for two primary reasons. First, no one needs permission to download open source software to a laptop. That enables developers to more easily experiment with new technologies. Second, cost. Many IT organizations prefer to use free open source software, rather than paying to license commercial software. They may one day pay for support, but the number of open source software users still dwarfs the number willing to pay for support; especially since knowledge and expertise is freely and equally shared across a growing open source community.

    Given those benefits, any friction in the open source community itself is largely seen as an acceptable risk and just the potential cost of doing business.

  • How To Address DevSecOps Skills Shortages

    How To Address DevSecOps Skills Shortages

    “If it’s scarce, it drives the price up,” said McAfee director of systems engineering Sahba Idelkhani. And DevSecOps talent is scarce, and expensive.

    Restrictions on international travel are having an effect on immigration in some countries, notably Australia. But there’s practically nothing employers can do about that.

    But some aspects of the supposed skills shortage are, in part, self-imposed. One example is recruitment ads that specify “5+ years’ experience required” (or something similar) when that level of experience is only a desirable characteristic.

    Such practices don’t just restrict the field of candidates for that particular vacancy, they also make it hard to find entry-level positions. If candidates can’t get a foot in the door, how can they gain the experience that employers say they want?

    DevSecOps Change is Needed

    Idelkhani suggests that organizations need to change their hiring practices and put more effort into reskilling existing employees.

    In particular, if you’re looking for DevSecOps people, he suggests it’s better to teach developers about security than it is to bring security specialists (who are also in short supply) up to speed about development. The result is less rework, reduced risk and shorter development timelines.

    However, there is a risk that security specialists will tell developers what they did wrong. Proactively educating developers about security is a more productive approach.

    Cloud Academy is one of many sources for online security training courses and includes hands-on labs, sometimes involving the same tools that criminals use to breach security. Other tips Idelkhani offered include adopting a “build secure” mindset to reduce the security effort needed after systems have been created.

    A similar perspective can be applied to entry-level positions.

    Idelkhani has hired new graduates, even though it requires effort to guide and train them to the point of being productive.

    He has even adopted this approach with experienced people that have no background in security, including a former CTO and mobile developers and a pre-sales engineer.

    Revamp job descriptions so more people can apply, urges Idelkhani, as aptitude and skill are more important than specific experience, which can be taught.

    For example, instead of a large financial services organization recruiting someone with experience in incident response for cloud systems, it would probably be better to hire an incident responder and then sponsor their cloud training, he suggests.

    Furthermore, a diversity program increases the supply of candidates, quite apart from the other benefits it may bring.

    DevSecOps Training

    Employers sometimes suggest training is a waste of time and money because people simply take their new skills elsewhere in search of higher pay.

    But Idelkhani reports that his staff turnover has, in fact, fallen over the last three years, and no one has left after being trained.

    He puts this down to establishing an “emotional connection” between employee and employer, at least in part.

    However, organizations do have to accept the need to pay people what they are worth as they master new skills. But standard HR practices don’t suit skills development situations, he warns.

    People usually won’t move from their current role or company for a 10% to 20% pay raise, Idelkhani said, but would be more willing to do so for the 200% to 300% increase that comes from being considered an accomplished worker rather than a mere trainee.

    At McAfee, he is able to argue for ‘pay for value’ raises for his team; that task is generally harder at larger organizations, he said.

    “It needs a rethink [of] HR practices,” he added.

    Planning

    Substantial raises tend to require approval from higher up in the hierarchy, and that requires a clear justification for the increase. He suggests this should be done in terms of the capabilities that are being built, not based on the numbers alone.

    Managers should look at the skills they are going to need in order to deliver on the business’s strategic goals and plans, and decide how best they can be obtained. An expected DevSecOps vacancy might best be addressed by hiring a cloud developer and training them in the necessary security skills, or by retraining a person with potential who is already on the payroll.

    “It’s a long-term process,” though, that requires a lot of management effort, Idelkhani said. Using this method means identifying people’s interests and skills, aligning them with company goals, identifying the skills gaps and then developing those needed skills. This requires a training budget and getting one approved means having clear plans.

    But once you have shown the value of this approach, senior management is less likely to question it in the future.

  • Manufacturing Workers Eager to Digitally Upskill

    Manufacturing Workers Eager to Digitally Upskill

    Anyone who has worked in machining within the past 70 years knew that the future of machining was automation. In the 1940s, computer pioneer John T. Parsons and engineer Frank L. Stulen invented, via a contract with the U.S. Air Force, numerical control milling machines. The machines were designed to help the Air Force produce geometrically complex parts more economically and accurately.

    Those machines were the precursor to today’s computer numerical control (CNC) machining tools that use programming to automatically process some material, such as metal or wood, to specification. By the late 1980s, such machines were standard within tool and die, machine shops and manufacturing floors. Today, such digitization of manufacturing is accelerating.

    Workers, for the most part, embrace the change and would do more to meet the technical skills demands needed for their jobs – if only their employers supported them. That’s the primary finding from a survey, Digital Illiteracy in the Factory: Providing Workers with Low-Code Tools, commissioned by low-code platform provider Mendix.

    Interestingly, today, low-code development tools are finding a home in manufacturing. According to the survey, nearly 9 out of 10 said they want to learn low-code software development, while only 3% currently use low-code in their jobs. More than two-thirds (67%) say they want to create a software app that would solve work issues. According to this survey and a parallel survey conducted in Europe, U.S. workers are more willing to welcome and contribute to workplace digitalization than their counterparts in Germany (78% versus 61%) — a surprising result, given that German manufacturing workers enjoy a reputation as some of the most skilled in the world.

    “Incorporating digital applications is vital to the ongoing competitiveness of manufacturing in the U.S., and it is heartening to see such a large percentage of the manufacturing workforce ready to contribute to this effort,” Gardner Carrick, vice president of strategic initiatives at The Manufacturing Institute said in a statement. “Low-code applications provide our workforce with the tools to contribute to this digital transformation, and we should prioritize training in these skills.”

    The survey found that 87% of U.S. workers want to learn low-code development, and within those respondents, 88% of women who responded indicated being very interested in learning low-code, while 51% of men responded in kind. Perhaps not surprisingly, younger workers are more interested in learning low-code than those nearing retirement.

    That may be so, but U.S. manufacturing employers aren’t getting the memo. The survey found that U.S. manufacturers are giving their workers little help in developing their digital skills, and only 18% of workers are happy with their digital skills. “That only 18% are happy with their digital skills is just one sign that more training is required. At a time when the country’s manufacturing industry remains mired in a decades-long slump and when managers clamor for more useful software applications, news reports indicate that the nation’s workforce is ill-equipped to deal with writing code,” Mendix said in a statement.

    “The United States needs to move now to get their workers into the digital game,” said Derek Roos, Mendix CEO. “If the country wants ‘Made in the USA’ to mean something again, and if it wants to reduce unemployment and keep its economy vital and thriving, manufacturing and industry should provide low-code and other tools that help bridge the digital divide.”

    The survey was conducted from Jan. 29 through Feb. 11, among 250 full-time manufacturing workers in the U.S. and 250 within Germany. The survey’s objectives included learning workers’ attitudes and motivations, as well as obstacles that prevent them from acquiring low-code and other digital skills.