devopsy.kinsta.cloud

Category: DevOps Practice

3 Steps for Organizational Agility in the COVID-19 Era

While COVID-19 forced a fundamental shift in the way we work nearly overnight, many companies have been able to continue operations with minimal disruption, effectively transitioning to a remote workforce with speed and agility. These organizations that were further along in their digital transformation journeys before the start of the pandemic faced minimal disruption in the transition to remote work, allowing them to maintain operations during a very critical time.

As we enter the next chapter of work, the trend of “working from anywhere” will continue as the status quo. But how can companies completely overhaul their processes in a way that lets employees remain productive, while still giving them the ability to connect and collaborate? While there’s no one-size-fits-all approach to managing this shift, it’s clear that mastering both speed and agility will be key.

Achieving Agility

To help achieve both during this critical time, organizations must take three key steps: automating workflows, enabling citizen development to build low-code and no-code applications and investing in centers of excellence.

Automating Business Critical Digital Workflows

Think about all of the business-critical processes that span today’s organizations—communications that are routed around in email and tracked in spreadsheets—each of these processes are digital workflows that can be automated. In fact, today’s workers spend over 30% of their days squandered in redundant or administrative tasks that can easily be automated.

Automating these workflows is the catalyst that starts the change in making organizations more agile. When done right, automating and digitizing workflows will fundamentally improve business operations and boost speed and productivity. And by incorporating advanced automation and machine learning into workflows, companies can also improve decision-making speed and effectiveness—meaning employee time is spent on strategic tasks that create value for the company.

Digitizing internal business operations also means IT leaders can spend less time thinking about yesterday’s problems and more time focused on solving tomorrow’s challenges. The COVID-19 crisis is pushing IT leaders to prioritize productivity, shift resources to innovation and increase the speed at which companies operate—all of which require creating great experiences for workers. Automating workflow digitization can drive efficiency and productivity, as well as create an environment for better decision-making.

Fueling Innovation With Citizen Developers

The COVID-19 pandemic is pushing organizations to be more agile, creating more demand for citizen programming. With low-code and no-code platforms that generate code automatically with point-and-click or visual interfaces, non-technical employees are boosting productivity throughout the organization by creating applications that simplify employee workflows across departments.

While the idea of unlocking employee productivity with low-code/no-code tools is not new, the pandemic has illuminated the value of these tools with companies racing to come up with quick, digital solutions that help navigate remote work needs and remain agile. Before the pandemic, the Achilles’ heel of low-code/no-code projects was they lacked the right organizational setup to make them successful. But now IT leaders recognize the need to expedite the app development process and are embracing low-code efforts to digitally transform at a much faster rate.

In action, citizen development enables organizations to transform existing applications while creating new ones. It empowers end users to create customizations and configuration changes on their own, while letting developers and other IT leaders work on more complex applications and stay focused on keeping operations up and running.

After all, to remain agile during this rapidly evolving landscape, companies must be able to create, deploy and scale apps quickly to respond to employee and business needs. For example, the city of Los Angeles doubled down on low coding to build a portal that supports drive-through COVID-19 testing—in less than 48 hours. The app gives individuals the option to easily conduct drive-through testing so they don’t have to wait in line and risk exposure. After launching the app, 50,000+ tests were booked in a couple of weeks with 1.5 million visitors, and the app has scaled to serve 25 locations throughout the county.

Low-code applications such as this one are truly becoming the saving grace to help organizations and individuals as they continue to navigate new challenges and uncertainty, enabling an amazing “force multiplier” impact on businesses and ultimately allowing them to be more agile during this critical time.

Scaling Delivery With a Center of Excellence

The final step in achieving organizational agility is creating a center of excellence to help continue digitizing business workflows. A center of excellence brings together business and IT teams for strategy, business engagement and delivery and innovation to help organizations reach value, speed and agility much faster. A center of excellence also removes the organizational silos that can crop up in the transition to remote work by eliminating barriers and consolidating workflows.

Furthermore, a center of excellence can provide best practices and no-code tools to empower citizen developers while allowing developers themselves to tackle more complex issues for the business. After all, having a center of excellence means citizen developers can easily access the information required to build low-code apps and developers have a streamlined way to deliver software updates more rapidly to different lines of business.

When done right, the payoff is significant. Successful centers of excellence are able to realize—and accelerate—time to value across the enterprise, empowering teams to be more productive, innovative and agile in everything they do.

The Agility Bottom Line

The COVID-19 pandemic has given many businesses the rare opportunity to pressure test their digital transformation progress and overall organizational agility. Work is never returning to the way it once was, and businesses that are changing their operations to be more agile will adapt faster to this environment.

Delivering speed and agility at scale has never been more important, but getting there doesn’t happen overnight. By doubling down on automating workflows, driving innovation with citizen developers and scaling delivery with centers of excellence, organizations can take the fast path to speed and agility at scale.

September 2, 2020
How ‘Some-Code’ Platforms Perform a Balancing Act
Recently, there’s been a surge of interest in visual programming models, all with varying degrees of user-friendliness. These low-code platforms utilize drag-and-drop elements to help citizen developers stitch together applications, avoiding the complexities of hard-coding connections. Such platforms are crucial amid a developer drought and shine in their usability. But, how usable is too usable?

“A low-code platform should abstract complexity, yet always offer a way under the hood,” said Jesse Orshan of WayScript. In other words, the platform should never get in the way of advanced mechanics. To do so, “some-code” platforms balance usability and customizability.

I recently spoke with WayScript co-founders Jesse Orshan and Lane Eden to see how some-code combines traditional coding and low-code. As opposed to a 100% visual no-code experience, some-code focuses on operational automation while granting a peek under the hood. Read on to see how the notion of “some-code” may set itself apart from the larger visual programming movement.

Why Just ‘Some-Code’?

To understand some-code, consider the greater industry. As I recently covered, many factors are spurring a low-code revitalization. One is the need for rapid development for internal tools. Orshan acknowledged how “cumbersome, costly, and time-consuming it is to build and maintain internal tools.”

Many developers are fully capable of, for example, programming a native iOS app. Yet, turning that into a business application with a back-end running in the cloud with the proper databases, server arrangement, access management, and continuous deployment strategy is a whole different story.

“The idea is to blend coding and low-code,” Orshan said. “Scaffolding is the most difficult part of development.” Therefore, a some-code platform provides an operational toolset—a framework that enables developers to focus on their application logic.

Some-Code Leverages Event-Driven Architecture

Event-triggering has become common within modern programming. Triggering is necessary for automating tasks and workflows involving interconnected tools.

For example, say an internal tool for a sales department must automatically update a lead spreadsheet and send a Slack notice once an email is received from a prospective client. This process requires scripting a series of API queries involving Gmail, Salesforce and Slack APIs.

