devopsy.kinsta.cloud

Category: DevOps Culture

  • DevOps Jobs Remain in High Demand, Survey Shows

    DevOps Jobs Remain in High Demand, Survey Shows

    There’s good news for those interested in a career in DevOps or development — there are plenty of opportunities. And there’s even room for those with unconventional backgrounds, according to a newly released report from CodinGame.

    The CodinGame Developer Survey 2021, which is based on responses from 15,000 international developers and HR professionals, found that 64% of companies hope to hire up to 50 developers this year, while 14% of organizations hope to hire between 50 and 100 developers and nearly another 14% hope to hire more than 100 developers. Five percent of respondents plan to hire more than 500 developers.

    Developers know that opportunity abounds, and their confidence was reflected in the survey. When asked the question, “On a scale of 0 to 10, with 0 being extremely difficult and 10 being extremely easy, how easy do you think it is to change jobs as a developer?” developers surveyed gave an average answer of 7. “Despite the difficulties 2020 has thrown at the world, developers are just as confident this year as they were last year (in our 2020 survey, developers also gave an average score of 7 out of 10),” the report said.

    Where HR Anticipates Hiring Challenges

    When asked, HR professionals believe that they will have the biggest challenge filling DevOps, back-end developer and full-stack developer positions this year. Roughly 43% of respondents said they will struggle to hire DevOps professionals. When it came to front-end and full-stack developers, 41% said they will have challenges hiring both classes of developers. A full one-third of respondents said it would be a struggle to hire architects.

    According to the survey, tester, CTO, data or business analyst, applications developer, mobile developer and systems engineer are among the easiest positions to fill, with 15% or fewer respondents citing those positions as challenging to fill.

    Still, whether they are relatively easy to fill or not, almost all of these positions are heavily sought after. In order of demand, according to respondents:

    1. DevOps
    2. Back-end developers
    3. Full-stack developers
    4. Architect
    5. Software developer
    6. Data scientist/Machine learning specialist
    7. Front-end developer
    8. Tester
    9. CTO
    10. Data or business analyst
    11. Applications developer
    12. Mobile developer
    13. Systems engineer

    “These rankings confirm changes many of us have been experiencing,” said Aude Barral, co-founder and chief communications officer at CodinGame. “For instance, the shift away from on-site operations is reflected in the ranking of systems engineers and the prioritization of DevOps and other roles that support the virtualization of the enterprise. Also interesting is the status of C-level engineering talent. To me, it shows that hiring organizations are retaining current senior personnel and not making strategic changes until the market stabilizes,” Barral said.

    Not surprisingly, HR professionals plan to focus heavily on candidate experience, talent retention and employer branding. According to the survey, HR professionals will be working on new areas of team building, events aimed at recruiting and on developing new recruitment processes. These include 80% of HR professionals planning to recruit developers with non-academic backgrounds and 48% of companies offering developers the possibility to work 100% remotely.

    Average salaries for developers varied widely, according to the survey. While front-end developers, at $34,946, were paid the least, software architects, at $74,585, were paid the highest salaries.

    CodinGame Jobs

    “We’ve also seen more tech recruiters hiring developers who haven’t followed the traditional academic route,” Barral said. “A computer science degree is no longer a must-have if you want a career as a programmer. With the wealth of online and offline resources available to everyone, coders of all levels of technical competence can improve their programming skills, opening up job opportunities in the booming tech sector,” Barral said.

    That’s good news for developers without a traditional academic background trying to break into development. Those developers who are self-taught or who attended a bootcamp or other short-term training are welcome to apply at many organizations. The survey found that while 55% do recruit developers with non-academic backgrounds (though rarely), 24% said they do so regularly. Only 20% of organizations said that they don’t even consider recruiting developers with non-academic backgrounds.

  • App Testing Must Evolve Within the DevOps Pipeline

    App Testing Must Evolve Within the DevOps Pipeline

    As the practice of DevOps evolves, so do the supporting tasks; hopefully in such a way that they introduce increased efficiency and automation to accelerate development and deployment pipelines. However, one specific process still remains a speed bump on the road to DevOps acceleration: the process—or, more specifically, the chore—of testing.

    Naturally, testing is an undeniably important component of quality assurance. However, introducing efficiency into a process that dictates quality assurance can accelerate development and improve outcomes, especially when it comes to application testing. 

    “Application testing should never be done in a vacuum, or, worse, a silo,” said Sara Faatz director, developer relations at Progress Software. “The DevOps process can benefit from accelerating the testing process, introducing automation and embracing teamwork.” 

    Faatz makes some valid points; historically, application testing was treated as either a standalone or separate process, and often was performed by non-programmers following some type of script. “We discovered early on that creating synergy between testers and developers was an important concept for accelerating development, while fostering teamwork,” said Ramiro Millan, director, product development, Test Studio. “Addressing the trifecta of acceleration, automation and teamwork challenges actually requires adopting a different mindset when it comes to testing, especially when it comes to automation and communication.”

    However, solving those problems requires adopting different procedures, as well as deploying tools to streamline processes and introduce automation. That said, there are ancillary challenges that also have to be addressed. For example, there is often a disconnect between the cultures of QA teams and development teams. Here, QA teams need to overhaul their processes and introduce more agile practices. In other words, the time is now to identify new practices and methods that allow QA teams to be creative and innovative while helping to test the software created by DevOps.

    “Automation is becoming hyper-critical for testing. However, it is not just automation alone, but also the ability to run tests in the background and not hijack control of the console or the machine,” Millan said. “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.”  

    That makes a great deal of sense. In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.

    “Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times,” Faatz said. “The ultimate goal here is to bring forth faster delivery, less maintenance and more stability. I think stability is a big part of the equation. If we can automate those day-to-day, repetitive tasks, we garner that additional stability.”

    Although testing is a broad subject, many of the lessons offered can have a beneficial impact on the overall process. Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on. This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process.

    “The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation,” Millan said. “Automation brings about consistency, and consistency brings forth improved results.”

    The lessons learned indicate that testing must evolve to keep up with the DevOps model, and also suggest that DevOps is pushing QA teams to adopt new methods of testing and interaction. The only remaining question is how quickly QA can better integrate into DevOps, and eliminate the deployment speed bumps.  

  • Copado Acquires New Context to Drive DevSecOps Adoption

    Copado Acquires New Context to Drive DevSecOps Adoption

    Copado, a provider of a DevOps platform for building applications deployed on the Salesforce cloud platform, announced today it has acquired New Context as part of an effort to expand the scope of its portfolio into the realm of DevSecOps best practices.

    Andrew Leigh, chief marketing officer for Copado, said the acquisition brings Copado tools and professional services expertise that will be applied to help organizations build and deploy secure, custom applications on top of the same cloud platform they already use to access a range of software-as-a-service (SaaS) applications.

    The New Context Lean Security Intelligence Platform enables developers to achieve that goal by analyzing code and then surfacing recommendations for when developers should apply specific security controls, Leigh explained. Existing New Context customers include Blue Shield of California, GE, Kaiser Permanente and Royal Dutch Shell.

    Like most organizations that have embraced DevOps best practices, it’s still early days as far as adoption of DevSecOps are concerned. However, it’s already apparent that Copado is well-positioned to advance adoption of a complementary Lean Security Intelligence Platform, said Leigh. Copado, which claims to have more than 1,000 customers, recently raised an additional $96 million in funding to help fuel those efforts. The company also claims it recorded 120% growth in annual recurring revenue (ARR).

    In the wake of the COVID-19 pandemic, more organizations are employing SaaS applications to drive digital business transformation initiatives. Rather than building every application from the ground up, it is often simpler to extend, for example, a Salesforce customer relationship management (CRM) application.

    Once organizations reach a certain level of scale, they then start to apply DevOps best practices to those builds. These efforts, however, are often uneven. A recent survey, conducted on behalf of Copado, found that while 82% have increased or maintained the size of their Salesforce development teams, the change fail rate jumped from 23% last year to 33% in 2020 when compared to a similar survey conducted a year ago. The survey also notes time to recover increased from 110 hours in 2019 to nearly 196 hours in 2020.

    The next major challenge facing organizations that have embraced DevOps is, of course, DevSecOps. The challenge is that, since Salesforce environments are unique, applications are constructed using a set of objects and tables that are specific to that platform. As such, Salesforce environments generally require a DevOps platform designed from the ground up to work with objects and tables.

    Salesforce, in its most recent fourth quarter, reported revenue of $5.82 billion, up 20% year-over-year despite the lingering economic impact of the COVID-19 pandemic. As such, the number of custom applications being developed on top of Salesforce should steadily increase, especially as low-code tools become more widely adopted. It’s now only a matter of time before more organizations reach application development initiative critical mass that warrants investing in a DevOps platform to manage them.

  • IBM Deepens DevOps Insights on Mainframes

    IBM Deepens DevOps Insights on Mainframes

    IBM today extended its effort to enable IT organizations that have mainframes to embrace DevOps best practices by updating the analytics tools it provides.

    Tom McPherson, vice president for IBM Z Software, said a version 6.0 update to the suite of IBM application discovery and delivery intelligence (ADDI) for IBM Z tools surfaces more granular insights by leveraging a new version of Wazi Analyze that now analyzes code immediately after a change is made. That capability is critical, because most of the workloads running on a mainframe are highly tuned. Any issue that is likely to occur can usually be traced directly back to the latest software update made to the environment, McPherson said.

     

    Wazi Analyze also can now be deployed as a set of containers, which McPherson said means IT teams can opt to run the analytics application on a platform other than the mainframe.

    ADDI also has been updated to improve Assembler support by making it easier to analyze multi-level dynamic assembler macro calls. A set of application programming interfaces (APIs) for feeding that data back to a continuous integration/continuous delivery (CI/CD) pipeline has also been added.

    Finally, IBM revealed it signed a licensing agreement with ITP Software Systeme GmbH, Munich (ITP) to enhance application analytics capabilities. That capability will be added to a future release of DevOps for IBM Z Hybrid Cloud, which includes ADDI and IBM Wazi Developer, to enable organizations to determine how best to modernize legacy monolithic applications as they transition to a microservices-based, cloud-native computing environment.

    Naturally, not every monolithic application is going to be converted into a series of microservices. However, McPherson said, it’s clear there is a need for analytics tools that will enable IT teams to more easily determine which elements of an application are better suited to being reconfigured as microservices that could be deployed on, for example, a Red Hat OpenShift cluster.

    For the last several years, IBM has been encouraging IT organizations that have mainframes to embrace DevOps best practices as part of a larger effort to position mainframes as another type of distributed computing platform. The overall goal is to lower the total cost of mainframe ownership by reducing the need to rely on specialists to manage mainframe application environments. Each year, more of those specialists retire. IBM wants to make it more feasible for organizations to replace those specialists with IT generalists, like those that typically manage distributed computing environments. At the same time, management of distributed computing environments is becoming more automated, thanks to the rise of DevOps.

    Of course, mainframe processes have been highly automated for decades. IT teams managing mainframes may still rely primarily on waterfall-based processes to deploy applications, but the underling infrastructure is designed to scale up and down on demand as application workloads require. Convincing IT teams that, for decades, have employed the same processes to manage mainframes often requires a significant amount of cultural change.

    Regardless of motivation, however, the winds of DevOps change are now blowing through mainframe environments just as fiercely as they have through the rest of IT.

  • How the Pandemic Renewed Respect for the Agile Mindset

    How the Pandemic Renewed Respect for the Agile Mindset

    Agile methodologies were introduced to us around 10 years ago. In that time, we have seen technology advance at breakneck speed and faced many new challenges in the way we work; arguably, never more so than in 2020.

    However, despite the abundance of change we have experienced, the core values of Agile have stood the test of time. Yes, Agile has been agile, adapting to fit our individual needs. But its values and principles are so strong that they ring true for each and every organization touched by this way of working.

    It’s impossible not to mention 2020, and how Agile shifted and adapted to help us through this turbulent time. What did we notice? Well, much like the renewed gratification you feel for your automotive breakdown service when your car gives up the ghost for the first time in years, we noticed that the COVID-19 pandemic changed Agile in a different way: by providing renewed respect for the agile mindset.

    What is the Agile Mindset?

    When we talk about the agile mindset, we’re referring to the core values that combine to establish a set of attitudes held by those embracing agility. There are four of these core values: Make people awesome, deliver value continuously, make safety a prerequisite and experiment and learn rapidly.

    All four values are of equal importance, but they each have a unique impact on the mindset. For example, making safety a prerequisite means providing employees with the confidence to experiment, innovate and not fear mistakes or failure – these are all natural on our path to achieving new things.

    Additionally, delivering value frequently benefits both our customers and employees. It takes away the pressure of bouncing from one milestone to the next and adds value to a consistent level of delivery. Our customers are happy and grateful, seeing constant developments and improvements to what we provide them.

    The final two values (make people awesome and experiment and learn rapidly) are those that were particularly important during the change and adversity of 2020. Let’s dive into them.

    Making People Awesome!

    Agile methodology is massively focused on people: both employees and customers. When we work in an agile way, we want to enrich our people and give them the freedom to express themselves and show off their skills. This, in turn, helps the entire organization to deliver excellent service to our customers.

    With such a focus on people, the mandate for remote work brought about by the COVID-19 pandemic introduced an obstacle to agile ways of working. Our only human interaction with colleagues and customers was through a screen, which, let’s be honest, just isn’t the same as interacting in person.

    Therefore, employee engagement has become more important than ever. Virtual interactions make it harder to truly see how somebody is feeling about work – whether they are happy or unhappy, motivated or unmotivated. It’s important to check in with everybody regularly; ask them directly how they’re doing and encourage honest answers. Keep the Agile team spirit alive by making an effort to break the screen barrier during meetings.

    There are benefits of remote working for Agile, too. For example, it offers a fantastic work-life balance. When employees are less pressured by commuting or less exhausted by the constant energy of the office, they are happier. And happy employees make happy customers!

    So, the value of Agile’s ‘Make people awesome’ tenet became even more important and respected in 2020. We realized that we must optimize our employees so that they can bring their best selves to work, even during uncertain times.

    Experiment and Learn Rapidly

    This been an incredibly important value, hasn’t it? For lots of us, remote working was a brand-new experience. Perhaps we’d spend the odd day working from the sofa to let the boiler engineer in, but five days a week from home – unprecedented!

    Learning and innovating at speed has been key to being able to work effectively from home. We’ve been truly embracing this aspect of the Agile mindset. But how? Essential to agility is the ability to critically review how we operate. Almost half of businesses say they do this every quarter (43%) and 21% say they do this every six months.

    Regularly reviewing and analyzing how we work helps us to identify areas of improvement, areas that we could experiment with innovation, and gaps in our knowledge. Without this, we’d be walking through our working life with a blindfold on, and likely not be able to pivot in the face of change and adversity.

    A great example of the renewed respect given to the ‘experiment and learn rapidly’ value is the COVID-19 vaccine. It normally takes years to develop, test and roll out a vaccine, but we’ve seen this happen in just months.

    You wouldn’t be mocked for not knowing that the vaccine was being developed way before the pandemic of 2020. In fact, scientists began preparing for ‘Disease X’ over four years ago. They analyzed the response to the Ebola outbreak of 2014 and recognized a need to develop a vaccine that could be used quickly, for an infection that did not yet exist.

    Fast-forward to COVID-19, and while scientists still had lots of work to do to prepare a specific vaccine (designing; initiating the correct immune response; testing and more testing and roll out), their agility, started years ago, meant they had a strong foundation on which to build.

    This value has definitely received more recognition in recent months. This is great, because it’s going to be vital for the continued response to our changing world. We must continue to analyze our response to new ways of working and adapt based on what we find. Are you already experimenting and learning to be ready for the new normal?

    An Essential Mindset for Remote Teams

    The core values of agility have had a huge part to play in our adaptation to the changes we saw in 2020. And many of us have embodied this agile mindset without even realizing – we’re calling this ‘unconscious agility.’

    If you’ve tried something new in the face of remote working, made a conscious effort to deliver value continuously rather than in big chunks, checked in more regularly with your colleagues or relayed the message that mistakes and failure are a natural part of innovation, you’ve been working in an agile way. Even if your organization doesn’t consciously work agile, you can still embody this mindset.

    And it’s going to be key for the new normal – we should already be looking ahead to that. We didn’t have time to prepare for what came in 2020 – it was somewhat of a surprise. But we do have time to prepare for what comes next, and the Agile mindset is key for tackling this successfully.

  • Despite the Pandemic, DevOps Salaries Rose in 2020

    Despite the Pandemic, DevOps Salaries Rose in 2020

    Puppet today published the results of an annual global DevOps survey that found, despite the downturn in the global economy brought on by the COVID-19 pandemic, most DevOps professionals saw their salaries rise in 2020.

    However, for the first time since Puppet started collecting this data, DevOps professionals working in the life sciences, health care and pharmaceutical sectors, on average, made more than those working in the financial services sector. Not surprisingly, the report also found that DevOps professionals working in the U.S. made more than their global counterparts.

    Nearly two-thirds of respondents in the life sciences, health care and pharmaceutical sectors earn more than $100,000. That compares to 53% in the financial services sector and 45% of those working for technology companies.

    The survey was based on responses from 2,243 DevOps professionals, and noted that organizations with highly evolved DevOps practices pay better than those that are less evolved. Among respondents working at highly evolved companies, 80% earn $75,000 per year or more. That compares to 57% that earn as much at less evolved companies. Much of that discrepancy is attributable to DevOps managers that make much more at highly evolved companies compared to their counterparts at less-evolved companies, the report noted. Two‑thirds of practitioners make less than $100,000 per year, the survey found. In general, respondents working at companies with revenue over $1 billion had the highest percentage of those earning $150,000 to $250,000 (22%).

    The largest percentage increases in salaries among DevOps professionals occurred in Japan and the United Kingdom (UK). Salaries, on average, did not rise in Singapore, Germany, New Zealand and Australia. In the U.S., the demographic that saw the most growth was among DevOps professionals earning between $150,000 to $250,000, most of whom are managers. More than half of all DevOps managers in the U.S. fall within this salary range, the report noted.

    The Puppet report also noted that DevOps professionals working in dedicated engineering and application development tend to make more than those that are part of a larger IT team. A third of respondents in engineering or development report salaries over $125,000 per year, compared to 22% percent in IT and 15% percent in information security.

    The Puppet report also showed a divergence between what men and women earn as salary ranges increase. For both men and women earning up to $75,000 a year, salaries are similar. Between $100,000 and $125,000, women actually earn more. However, at $125,000, men (28%) earn more than women (17%). The survey, however, does not mention the experience levels of any respondents.

    It’s also not clear whether the higher salaries among DevOps professionals found in the life sciences, health care and pharmaceutical sectors represent a fundamental shift, or is an aberration based on the amount of COVID-19 research being conducted.

    Alanna Brown, a senior director of marketing for Puppet, said the one thing that COVID-19 has changed forever is that competition for DevOps expertise is now global. Organizations are no longer limiting themselves to hiring individuals within 50 miles of their office. In fact, DevOps professionals that have shown they can successfully work remotely will, in the months and years ahead, be in greater demand than those that have only worked in an office setting, Brown predicted. Organizations of all sizes are trying to reduce their commercial real estate expenses, Brown added.

    In the meantime, the most important thing for IT professionals is to stay relevant. Site reliability engineers (SREs) with certified programming skills will make more than a traditional IT administrator. It’s up to each IT professional to make sure they have the skills that are highest in demand at a time when many IT functions are being ruthless automated by increasing numbers of DevOps professionals.

  • IaC Frameworks: Vendor-Specific or Multi-Cloud?

    IaC Frameworks: Vendor-Specific or Multi-Cloud?

    Over the past few years, I have been watching the shift to infrastructure as code (IaC) frameworks closely. With the shift from monolithic to microservices, and with the shift from mostly virtual machines (VMs) to cloud-native architecture, applications are much more complicated, making it much more important to automate infrastructure to respond with speed.

    In that sense, I refer to IaC as “The third cloud revolution.” Looking at the history of cloud transformation, the shift from physical servers to virtual machines (led by VMware about 20 years ago) would be the first cloud revolution. The move from virtualized data centers to the public cloud (led by AWS about 10 years ago) would be the second cloud revolution. With the shift to public clouds, people were suddenly able to click buttons to provision new resources, including “hardware.”

    In the last few years however, we see fewer clicks and more code. Engineers write and maintain that IaC, and something executes that code. Engineers influence the infrastructure much more than they used to – that is the third cloud revolution. We mainly see four IaC frameworks that drove this revolution – Terraform and Pulumi (both multi-cloud), CloudFormation and ARM (vendor specific).

    I recently talked with Joe Duffy, CEO, Pulumi, Mark Russinovich, CTO, Azure and Anton Babenko, AWS community hero and Hashicorp ambassador, the head of Terraform at Microsoft, the head of Terraform at IBM Cloud and one of the founders at Gruntwork. After our brainstorming session, it’s clear we all agree that IaC will have a huge effect on cloud operations. In this blog, I’ll share my point of view regarding multi-vendor IaC versus single-vendor IaC frameworks; discuss how they compare to the differences between iOS and Android and which direction I believe will win the day.

    The big cloud vendors seem to go “all-in” and create full ecosystem, iOS-style, and they have everything working nicely with the relevant services and tools. AWS just released AWS Proton, which works with CloudFormation. They say that Terraform is on their roadmap, but time will tell. Microsoft seems to offer more solutions that are ARM-based, like Bicep. When I talk with executives at those companies, they strongly believe in the great value of this vendor lock-in/closed approach. They truly believe that this will help their customers in the best way possible. Perhaps they are right.

    On the other hand, when I talk with the community, I hear different opinions. DevOps engineers at Azure customers do not debate whether to choose Terraform or ARM. DevOps engineers at AWS customers do not debate whether to choose Cloudformation or Terraform. While this was the case three years ago, it is not, anymore. Now, the real debate is whether to choose Terraform or Pulumi. Engineers prefer a language that is multi-vendor, open-source, no vendor lock-in and that is compatible with other open source solutions built on top, like Open Policy Agent and Terragrunt, to help Terraform users. This is the Android-style approach – open platform.

    Moreover, I hear new phrases from the community that make me think the future is going in this direction. Erik Osterman at Cloud Posse started using the acronym  TACOS – Terraform Automation and Collaboration Software (see the video here). It takes time, but, going forward, developers and the community will hold the key to the future of IaC, not executives and large vendors.

    You can, of course, challenge this by replying that, “iOS is a great OS.” This is obviously true, but I think there is one big difference here as to why the Android approach is winning the IaC market. The answer lies with the end user; the Apple ecosystem is a solution for the end user and consumer, and IaC is about larger-scale infrastructure decisions. Like the shift from monolith to microservices, developers prefer small and isolated parts, not one big system. With Terraform and Pulumi, developers get more freedom. Maybe the company will move from AWS to GCP or Azure or vice versa. Maybe IT will need an Auth0 provider, as well, and will want to manage it the same way. Maybe the use of Open Policy Agent to govern deployments becomes the status quo. Developers need freedom, whereas consumers just need a great product.

    But the question has still not been answered: Terraform or Pulumi? It is still too early to tell, and, frankly, there is more than enough room in the IaC space for both. Maybe more open-source and multi-vendor frameworks will emerge and one that’s yet unknown will rule the day. Terraform provides a great ecosystem of providers, support and maintainers. Pulumi has started to provide all of those, together with its imperative approach, which seems to be a bit more appealing to developers.

  • Value Stream Management Consortium Makes Debut

    Value Stream Management Consortium Makes Debut

    A consortium dedicated to advancing the adoption of value stream management best practices is being launched today with backing from Digital.ai, HCL Software, Plutora, ServiceNow and Tasktop.

    The Value Stream Management Consortium (VSMC) will create an open community around which organizations that are seeking to expand DevOps workflows and processes across functions and organizations can more easily collaborate.

    VSMC chair Helen Beal said that while value stream management has been around as a concept for years, the number of organizations that have fully embraced the concept remains relatively small. The VSMC is dedicated to enabling organizations to orchestrate software development processes more flexibly, she said.

    VSMC Chair Helen Beal

    That goal has proven elusive, because it requires a level of collaboration between release managers, DevOps managers and product managers as well as IT and business leaders. Value stream management provides a framework for enabling organizations to embrace value stream management concepts as they become more adept at employing DevOps workflows to manage multiple application development initiatives simultaneously.

    Initially, Beal said, the VSMC will function as a central hub of information and education pertaining to value stream management. Ongoing research will track how organizations measure value. Eventually, the VSMC will provide certified training, Beal added.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring things such as the impact of missed software development deadlines on the business is growing steadily as organizations realize how dependent on software they have become.

    As organizations come to terms with this new reality, many also realize there is a much greater need to align software development with their core business processes. Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    Business leaders are especially anxious to understand how any software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of DevOps sophistication, but as software continues to eat the world it’s only a matter of time before value stream management becomes the table stakes organizations will need to survive and, hopefully, thrive.

  • Could No-Code Enable Everything Ops?

    Could No-Code Enable Everything Ops?

    It feels like DevOps principles are permeating every discipline, creating new buzzwords by the minute. DevSecOps. DatabaseOps. SalesOps. FinOps. MarketingOps. This “JargonOps” is clearly encouraged by marketing campaigns (and bloggers, wink, wink). Yet, the phrases do depict a real trend: all industries are getting an efficiency overhaul in the wake of increased automation.

    As I’ve covered before, low-code and no-code tools lower the barrier to entry to application development, enabling field experts to construct workflows as they see fit. For tech-savvy non-engineers, this could be a huge boon to transform copy-and-paste stopgaps into efficient workflow automations.

    I recently chatted with self-proclaimed “productivity geek” Sean Chou, CEO of Catalytic, to get his take on where this new era of automation is heading. From healthcare to logistics, advertising to supply chain management, every industry is likely to get an efficiency boost — and a lot of this digitization will be constructed using codeless environments.

    But first, how did we get here?

    From RPA to No-Code

    “The story of B2B software is largely about automation,” said Chou. If we consider classic examples of corporate applications, we see one common thread — B2B software has always sought to automate traditional office work.

    And so, it came to pass that computing and software devoured all these office tasks, from accounting to time-tracking, communications and many other areas. Though computer-based office work delivered huge efficiency boosts, these interfaces often introduced new hurdles; bad UI design, difficult navigation and a hundred open tabs, just to name a few.

    From there, robotic process automation (RPA) aimed to operationalize a growing number of tedious digital workflows across Excel spreadsheets, web apps and desktop apps. In Chou’s words, “RPA took the concepts of test automation software, and then pointed it toward production systems.”

    Though RPA’s process of recording screen interactions gathered much interest and attention (and funding), screen scraping is ultimately too fragile to be effective. It adds technical debt over legacy systems. It can be expensive to implement. Lastly, it’s not processes-centric and doesn’t implement reusable software-defined APIs.

    At that point, though, “Pandora’s box was open,” Chou said. Folks started to consider other ways to optimize, and reimagine how end users could automate workflows and stitch together interactions between disparate apps.

    Out of the ashes of RPA rose a new paradigm — low-code and no-code.

    No-Code Addresses Everything Ops

    With developer resources stretched thin and limited engineering talent available, it can be challenging to loop expert programmers into codifying traditionally non-IT processes.

    There’s not often enough developers to help with SalesOps, FinOps or any other Ops areas, explained Chou. “The only thing that can change the narrative is no-code technology that is effective.”

    Similar to how higher-level programming languages made low-level programming more accessible, Chou sees low-code and no-code unlocking accessibility for automation design by orders of magnitude.

    Four Examples of Everything Ops

    So, what are some examples of no-code use cases for automating operations? Chou outlined four specific categories that he believes will see much more citizen developer attention and action in the years to come:

    Customer Ops: “It’s really important to run customer operations as efficiently as possible,” Chou said. Especially in B2B interactions, people need to adopt various systems dictated by the customer. This can result in many ad-hoc implementations that beg for efficiency improvements.

    Financial Ops: Imagine the number of Excel spreadsheets that make up an account’s financial foundation. Consider the tedium of inputting data, generating reports or migrating calculations into other tools. There’s a ton to automate here. Providing no-code platforms to financial minds could have a “really transforming effect,” said Chou.

    People Ops: “The number of mini apps being developed for HR use cases is astounding,” Chou said. Think of all the digital tools HR must use: vacation requests, employee performance reviews, personnel databases – the list goes on. There’s a significant opportunity to clean up legacy applications within many HR departments to build a more coherent platform.

    SupplyChain Ops: Procurement and supply chain operations is another area where no-code could have an impact. Streamlining inter-company communications or engaging with potential customers are areas worthy of automation.

    No-Code? No Problem

    Across all these verticals, Chou notices three common patterns emerging.

    First, groups are using no-code to create standard operating procedures (SOP). SOPs could be used for onboarding or offboarding customers or ensuring compliance with a set of policies.

    Another everyday use is data pipelining — pulling information from many resources for analysis. A common use case is processing financial or customer data to generate a particular output. This is an area where embedded machine learning models could enrich the data.

    Lastly, a third common use case is creating workflow-powered surveys. These online forms could be used to measure employee engagement or to collect customer input. No-code workflows enable not only the collection of that data, but could allow for additional actions to be taken upon input.

    Implications and Governance

    Of course, giving non-developers the keys to the castle could have some downsides. Let’s face it — computer science is, well, a science. There’s a reason engineers are taught strict practices around version control, data governance and peer reviews. All of which must still be upheld when establishing a citizen development culture — especially at scale.

    When it comes to low-code and no-code, “governance is a huge thing,” said Chou. “Any company coming at this with no governance in mind can’t work beyond small teams.” Move beyond 10 or so citizen developers, and you’ll really need to establish some sort of shared framework or center of excellence.

    Making citizen development work in a large company requires IT visibility, data governance and a review process for new workflows, said Chou. IT will likely also want to verify that a new workflow doesn’t make permanent state changes. Otherwise, static apps that don’t touch core systems or affect persistent data stores are probably fine. “Having built-in governance is really key to making this successful,” Chou said.

    A Technology Leap

    No-code is giving more people the ability to produce unique workflows to increase their efficiency and do more with less. But with this movement comes worry. “With every technology leap, there’s always a wave of people concerned,” said Chou. Many naysayers are worried that automation will leave people out of work – “They’re coming for our office jobs!”

    Instead, Chou recommended we curb our expectations. Citizen developers are not going to build sophisticated iPhone apps any time soon. “If you think no-code is a panacea for all software, you’re coming at it all wrong,” he said. Instead, what they can actually can accomplish is far more practical.

    In reality, things are not as dire as some may make it seem. The new age of automation will likely open room for more jobs than it diminishes. “The net is always a plus,” said Chou.

  • Puppet Adds DevOps Consulting Practice

    Puppet Adds DevOps Consulting Practice

    Puppet has launched a DevOps consulting service that promises to help organizations implement best practices that will ultimately make their IT organizations more efficient.

    Nigel Kersten, field CTO, Puppet, said the Scaling DevOps Service is especially focused on improving workflows among organizations that have already started down the DevOps path.

    Most IT organizations that embrace DevOps eventually encounter bottlenecks that conspire to limit the rate at which they can build and deploy applications. Puppet will make available DevOps experts capable of assessing DevOps workflows as part of an effort to reduce operational friction, said Kersten.

    Those consultants can also identify integration opportunities that might further streamline workflows, in addition to providing an overall assessment of an organization’s DevOps maturity based on a model Puppet developed.

    Kersten said in many cases, enterprise IT organizations, especially, are trying to adapt DevOps principles that were originally created for small startup companies, with mixed success. Puppet consultants, using observations gleaned from their own engagements with customers that have embraced its tools for automating the management of IT, are often in a better position to identify ways to optimize DevOps workflows across larger IT organizations, Kersten said.

    It’s also easy for large enterprise IT organizations to misinterpret how one DevOps principle or another should actually be implemented, Kersten said.

    DevOps consulting, of course, has become a cottage industry within the IT services sector over the last decade. Now, almost every systems integrator has a DevOps practice. Most of those practices are focused on enabling organizations to embrace DevOps, versus helping organizations optimize workflows after they have already begun the transition, said Kersten.

    It’s not clear to what degree organizations that have not embraced Puppet’s automation framework will embrace consulting services based on a DevOps model created by observing Puppet’s customers. However, it’s apparent many IT organizations have inconsistently implemented DevOps practices across various departments. In many cases, bottlenecks that result in various departments within a larger IT organization are being addressed using a set of manual processes that have been created as a workaround to a specific problem.

    Of course, optimizing DevSecOps best processes is only going to become more challenging as emergent technologies such as containers, Kubernetes clusters and serverless computing frameworks are added to the IT mix. More challenging still, many organizations are now trying to shift responsibility for security further left as part of a DevSecOps workflow.

    Many IT teams are, naturally, resistant to paying for advice, while others routinely hire small armies of consultants in the hope that ideas and concepts that have worked well elsewhere can make their IT teams more efficient. Regardless of the approach pursued, IT leaders need to remember that DevOps is a continuous journey. Every time a new platform is added to an IT environment, a DevOps workflow will need to evolve. The real issue IT leaders need to come to terms with is how long it will take for their internal teams to adapt, whether it’s via the school of hard knocks or relying on external expertise that has handled most of the issues an internal IT team is likely to encounter.