Though the logic seems simple from the outset, hooking together applications is not a trivial task. “Building a robust triggering system that can scale with your load is a very complicated thing to do,” said Eden. HTTP API integration is a unique skill that not all possess. “Thereʼs an understated art to building good APIs,” according to an Increment blog post.

The hurdles of API integration have already given rise to drag-and-drop workflow services such as IFTTT and Zapier. Some-code applications, too, could quickly enable developers to mix-and-match APIs in the programming language of their choice.

Other Some-Code Benefits

Internal tooling can be a big pain point. It’s “bespoke and custom to every business,” said Orshan. Utilizing drag-and-drop components alongside an IDE, some-code could lower the DevOps barrier for constructing enterprise-grade interconnected applications that require testing, auto-build and deployment automation. Here are some other some-code benefits:
- Abstracted type system: APIs are at the heart of many low code initiatives, enabling integrations with third-party tooling to enable event-based modeling. Some-code could enable developers to program logic without hardcoding integrations, offering a “unifying system abstracted type system,” noted Orshan.
- Flexibility: A unique prospect of some-code is that it could retain the programming language developers are accustomed to.
- Aids rapid development: Some code seeks to abstract things away, making it easier for developers to quickly solve core problems.
- Fill integration talent gap: A lack of specialized talent encompasses integration engineers and IT security disciplines. According to OutSystems, 45% of businesses adopt low-code to reduce dependency on hard-to-hire technical skills.
The Reality of ‘Citizen Development’

Problem-solvers come in all skill sets. Some are programming novices with little know-how, and UIs cater well to this group. However, only 8% of companies say they have business users utilizing a no-code platform without IT intervention, according to OutSystems’ 2019 State of Application Development report. Instead, the majority of low-code users are professional IT developers, at 69%.

“There is a place for visual elements, and there is a place for coding,” said Eden. “Sometimes, writing a function in Python is just way more efficient.”

Though low-code providers may trumpet the citizen development ideal, in reality, in 2019, only 20% cited enabling citizen developers as a key reason for adopting low-code. Perhaps this need will increase subsequent a fully remote economy and a developer talent shortage. Yet, as of now, experienced software developers are the ones using and benefiting from low-code tools.

Final Thoughts

The usability of no-code empowers business technologists to build basic workflows, yet lacks deep customization abilities. Yet, pure manual programming slows when you consider the many web APIs, differing standards and DevOps tooling integrations necessary to deploy modern enterprise-grade cloud applications.

The premise behind some-code is to help skilled developers stitch the operational scaffolding around their source code, helping integrate, validate, test and deploy software in a more streamlined approach. This style could be a better balance for advanced developer teams requiring an extra push.

“Our guiding philosophy is there should always be a way to get under the hood,” said Orshan. “The platform should never get in the way.”
September 2, 2020
Mendix Adds Git Repository Support to Low-Code Platform

Mendix today updated its low-code development platform to add support for Git repositories as part of an effort to make it easier to share and reuse code, as well as a visual conflict resolution capability that enables developers to easily see the differences between multiple versions of the same code.

Announced at its online Mendix World 2.0 conference, Mendix 9 also now provides access to a Data Hub based on a searchable Mendix Data Hub Catalog, an open, standards-based metadata repository designed to help developers discover data more easily.

The Data Hub Connect tool enables organizations to populate that Data Hub. The first connectors being made available are an open source oData connector and connectors to Siemens Teamcenter and SAP applications. Mendix is a subsidiary of Siemens. Mendix is also including an External Entities capability that presents data from remote systems as if they were local resources.

Sheryl Koenigsberg, global director of marketing at Mendix, said the Data Hub Catalog is designed to make it easier for developers to drag-and-drop data into applications as part of an effort to streamline processes.

Mendix today also unveiled a Workflow Editor, through which development teams can invoke workflow templates for both machine-executed and human-executed processes. These workflows can be accessed via a central task manager, and pre-configured dashboards to track and manage workflows are available.

In addition, Mendix has enhanced Mendix Assist, the artificial intelligence (AI) tool within the platform to include a bot specifically focused on performance issues. Mendix Performance Assist analyzes applications against known best practices to either suggest or automatically implement changes that ensure solutions don’t implement anti-patterns that deprecate application performance.

Mobile application development is being improved with support for Progressive Web Apps (PWAs). Developers now can deploy different types of mobile applications using, for example, a highly interactive React Native framework alongside a traditional browser-based framework within the same solution using the familiar Mendix modeling tools.

Finally, Mendix is making available augmented reality (AR) widgets to make it much easier to build the next generation of exciting business applications. Developers can now easily create a user interface, including 3D objects, images and marker detection.

Koenigsberg said Mendix is squarely focused on accelerating the development of critical digital business applications. In the wake of the COVID-19 pandemic many organizations are turning to low-code tools to allow professional and citizen developers to build applications faster. From a DevOps perspective, low-code tools such as Mendix 9 accelerate the velocity at which applications are being built and ultimately deployed using low-code tools that abstract away much of the complexity associated with building those applications.

Mendix 9 effectively represents an effort to extend the reach and scope of that layer of abstraction across a much broader swath of the application development life cycle, added Koenigsberg.

It’s too early to say to what degree the COVID-19 pandemic has driven organizations to embrace low-code tools more broadly. However, at a time when many DevOps teams are under pressure to deliver more code faster than ever, chances are good low-code platforms are building many of the digital business applications that organizations now need to survive and ultimately thrive.

September 1, 2020
DevOps: Driving Innovation With Old Habits

DevOps can help drive cost-efficiency, greater productivity and innovation

When software development and IT operations merge and work in a state of harmony, they create a flow that we call continuous product delivery. Ideal for project managers, this flow is the elixir to innovation and enables the agility needed to respond to changing market requirements. It also creates currents of speed, proactiveness and integration within enterprises. However, asynchronous code updates, inadequate IT infrastructure, siloed functioning and inefficient processes can hinder this flow.

In 2009, Patrick Debois and Andrew Clay Shafer devised a framework to break such barriers and coined it “DevOps.” Over the last decade, DevOps has garnered many followers and fans, including myself. Product managers worldwide rely on DevOps to enhance performance, accelerate time to market and innovate with agility. DevOps is more critical today than ever before—when nature mandates a new order of remote working, product managers must rely on DevOps to catalyze innovation and sustain continuous product deployments and updates.

Yet, not all enterprises that have adopted DevOps have unearthed innovation like that of Dyson, which created a new type of ventilator in a mere 10 days to help the UK government scale COVID-19 treatments. Nor have they been able to match the frontrunners of innovation such as Google and Amazon that can deploy code thousands of times per day, compared to low performers that deploy code only about four times per day. The obvious question on everyone’s mind is, “What are these heroic innovators doing differently with DevOps?”

Driving Success Through DevOps

While business executives are aware that implementing DevOps drives business innovation, most are not aware of the old habits that remain, causing unnecessary hiccups within the application cycle and business transformation. As the way forward, organizations must tweak their approach to DevOps to be able to reap more significant benefits of business innovation. They must:

Ensure speed does not outpace stability

Today’s digital-first world has swept through every enterprise. However, to keep up with the rapid dynamics of the digital tide, enterprises need to weed out monolithic architectures and manual processes to turbocharge software development and deployment. Automating the deployment process with the help of microservices and cloud can help enterprises gain speed in software deployments and swim the tide of customer experiences. Speaking from experience, this is a privilege that has allowed me to witness how DevOps practices have enabled enterprises to crunch deployment times from weeks and days to just a few minutes. Needless to say, innovation depends on speed: The faster an enterprise deploys a novel solution, the higher its chance to claim the prize of innovation.

A word of caution here: Many enterprises that have neglected quality and stability while accelerating speed drown in a vortex of defects often. When pushing out a product or an application 30 times faster than the traditional model, enterprises must consider its stability, too. Cloud infrastructure plays a vital role in helping enterprises achieve both stability and speed. On-demand self-service, networks that cater to multiple devices, high scalability and analytics are some of the primary advantages that enable enterprises to deploy faster without impacting the core.

Losing stability for the sake of speed can cause organizations to regress instead of leaping forward. In recent times, British Airways has been in the news for repeated issues in its IT infrastructure’s stability. It has had to cancel several flights and inconvenience passengers because software upgrades and incidents have caused its infrastructure to fail. Enterprises must consider these four metrics—lead time for changes, deployment frequency, time to restore service and change failure rate—to receive the value of their DevOps investment.

Make security equal to agility

The pandemic-driven remote working has seen the video communication solutions provider Zoom soar to 300 million active monthly users last month. The brand showed great agility in meeting the surge in demand but became vulnerable to cyberattacks—500,000 Zoom passwords were available for sale in the dark web’s crime forums last month. This is an excellent example of how security is usually an afterthought when compared to agility; not prioritizing security in the DevOps cycle can place teams and their organizations at significant risk, creating vulnerabilities and exposing organizations to bad actors.

In my experience, putting security checks in place early in the DevOps process can help enterprises shift left more effectively. As a first step, security and development teams need to communicate better through the continuous delivery flow. Security teams need to play more proactive roles in foreseeing risks in innovative solutions and routine software updates. Leaving security for the last will only force organizations to be reactive versus proactive.

Build collaboration, not silos

Gartner predicts that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. DevOps is a process that provides tools but it is also a philosophy that promotes collaboration among teams in software development. It catalyzes an ecosystem that encourages high collaboration and information-sharing. In a DevOps culture, failure is not shot down but leads to inquiry that drives solutions. Seamless information flow is the critical outcome of a DevOps-driven organization. Proper information flow is timely, answers questions and is understandable while needing the support of tools and technologies to drive success.

The General Motors Freemont Assembly line has been a great case study of how poor workforce culture can cause an enterprise to shut down. As one of the largest automobile factories in the United States, the manufacturer had to shut shop in 1982 due to rising losses attributed to an unruly workforce that was protected by a strong union. Within the next two years, the same factory was re-opened in collaboration with Toyota Motors, and it was called NUMMI.

NUMMI hired up to 85% of the old workforce of GM’s Freemont assembly. The difference was the Toyota culture–one that focused on learning and improvement and set a framework of how leadership interacted with and inspired teams. This change was fundamental in driving success for NUMMI, which reduced the time to manufacture a car to 20.8 hours in 1986—a drastic improvement over 43.1 hours in 1978.

At a time when we are witnessing unprecedented disruptions to supply chains, manufacturing and employment, enterprises need to deep dive into functioning to explore new opportunities for cost-efficiency, greater productivity and innovation. DevOps can help achieve these and build the foundations for continuous innovation. Investments in automation, cloud and culture will help enterprises realize the continuous flow of product delivery and innovation. The wave of innovation in the new normal will be propelled by the forces of time-tested practices and new next-generation approaches to enable enterprises to shift-left.

September 1, 2020
OverOps Taps Into Git Repos to Accelerate Code Reviews

OverOps this week announced it has added support for a git blame and automated source attach capability to its namesake platform for analyzing code that surfaces both root cause data for every error as well as the identity of the developer who owns that code.

Eric Mizell, vice president of solution engineering at OverOps, said once those developers are identified, the OverOps platform will automatically alert them about the errors in the code.

Every Git repository provides access to a git blame tracking command that identifies the authors of source code and the last time files were modified source file. The git blame and automated source attach capability extends that tracking command to accelerate the process of fixing errors that are discovered by the OverOps platform, which leverages machine learning algorithms and other forms of advanced analytics to perform static and dynamic analysis of code to detect errors in code before a DevOps team promotes code into a production environment.

Mizell said this latest capability accelerates the remediation process by automatically routing critical alerts to the developers responsible for the last commit.

Ultimately, DevOps teams should be able to spend less time in “war rooms” trying to resolve issues in a production environment because errors in code will have been addressed much earlier in the application development life cycle, he said.

Naturally, there’s a lot of sensitivity when it comes to analyzing code. It will be up to each IT organization to determine the level of visibility into the quality of the code being created by each developer. Most organizations will simply route alerts to individual developers to address without making each issue the topic of a team review. However, organizations may want to track what types of errors are being made consistently to better inform training requirements.

Regardless of approach, most experienced developers don’t want to spend a lot of time discovering the same issues multiple times when reviewing code someone else wrote. Tools that automate the discovery of those issues should enable development teams to focus their efforts on the more complex issues that inevitably arise when building modern applications.

In the wake of economic downturn brought on by the COVID-19 pandemic, there’s a lot more pressure on DevOps teams to become more efficient. In many cases, the velocity at which applications need to be built, tested and deployed in the wake of the economic downturn has increased as organizations invest more in digital business transformation.

Not every developer will enjoy have the code they wrote analyzed by a machine. However, most coders take pride in their work and would prefer to address in their own way any issue that may arise. The challenge is putting in place a code review process that results in better code being deployed faster without unnecessarily antagonizing the most valuable contributors to the digital success of any organization.

August 28, 2020
5 Myths About Software Development

2020 has broken many rules about software development. Some perceived trends, however, remain myths

Some trends come and go, some trends stick. I remember when Docker launched and it was barely mature enough to run unit tests, and now containers are a common way for modern orgs to deploy applications. We’ve seen the rise of microservices but also the return to the monolith. We’ve seen “observability” take off in popularity, while serverless remains a buzzword with limited (but fast-growing!) adoption. Machine learning and artificial intelligence are still click-worthy headlines, but how much actual ML is being used within our applications?

The True State of Software Development

Let’s look at five common myths about the current state of software development and evaluate why they’re not completely true:

Digital Transformation Initiatives Will Be Hindered by the Pandemic

We live in an online world where every business is already a software business (or rapidly becoming one). The impact of the pandemic further highlighted ISG’s research which stated that “2020 will still see the rapid scaling of digital initiatives across industries.” While some industries have been hit so hard that digital projects had no choice but to stop (e.g. the airline industry), in many circumstances this will be the catalyst to fully embrace digital transformation.

The Waterfall Method Still Works

Organizations that haven’t adopted more agile and iterative approaches to building software are operating at a significant disadvantage. I know there are many big companies that still believe in doing all of the strategic planning upfront (I know this because I talk to these companies), but the truth is that it leaves very little room for flexibility and improvement in real-time. In today’s world, the customers and the users are kings—it is no longer possible to build great products without their input. If you take anything away from this article, it’s that the waterfall methodology needs to be abandoned once and for all.

Everyone Loves Kubernetes

K8s is not a one-size-fits-all solution. The fact of the matter is that a large chunk of the enterprise still hasn’t fully embraced the cloud, let alone started containerizing their applications. So while we have to give credit where it’s due and acknowledge that K8s is the clear leader for orchestrating containers, we also have to acknowledge that the hype doesn’t quite match the adoption. It’s still a relatively young technology.

According to a report from Datadog last year, 45% of their customers that run containers use Kubernetes. That number is growing and is certainly impressive, but when you realize that only a chunk of their customers run containers in the first place and they are a modern monitoring solution where we’d expect to see a higher percentage than a random sampling, it’s clear that K8s is far from mainstream.

Everyone Is Doing Tracing

The rise of the digital age has put monitoring and observability in the forefront. As we rely more and more on online services for internal and external interactions, we better make sure they are working properly. But at the same time, regardless of industry headlines and conference talks focusing on tracing, the truth is that the industry at large has yet to adopt it.

For most organizations, there’s so much room for improvement in getting logging and metrics right, that there’s no need to opt for tracing (yet). After all, Google built most of its global platform relying on metrics. Unlike SREs, developers often find tracing alien and very cumbersome to deploy and wield. Instead, more and more companies are opting to empower their engineers to see what’s going on in remote environments through software understandability.

AI Will Solve Our IT Problems

We’ve been hearing about the promises of AI in IT for a long time now. One of the terms still actively promoted that I am very skeptical of is “AIOps.” What does that even mean, really? According to a recent report from OverOps, only a very small percentage of companies are even considering AIOps in their plans for the future.

That said, I do believe in making better, data-driven decisions. So the more data we can collect, contextualize and understand, the better. We see how this helps companies identify anomalies, alert on issues and even project out into the future. But none of this, really, is artificial intelligence.

Conclusion

There’s often a gap between hype and actual adoption. That’s the role of good marketing. And ultimately, hype helps drive adoption. But as technical practitioners, we need to stay rooted in reality in software development and beyond. So while I am convinced agile has proven to be the best way to build and deploy software, and that most organizations would benefit from letting go of old-fashioned waterfall processes; on the other end, I haven’t been fully convinced of the benefits of tracing and AIOps for most companies.

August 27, 2020
7 Forces Driving the Low-Code Movement
Why low-code? Why now? Here are some of the driving forces behind the burgeoning low-code movement

If you’re keeping an eye on the tech tooling landscape in 2020, you may have noticed the buzz around low-code. Countless low-code platforms are being funded and coming to the market. In fact, Forrester estimates that spending in the low-code category will exceed $20 billion in 2022.

But, arguably, visual programming models are nothing new; FileMaker is 35 years old, for crying out loud. WYSIWYG web editors are just as old. Providers including Outsystems and Appian have similarly supported visual code generators for decades. So, what’s with all the low-code hype? Why low-code, and why now?

Well, a new generation of low-code is emerging, spurred by some unique forces. I recently talked with Peter Nelson, vice president of Claris, an Apple subsidiary, and maintainer of FileMaker, on the current market factors driving advances in the visual programming space.

Low-Code, High Interest

Below, we brainstorm top forces stimulating the low-code trend, from a pressure to automate internal processes to a lack of developer talent and COVID–19. This list is not exhaustible, but hopefully offers a window into why the low-code movement is gathering steam.

Rapid Development

There is a pressing need to automate internal processes to maintain business agility.

Release velocity is quickening. Across the board, all companies face the need to automate their internal operations. Companies require workflow automation for form generation, data retrieval and database-driven functional apps, among other things.

The low-code industry had become a bit stale up until about five years ago when things started to change rapidly, Nelson said. “Recently, we’ve seen an explosion in the low-code no-code space.”

The emergence of next-gen low-code tooling runs parallel with the emphasis on rapid, continuous-release strategies. New UX layers that appeal to citizen developers empower more actors within an organization to embrace DevOps and enable quicker deployments.

Lack of Developer Talent

Businesses lack programmers with proper skill sets.

Code.org tracks 666,534 open computing jobs nationwide, yet only 71,226 computer science students graduated into the workforce last year. That means roughly 89% of open positions cannot be filled with the talent on hand.

IT faces a labor shortage. Drag-and-drop visual models enable problem solvers to quickly string together a workflow, avoiding tracking down the right IT department or PHP developer.

Nelson feels low-code can rectify the labor gap and act as more than just a temporary bandage. “You aren’t sacrificing long-term viability,” he said. “These aren’t temporary solutions that you need to grow out of.”

Cloud Integrations

Nuances of cloud integration workflows are challenging to maintain.

Think of all the cloud-based business utilities an average user consumes: Slack, DocuSign, Dropbox, Google Drive, Salesforce, etc. If a problem solver is automating a unique internal process, they’re likely creating an event-driven workflow between these apps. This means cloud integrations have become very important.

Web APIs do offer a standard communication format between cloud-based microservices. However, each connector has its nuances, and manually programming actions between them can be time-consuming. Not to mention the implications of supporting third-party dependencies such as authentication time-outs, versioning breaking change and uptime monitoring.

“Integration within no-code did not exist 10 years ago,” Nelson said. Fast forward to 2020, and ProgrammableWeb cites 23,000 public APIs. Low-code platforms have emerged as a glue between properties, solving the integration hurdles.

“You can build anything with the right legos,” he noted. Similarly, workflow automation requires stringing together the right components. “You don’t need to be a developer to do this.”

Hybrid Modes

Hybrid styles mean platform-agnostic development layers become more important.

Hybrid cloud, multi-cloud, multi-device. The world is accessing data from multiple sources and storing it in multiple places. Thus, business applications must be flexible in a platform-agnostic world.

A 2012 Cisco Systems study found 95% of organizations allow employee-owned devices. In 2016, Systonic found 87% of businesses rely on workers to access their smartphones. Now in 2020, a fully remote economy clocks in to work on their personal devices from home.

In this remote paradigm, web-based collaboration is an absolute necessity. Users should encounter the same digital experience regardless of the device used or where they’re located. However, even though users are remote, not all servers are remote.

“We’re slowly shifting toward cloud-native,” Nelson said. “But on-premise[s] still takes the lion share.” With concern looming over container-based cloud deployments, some high-security institutions could remain on-premises for some time.

Thus, business workflows require platform-agnostic capabilities that can talk with both on-premises and cloud-native servers. Low-code platforms are acting as an agnostic layer, catering to these hybrid modalities.

Artificial Intelligence

Low-code democratizes access to machine learning and AI.

“Today, you can learn how to stand up a database and interact with it from a YouTube video,” Nelson noted. “However, you can’t integrate AI, or scale it easily. The problem statement has changed.”

Low-code platforms abstract the back-end complexity of AI, enabling object recognition, language analysis, predictive analysis, risk scoring and other abilities. Some even can train new machine learning (ML) models.

Low-code enables companies to leverage powerful AI without much investment. For example, Outside Insight recently reported how low-code platforms are democratizing AI, while consulting firm Delloite assembled TrueVoice, a voice analytics platform built on a low-code platform using behavioral and emotional AI.

“If you can attach machine learning to the automation of business processes, I think you change multiple industries,” he said.

COVID–19

COVID–19 amplifies the pace of digital transformation.

Digital transformation has always been there. But now, you can’t ignore it. “COVID isn’t actually changing anything, it’s accelerating things,” said Nelson.

In the wake of COVID–19, companies may wholly depend on virtual business. For example, Take Allstate Insurance, which now receives 90% of claims using virtual tools, up from 11% in pre-COVID times. Low-code helps these brick-and-mortar companies quickly onboard to new technologies.

To supplement traditional business models, some industries will take digital transformation even further, becoming legitimate tech companies with externalized SaaS. For example, take speaker designer Dolby’s transition to online media transformation as a service.

Reusability

Next-gen low-code emphasizes reusability and externalization more than predecessors.

Anyone who follows the Bezos mandate of externalization from day one knows how valuable internal infrastructure can be. The tools you build should always be reusable by anyone on the network.

So, if you’re introducing an abstraction layer to build new software, you don’t want to shoot yourself in the foot. Low-code has a potential downside of inhibiting code ownership and stunting the ability to externalize valuable infrastructure.

Whereas older low-code platforms may have caused these concerns, Nelson views modern platforms as more malleable. He noted that with low-code widgets and data accessible via APIs, “internal processes, management work, by definition, are exposable.”

A Low-Code Revitalization

Low-code, no-code, some-code, workflow automation; call it what you will. Citizen developer platforms have taken on much interest (not to mention much funding) in recent years.

The need for increased accessibility to advanced workflow automation seems to underpin the low-code movement. But what else is powering recent transformations? To review:
- Rapid automation: Companies need to create frictionless business processes easily and rapidly, and change them on the fly.
- Developer scarcity: The workforce lacks qualified candidates. Low-code fills this gap in the market.
- Integrations hurdles: Internal apps involve many cloud integrations. Low-code can support these connections, enabling users to link event-driven workflows visually.
- Hybrid requirements: Users demand ubiquitous network access no matter device or cloud type. Low-code can act as an agnostic layer.
- Democratization of AI: AI empowers analytics and business intelligence projects, yet machine learning is difficult to implement. Low-code is abstracting this complexity.
- Reuse and externalize: Newer low-code platforms are better designed to expose data and services.
All this adds to a confluence of forces, giving rise to a low-code tidal wave. “This is the time where everything is coming together and is possible,” said Nelson.

What do you see as spurring our current generation of low-code?
August 27, 2020
Z is for Zowe – the Open Path to Mainframe DevOps
The energy and excitement in the IBM Z mainframe community during the two years since the announcement of Zowe have not been seen in a generation. By enabling mainframers to work like technologists who work on the cloud, mobile and distributed platforms, Zowe unlocks the power of DevOps for mainframers, ensuring the vitality of the platform for the long-term.

It accomplishes this by opening up the world of enterprise DevOps tools, both familiar and special-purpose ones, for mainframe applications, allowing users to easily create toolchains that include the mainframe. This freedom to leverage any enterprise DevOps tools across the entire deployment pipeline is achieved simply and elegantly.

The Zowe Backstory

The Zowe journey began when Broadcom, at the time CA Technologies, along with IBM and Rocket Software realized the challenges they were hearing from customers—IT isolation, need for increased delivery velocity and recruitment and retention problems—were bigger than any single vendor could solve on its own. The challenges of this scale required an ecosystem-wide response.

So the vendors came together with the Linux Foundation’s Open Mainframe Project to create the open source framework known as Zowe (as in David Bowie, for the uninitiated). The Zowe community operates transparently and welcomes contributions from all in the form of code, enhancement requests, educational content and shared experiences. A virtual meetup held earlier in the year attracted participants from 47 companies from across the mainframe ecosystem.

Traditionally, mainframe application development and operations have been separate from the rest of the IT organization due to specialized processes, roles and tools designed around the platform. While they have served the mainframe community extraordinarily well over the decades, the world outside has changed with demand for ever-shorter software delivery cycles resulting in the DevOps model.

In short, the tipping point has arrived and the time to normalize is now.

What Is Zowe?

Zowe is a modern interface to the mainframe that extends z/OS-based services and tooling to the greater IT landscape, including DevOps. As a framework, it consists of four main components:
- Zowe API Mediation Layer (APIML)
- Zowe Command Line Interface (CLI)
- Zowe Explorer (Visual Studio Code extension)
- Zowe App Framework (UI)
Broadcom is proud to have initially contributed the first three of these components. The first two were created as part of our CA Brightside offering, which won an award for the Most Innovative DevOps solution—yes, a mainframe offering won a DevOps innovation award!

These components provide a modern way of working that supports core DevOps practices such as empowering developers with shift-left testing responsibilities and DevOps engineers with robust automation options.

This article describes the framework’s ability to onboard the mainframe to enterprise DevOps, so developers, systems programmers and others who work with the mainframe can now do so the same way their peers do with other IT platforms (i.e., cloud, mobile, distributed). These shared experiences close the gap between mainframers and others while preserving the core advantages of the platform. Common tools fuel a common language that benefits all, especially when deploying hybrid applications (e.g., web front-end with mainframe back-end).

Through automation and script libraries, Zowe helps reduce the range of mainframe-specific knowledge necessary to be productive, enabling organizations to more easily recruit, onboard and retain the next generation of talent. By using modern DevOps tools and techniques combined with access to “big iron” applications, the next-generation now sees mainframe as an exciting career choice.

Recent milestones achieved by the Zowe community include the launch of the long-term support (LTS) release ensuring the stability and longevity of the framework and a Zowe Conformance program ensuring the interoperability of a growing ecosystem of conformant tools.

The framework drives mainframe DevOps in several ways:

Zowe API Mediation Layer – Discover and Securely Consume

As RESTful APIs become table stakes, the greater the challenge becomes, making those services easily discoverable and consumable in a secure way. The Zowe API Mediation Layer (APIML) addresses this need by exposing mainframe services, ranging from z/OS system level to database/transaction services to tool-based services, through a centralized gateway and catalog.

Conformance of these APIs with the Zowe LTS standard eliminates breaking changes while bringing additional value, including the usability and productivity benefits of single sign-on (SSO).

At Broadcom, we’ve leveraged Zowe to achieve conformance across our product portfolio and have a healthy pipeline of Zowe-conformant products soon to be announced. By spanning the traditional Dev and Ops domains, we’re facilitating true mainframe DevOps adoption—teams can combine their preferred mainframe-native tools with off-platform ones, including ones used by their peers working on other platforms, to optimize speed, quality and productivity.

Zowe CLI – Orchestrate and Automate

For DevOps Engineers and DevOps-savvy self-service developers, CLIs are a “go-to” tool. They use CLIs for a wide range of platforms including AWS and Azure, Git, Kubernetes and so on … why not mainframe? The use of CLIs paves the way for robust, script-based automation, which is a cornerstone of DevOps. The Zowe community already offers some basic scripts, free for anyone to use.

Using a CLI may be new for some, so community members often share tips and tricks to help these users navigate the productivity curve quickly.

Broadcom currently offers a dozen or so CLI extensions to mainframe-native tools, once again spanning the traditional Dev and Ops domains to improve productivity across roles and processes.

Zowe Explorer for VS Code – Visualize and Navigate

Visual Studio Code is exciting for any mainframers editing code, especially developers and sysprogs. While ISPF and Eclipse will remain viable options for the foreseeable future, the extraordinary success of the lightweight VS Code, which is backed by Microsoft, and the rapid emergence of browser-based editors/IDEs expand the range of options. With 11 million users around the globe, VS Code provides an experience users love and a marketplace of 20,000 extensions enabling users to personalize their UX and optimize their workflows.

Zowe Explorer, which streamlines interaction with mainframe data sets, USS files and jobs, is only one of the many VS Code extensions available in the VS Code marketplace for mainframe users (and a successful one with more than 12,000 downloads). Unlike Eclipse extensions, all of the mainframe extensions from Broadcom are free, and many are open-sourced.

In the Queue: SSO/MFA, SDK, Mobile App

The Zowe community has been working diligently on the implementation of SSO and multi-factor authentication (MFA), which eliminates the drudgery of constantly logging on to multiple systems.

Also, software development kits (SDKs) are in the works, the goal of which is to make Zowe services (and by extension, the mainframe) easier to use by providing reusable code for common mainframe operations in popular languages and runtime libraries. The beginnings of a Zowe Node.js SDK and Zowe Python SDK already exist.

Finally, a Zowe mobile app to help systems and operations support staff improve system availability is, like the SDK, being incubated by the community.

Decision Time – Zowe Open Path or Closed, Proprietary

Mainframe teams face a choice: Continue with a vendor-controlled model, in which vendors determine which tools you use and how you work or adopt the open path. While the prescriptive (aka opinionated) approach of the former may have been acceptable for a siloed mainframe, the open approach is the foundation of enterprise DevOps.

As an indication of the early success of the open path, we’ve been delighted to learn about many mainframe shops adopting Zowe on their own, with CI/CD integration and code analysis a common entry point.

For those with reservations about open source, consider the prevalence of Git, Visual Studio Code, Jenkins, SonarQube and so on in the DevOps landscape. Microsoft CEO Nadella recently stated, “We’re all-in on open source” and Zowe co-founder IBM recently acquired Red Hat—more shining examples that open source tools are a trusted part of the technology stack.

Change is never easy, which is why no-fee Design Thinking workshops are available to help adopters prioritize the DevOps use cases enabled by Zowe. Because so many see “open” as the least costly, least risky and fastest path to mainframe modernization, familiarity with Zowe is quickly becoming an industry standard. Ask your vendors if they’re joining the Zowe community and ecosystem.

With ongoing commitment from IBM, Rocket and Broadcom and the guidance and support of the Open Mainframe Project, the excitement around will Zowe continue so join the open mainframe movement!

To learn more about Zowe, visit Zowe.org and the community blog site.
August 26, 2020
Did Your Last DevOps Strategy Fail? Try Again

Let’s get one thing out of the way. DevOps isn’t a panacea—it isn’t magic, it isn’t a requirement for any enterprise and it won’t work for every team in every situation. Above all, it isn’t a yardstick by which an outsider can measure great operations, development or IT. And if anybody tries to tell you it is, feel free to say thanks and politely change the subject. You’re the one responsible for delivering the services your business depends on, and if the way you do it meets the needs of your business and the team is happy, stick with it.

But if you’ve tried adopting DevOps methodology, it’s likely because your business needs to substantially alter itself to meet specific goals. And DevOps has demonstrated the ability to help many organizations. Unfortunately, just as many seem to abandon DevOps initiatives and roll back, sometimes more frustrated than if they hadn’t tried it in the first place.

IT might be the team responsible for reliability, but this is a big challenge in an increasingly “fail fast” era. Many businesses are encouraging their departments to experiment, learn from their mistakes and keep trying until they deliver business-transforming innovation. But in IT, the high visibility of issues—even those initially within the accepted risks of a new project—seem to be treated differently. Even minor and expected teething pains can be judged as failures in hindsight. And many of us have seen instances in which attempting something new and encountering difficulty seems to make it five times harder to get off the ground on the next attempt.

DevOps is a prime example. As its culture and practices gained popularity, companies were quick to jump on the bandwagon—only to stumble in the execution or not deliver anticipated “transformation” or measurable ROI. It’s not uncommon for these companies and decision-makers to be left with a bad taste in their mouths. They may be reluctant to revisit DevOps and try again, even with the gained value of previous investments and lessons learned.

This isn’t much of a surprise: Humans don’t like to investigate public failures, and everything in IT is public, assessed in binary absolutes. It either works or it doesn’t, apps are up or down, and everyone in the company can see them. It’s also natural for businesses to switch their focus to the next potential success if personal political capital was part of a DevOps project. And as engineers, looking forward is in our DNA. We’ve built our careers around finding new and better ways to meet customers’ needs, solving novel challenges, and permanently squashing nagging issues to make room for new technology. The trick is to avoid considering DevOps a passing fad.

There’s significant value to be gleaned from any investment in DevOps—a better understanding of the human dynamics of your organization, at a minimum. If your team tried to implement some of the processes of DevOps or took the advanced step of adopting DevOps culture, don’t forget you did it for a reason. Go back and review what led you to consider DevOps in the first place. Chances are the business needs behind it haven’t changed and may have even expanded.

Outline those earlier reasons—they’re likely still there, even under novel circumstances such as shifting the team to work from home. Did your DevOps effort meet its original objectives, regardless of any rear-view assessment? Drill into the details where it didn’t. Was it due to culture, communication, risk reassessment or operations challenges? Did your team end up building something different than what you intended—a compromise not meeting the business’s needs? Take your time; you likely had many good people on the effort who are eager to share what they learned. A previous misstep could be due to a skills gap, software, management support or something as basic as infrastructure. The first step in taking another swing at DevOps is analyzing the previous attempt with data instead of opinions.

And there’s a good reason you’re likely planning to try again: The stakes are high. According to Forrester, 80% of revenue growth will depend on digital offerings and operations by 2022. Organizations will survive and grow depending on their ability to design and deliver technology services, respond to issues and meet growing user expectations. At the same time, considering the environment brought on by COVID-19, IT teams are seeking new ways to sustain operations and use the time to build a head start for when business picks up.

With this in mind, here are a few ways businesses can approach evaluating the execution of a first DevOps attempt to inform a successful second try.

First: Deputize an Investigator

You’ll need a deputy to help you conduct a forensic analysis and your QA team might be an unexpected place to find the right candidate. QA likes many of the outcomes of DevOps practices because they’re often suffering horror-show weekends at the hands of big-bang monolithic deployments at several companies. If you don’t find a detective there, empower someone who focuses on quality service and considers it a peer to availability, security and resiliency.

Your first job will be to demark the fault lines. Remember, the task isn’t to assign blame and a good admin-side manner is required to prevent this. Remind the team the mission is to avoid making the same mistakes, not to point fingers. Perhaps you originally had fantastic buy-in but everyone got caught up in the wrong details. Was the problem operational? You’ll need to know.

Second: Admit Mistakes and Ask for Feedback

Once you’ve conducted your analysis, you’re ready to take it to the next step: humanizing past technical actions. Consider what the previous attempt might have been like for different teams and people. Remember what it was like when you rode the help desk, when you were sitting in the data center on a weekend or when you were working as a dev lead under an impossible deadline. Chances are you’ll remember the common frustration was external direction not taking people into account. DevOps success is primarily about people. Align your DevOps reboot with the humans on your team and the processes will follow.

For instance, your company may have hired outside consultants to “rub a little DevOps on it,” and it’s possible they evangelized a lot of dogma. “Do exactly these things, this exact way, or you’ll fail at digital transformation,” they might have said. There may have even been FUD and frightening charts. Perhaps they said everything would be neatly wrapped up in six months and you’d achieve a high-performing, blended, and fully active nirvana within a year. “You could be the next Netflix!” You’ve probably heard this story several times by now, and if it’s happened to you, know you’re not alone.

But your approach this time will be different because it will be yours. You will have noted sharp edges needing to be filed down. The broader team will be integral to conversations from the get-go. Internal champions won’t be under the influence of ballyhoo, fancy decks or hard sells. Your team will have a list of concerns but also possibilities reflecting a shared interest in modernizing operations. One look at salaries for job postings with “DevOps” in the skill set has likely piqued more interest from your team than a year ago.

Open conversation has always been the hallmark of good forensic analysis. Express what you think went wrong the last time and encourage frankness. Acknowledge concerns—previous outcomes may have validated many of them. Your team will be looking for proof you’ve given thought to a process that might—in extreme circumstances—temporarily affect availability or lead to a security concern. Maintain an open invitation for everyone on the team to be a part of the conversation and hear their concerns. And wherever possible, lean toward person-to-person communication. You’re changing hearts and minds, not reviewing governance policy.

Third: Unite Your Team by Confronting Obstacles Together

Don’t perform a shotgun wedding between ops and dev. Administrators and developers are drawn to their technology foci for personal reasons and interests. One of the most cited reasons for unsuccessful DevOps plans is a directive to homogenize the team, followed by shock this didn’t work. Developers are attracted to and rewarded for innovation and building new things, while admins take pride in finding ways to migrate the mission-critical apps everyone forgets about onto new hosting platforms. They’re complementary, integrable engineers, but they’re not interchangeable cogs.

Contrary to popular opinion, telling developers they’re going to carry a pager for escalation doesn’t magically improve code quality and can slow innovation. They may even quit, even in this chaotic economy. And telling ops they need to learn code patterns, git merge and dev toolchains will be an unwelcome distraction not related to keeping their business running or meeting their personal review goals. They also may quit.

It might be helpful to share with your team the simple idea you embrace: Unfounded stories of friction between dev and ops aren’t about the teams. They’re usually someone else’s war story about the organization, technology or process obstacles dividing them. At its heart, DevOps is about clearing these obstacles, not replacing them with new ones.

By 2020, you’ve likely met someone from a team who had an opportunity to work based on tenets of DevOps, and they likely have no intention of going back. They’ll tell you they built or modified interaction models and evolved their deployment methodology organically. They streamlined the way code is built, improved testing at the bench level, staging and production. Even some companies needing to maintain specific waterfall processes for business or regulatory reasons may benefit if the transition is organic and incorporates their specific needs.

Fourth: Set Your Plan in Action

The last step—and this time, hopefully, the easiest—is to set your plan in motion, especially if you’re doing so at a smaller scale with better instrumentation than before. Ops teams and developers are people of action. We like to research, test and discover, but we’re happiest when our work sees production and we have a positive impact on the business. And often with initial forays into DevOps, stymied progress is what makes teams give up. By tracking ops and business metrics together, all the stakeholders will be able to share a sense of progress toward the overall goals, even when you break a few things along the way. Think of it as fail fast insurance.

For example, consider adding development metrics and business metrics alongside your traditional infrastructure data. Track rate of change, error rate over time, deployment events and PR requests to get a measure of release times. Share your application performance management (APM) metrics with the whole team—real-time user-to-app-code-to-infrastructure-to-resources data sparks insightful cross-team conversation. But you should also track metrics affected by ops quality, including visitor time on site, page abandons, service desk ticket rate and CSAT. You likely already have the data you need, but perhaps it’s siloed in different systems. If your dashboards combine data mirroring the mix of teams and infrastructure flying in formation, it’ll be much easier to identify issues, evolve your initial plan to suit your unique environment and improve overall DevOps collaboration.

And this time, you’ll be able to see code check-ins, unit tests, builds, pipeline progress, deployment to staging and prod, and follow-through on performance, issues and anomalies. If the team gets nervous trying something new, you’ll have actionable data, the production feedback loops developers crave and common charts everyone agrees on. It’ll be easier to know your DevOps effort is working and to keep pushing forward as you address unexpected challenges.

You’ll Know It When You See It

I made a joke in a talk once that DevOps is a lot like being in a relationship: You kind of fall into it. You learn about it, adopt some of its practices and enjoy the experience when it works. You don’t set out to “get in love” and likewise don’t set out to “get in DevOps.” Rather, you find yourself in a situation developed with experience over time, and you wake up one day and realize, “Hey, we’re a DevOps shop!” That’s why you can’t buy it in a box, and nobody else’s will be like yours. It’s not about the technology, it’s about the humans working together to manage it.

Maybe this is the best reason to give DevOps another shot. It didn’t spring from a consulting team as a framework to drive engagement or from a vendor with an appliance requiring admins to bend to arcane workflows. It came from people; from developers and administrators who fought the same operations challenges we all have and who wanted to share what they learned. And this is why, outside of a bit of time investment from your team, DevOps is free. It’s made to help, not to sell you anything.

August 25, 2020
DevOps and Compliance: A Recipe for Success
In today’s world, DevOps and compliance teams need to work together, not separately

Imagine this: You organized a dinner party weeks ago, promptly forgot about it and just realized tonight’s the night! You have two hours to whip up a gourmet meal for 10 friends. Instead of panicking, you get smart and enlist your kids to form an assembly line. One starts on sides, the other maps out dessert and you begin marinating steaks. All goes well—until the Brussel sprouts burn. Glancing at your watch, you sigh in relief—there’s just enough time to make another batch.

At that moment, your spouse walks in and assesses the situation. The meat is a tad underdone, the veggies could be crispier and the cake is lopsided. You can’t serve this meal! But now your guests are knocking. What do you do?

And more importantly, how does this scenario translate into a genuine business imperative?

The DevOps and Compliance Divide

In many ways, this dinner party dilemma exemplifies the clash between DevOps and compliance teams when it comes to priorities and perspectives.
- The DevOps PoV: Sure, we had a few hiccups along the way, but the end result smells and tastes amazing. Best of all, it’s hot, plated and ready on time for everyone to eat.
- The Compliance PoV: Yes, but the steak is 144°F. It needs to be 145°F to be considered safe. Boiling the veggies instead of steaming them depletes important vitamins from the meal. And both layers of the cake need to be exactly 2 inches tall.
Why the great divide? For starters, their reasons for being are at odds. The DevOps philosophy combines people, processes and tools to empower software developers and speed the delivery of high-quality applications, all while cutting costs. It’s also flexible, iterative and imperfect—experimentation is embraced. Imagine someone saying, “We’ll improve it in the next sprint.”

In contrast, compliance is all about order and uniformity; there aren’t any gray areas. Compliance teams are in place to make sure an organization’s security controls are implemented and monitored consistently. They adhere to a set of rules, mandated by a security framework, government body or customer contractual terms.

Yet in today’s world, these teams need to “cook” together—not separately. And that’s not easy.

Can’t Have One Without the Other

Compliance is a business imperative. Adhering to external regulations and the demands of your customers is of the utmost importance. If you think compliance is extraneous or expensive, try non-compliance. And it’s not just about avoiding millions (or even billions) of dollars in fines. It’s about maintaining trust. According to an IBM study, 53% of consumers say how well businesses protect their data from a cyberattack is “extremely important,” while 64% have opted not to work with a business due to concerns about whether they could keep their data secure. A company’s internal rules and controls are also implemented for good reasons, from instilling accountability to meeting customer requirements. They are not optional.

But neither is DevOps. It’s proven to boost competitive advantage by speeding up software delivery. In fact, high-performing IT teams that implement DevOps practices are more agile, deploying software and changes 46x more frequently with 440x faster lead times than their lower-performing peers. DevOps is also driving digital transformation by streamlining operations, cutting costs, accelerating agility and response, breaking down silos, challenging long-held mindsets, encouraging experimentation and cultivating collaboration, productivity and overall job satisfaction.

2 Cooks in the Kitchen: 5 Steps for Making it Work

So, how can two diametrically opposed “chefs” work in concert to create masterpieces? It’s a question that many CISOs and compliance officers are grappling with …

How do I do my job without standing in the way of DevOps?

To find the answer, they must ask another, broader question …

How do I get complete and continuous visibility of the risks impacting my business?

The only way to do this is to embed automated, transparent risk management into the entire DevOps process. Here’s how to get started:
- Open Up. Compliance and security teams need to be clear about what’s required of DevOps teams. Effective, ongoing communication and granular details will ensure DevOps teams understand their responsibilities and are empowered to do their part. This open line should flow both ways. DevOps teams should be transparent with compliance about their processes, ask lots of questions and understand how their actions will impact the business.
- Get Leadership On Board. Widespread change across people, processes and tools requires support from the top. Executive teams have to believe in it and back it. This will help your organization push through the tough times, convince the cynics and ensure sustained success.
- Make Training a Two-Way Street. Train security teams in DevOps processes—it’s easier to protect what you can understand. And involve security in developer training, from attack “post-mortems” to sharing source code repositories.
- Embed Security from the Start. Most organizations have multiple security scanning tools in place to identify vulnerabilities at different points in the DevOps process. But this often leads to alert overload, security gaps and more questions than answers. Consistent security scanning should be integrated across the software development life cycle and issues should be monitored in a consistent, centralized manner.
- Embrace Automation. This helps organizations understand where vulnerabilities repeat themselves and which ones present the most risk, empowering developers to address real issues quickly so they can get back to business.
Just like perfecting a signature dish, bringing DevOps, security and compliance into alignment takes time. It takes cooperation and patience. All significant organizational shifts do. But by following these steps, you will pave the way for DevSecOps—the holy grail of modern security—to strengthen customer trust and business endurance. Turns out, working together makes things safer and more enjoyable in both the culinary arts and application security.
August 25, 2020