devopsy.kinsta.cloud

Tag: continuous development

The Time for Automated Testing is Now

Skilled software testers continue to be in high demand, and it appears that trend won’t change any time soon. The current labor shortage and a looming recession is giving software development leaders good cause to think about how to attract and keep qualified personnel and, more importantly, enable them to work as efficiently as possible. Added to this scenario is a trend in the software development cycle toward shift left testing, which has put increased pressure on developers to take on testing responsibilities that often require taking on new perspectives and using new tools. Automated testing solves these problems by making it easier to learn how to build a consistent, reliable testing program in less time, requiring less maintenance.

Add to this the future promise of artificial intelligence or AI-augmented testing platforms and current machine learning (ML) capabilities, such as self-repairing of test scripts, and you have a platform that both levels the learning curve and accelerates efficiency. The sooner organizations can transition from manual to automated testing, the better they can withstand internal and external market fluctuations.

A Developer and a Tester Walk Into a Bar …

Traditional software testing is a manual process in which testers are employed to replicate users and are expected to bring that perspective to their work. As such, software testers have a very different mindset than software developers. Where developers are protective of their creative output, software testers are driven by a curiosity to probe the limitations of a system. It stands to reason that the qualities that make someone excel at either of these roles is, likewise, not the same. And yet, with the trend toward shift left testing and continuous integration/continuous development (CI/CD), the industry has blurred the distinction between coder and tester to the dismay of both sides.

Automated testing removes much of the monotonous work associated with repetitious test plans. It allows testers to focus on writing better scripts, extending the scope of their testing plans and scheduling more powerful load tests. From the organization’s perspective, once you have established a library of reusable test scripts, your testing program will be protected from future turbulence in the employment market, including recession and attrition.

Low-Code/No-Code

Regardless of the tool you use, code will be created if you are creating software — even test scripts. Ideally, however, a low-code/no-code tool can hide some of the complexity and promote best practices. Using a low-code/no-code tool can relieve a tester from creating test scripts from scratch by recording manual interactions and offering suggestions. In the case of shift left testing, a low-code tool can eliminate the need to learn entire testing frameworks while still enabling a developer to access code when desired. Automating testing also eliminates the human error inherent in repetitive manual tests. In short, test automation does not diminish the value of skilled software testers and developers; it increases it.

Placed in the hands of skilled testers, automated testing will only become more powerful, more effective and more critical to your development cycle. It elevates the skills of testers and makes them more productive, accurate and thorough. Test automation also makes for a smoother transition to shift left testing, allowing developers to spend less time testing their software and more time doing the creative work that makes them thrive. In a market where attracting and keeping top talent is only going to get more difficult, anything you can do to lighten the burden on your employees and make them more productive will be a big win for your business. So, the question is not whether you should transition from manual to automated testing but when.

January 9, 2023
Different Organizations, Different DevOps Outcomes
The main motivation behind inventing DevOps platform was to help close collaboration between developers and IT operations. Basically, DevOps emerged as a great platform to bring closer together developers and beneficiaries of the app development process. DevOps initiates a cross-disciplinary practice spanning across development and operations.

The ultimate benefit of the DevOps approach is removing the barrier between development and deployment of software applications in specific business processes. Regardless, not all businesses reap the benefits of DevOps platform.

Does DevOps really suit all businesses of different sizes and niches? What are the key considerations for utilizing DevOps platform? These are the questions we will try to answer through this article.

Do All Businesses Require DevOps?

The common and widespread consensus is that any software development company geared for innovation must embrace a DevOps environment. Any business that considers innovation and smooth deployment in the software development process—a key factor in their long-term growth strategy—should take advantage of the benefits of a DevOps platform. Whenever any service provider needs to adopt new strategies to keep pace with the evolution in the software space, DevOps will come as an irreplaceable platform choice.

Despite this consensus and widely accepted perception, there are different opinions in the market. Many industry experts believe that to reap the benefit of the platform you need to have a dedicated DevOps team in place. If you have a DevOps culture and in-house DevOps team in your company, you can gain a competitive advantage.

The Key Benefits of DevOps

The main benefit of DevOps is faster delivery of software with much-improved quality. There can be several other benefits depending on the industry.

While some companies refer to the huge reduction in downtime since they adopted DevOps culture, there are still many others who simply give credit to the platform because of its integrated approach that makes the process more agile and fast-paced.

For most companies, the domino effect of getting better software at a faster speed ends up delivering sustainable growth and revenue opportunities.

Here’s a look at the role of DevOps platform across three types of businesses: small companies and startups, midsize companies and large business houses.

Small Companies and Startups

In smaller companies and startups where resources and human capital remain under-supplied, the responsibilities ascribed to developers, engineers and deployment professionals often tend to get blurred or overlap. Because of the scarcity of human resource, developers and engineers are often assigned multiple responsibilities. Naturally, in such companies, it is common to see cross-functional teams ready to engage into various development projects with ease. This makes them ideal business organizations to embrace and grow with DevOps culture.

Midsize Companies

As the companies tend to grow bigger in size and resources, they have a bigger (and often unbreachable) divide between verticals such as operations and development. In such organizations, staff are less likely to be open to cross-functional responsibilities, as many have been in the same job doing the same tasks and feel settled. This brings in a stagnant organizational process, where strong departmental divide rules the business process outcome.

This stagnant work culture makes such companies less appropriate candidates to implement DevOps environment. For these companies to reap the benefits of a DevOps platform, mass organizational changes should be brought in the team structure. Building a separate cross-functional DevOps team to handle some focus projects can also be good practice for them.

Large Companies

Large companies enjoy the luxury and abundance of resources, and this makes them much better-placed compared to other organizations. Companies such as Amazon, Facebook, Google and Microsoft have the diversity, huge experience and robust abilities to bring together cross-functional specialists from development and operations to work on ambitious projects. These organizations are known for having product-oriented units, comprising specialists from both development and operations.

Apart from their cross-functional expertise, product-focused approach and abundance of resources to roll on new projects, large companies also can make a big difference to the teamwork and motivation through a highly unified vision and strategic long-term objectives shared by every member of each team. This is why large companies always stand as suitable candidates to embrace DevOps approach and environment for their projects.

Fixing the Right DevOps Strategy: 3 Things to Consider

Beyond the organizational differences and core strengths and weakness for embracing a cross-functional DevOps approach, we must look into the key aspects that make a right strategy for any organization to incorporate DevOps into their scheme of things. Question is, despite the shortcomings and lacking, how can you embrace DevOps environment and reap the benefits? Here we provide some clues:
- Making Change a Habit. Some strategists believe that any organizational change will face a lot of friction, causing substantial harm to the immediate business outcome. But there should be no reluctance to change for this. Rather, by bringing constant changes, people get used to the friction and pain and it becomes normal. This is one way to replace traditional IT mindset with DevOps.
- Starting Small with a Neat Team. Obviously, finding the appropriate and credible skilled employee for your DevOps projects is not always easy. This is why it is advisable to create small startups or units, in which sharing the common vision and embracing a cross-functional approach becomes the order of the day. On top of that, do your best to bring out the best from your team and hire some experienced ones with knowledge of DevOps.
- Continuous Development Mindset. We all know how the DevOps platform always focuses on continuous development approach. It is easier for the software developers to embrace such approach, but for operations staff, you have to slowly make them think of infrastructure as evolving and slowly building components. That’s something challenging but not impossible.
Conclusion

DevOps has emerged as the most promising development approach for modern software developers. Though for many development companies the friction emanating from strict role divides is becoming an obstacle, the positive push by DevOps for cross-functional approach looks indomitable.

— Atman Rathod
April 26, 2019
Assembling the Key Components of Continuous Delivery
As agile methodology was popularized at the start of last decade, engineering teams gained the opportunity to begin producing software in shorter cycles, while releasing it reliably at more frequent intervals.

This concept garnered greater attention in 2009, when Tim Fitz published his thoughts on continuous deployment. By the time Jez Humble authored his seminal book, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” in 2010, the approach started to get significant mindshare. In the book, Humble advanced the three building blocks of continuous delivery: configuration management, continuous integration and continuous testing.

Thereafter, Agile Operations—the practice of using end-to-end monitoring, fueled by analytics, to increase operational agility—appeared. This complemented continuous delivery, with the goal of increasing the quality and velocity of software delivery while minimizing overhead.

Since then, and particularly over the last six years as DevOps adoption has exploded, there’s been significant discussion (and confusion) over the opportunity to embrace “continuous everything” across the software development life cycle (SDLC) to deliver functionality continuously and optimize end-user experience.

Today, having spoken to hundreds of organizations employing agile and DevOps, it’s possible to expand on these concepts to better define the key components of continuous delivery.

In this blog, I’ll detail the precepts of “CD” that CA’s customers recognize as critical in reducing the time, risk and expense of software delivery by frequently releasing smaller batches of code with extensive visibility and traceability.

These building blocks of continuous delivery are:
- Continuous development & integration,
- Continuous testing. and
- Continuous release.
Continuous Development and Integration

When it comes to delivering quality apps faster, every second counts.

That’s why it’s important to automate the planning, development, unit testing and integration of code with different inter-dependent components, all while packaging it for quality assurance. We categorize these activities under continuous development and integration, as shown in Fig 1.

This all starts with sprint planning and modeling of requirements in agile management software. Unit tests can be created automatically, based on requirements and use case stories. These unit tests then can be executed automatically based on pre-defined criterion, using automatically generated synthetic data.

Fig 1: Continuous Development and Integration

Next, virtual service interfaces can be generated automatically by simulating unavailable systems across the SDLC, allowing developers, testers, integration and performance monitoring teams to work in parallel—driving faster delivery, along with higher quality and reliability.

The integrated code can be built and tested automatically against validation criterion, and upon passing, made available for continuous testing. This later phase, after code development and before QA, is also commonly referred to as continuous integration.

Continuous Testing

Continuous testing across app delivery not only enables enterprises to shift testing left, engaging it earlier in the SDLC, but it also helps them shift right, leveraging the same processes throughout staging and production.

After the unit tests are passed and integrated builds are made available for QA, functional and performance tests can be completed—before the build is made available for staging and production. Various activities during continuous testing are shown in Fig 2.

Before the functional and performance tests are performed, the build promotion criterion and configuration also need to be validated. Testers require provisioning of QA environments to deploy the build, along with virtual services and test data. Using test data management to create a subset of production data and mask sensitive information is another continuous testing requirement.

Fig 2: Continuous Testing

It’s also important to engage application performance monitoring in the QA environment before running automated tests, providing feedback about any problems back to developers.

After the automated tests are executed and promotion criterion are met, the build is ready for deployment in staging or production environments.

Continuous Release

Continuous release matches release velocity to development velocity through controlled and scalable deployments.

The goal of continuous release (sometimes referred to as continuous deployment) is to continually and automatically deploy the build into production; similar activities also can be performed in a staging environment.

As shown in Fig 3, build configuration needs to be validated, with the production environment configuration updated before being sent to production. As with application code, configuration is also maintained in the version control system and can be automated for deployment.

Fig 3: Continuous Release

After the build is deployed into production, application monitoring should be initiated to track performance and customer experience. Feedback from the production environment can be passed back to developers to guide enhancements or sprint backlogs.

This blog aims to outline core CD activities, and in subsequent articles I’ll provide additional details on entry and exit criterion, as well as metrics useful in tracking continuous development & integration, continuous testing and continuous release.

In the meantime, check out, “DevOps for Digital Leaders: Reignite Business with a Modern DevOps-Enabled Software Factory,” a new book authored by my colleagues Aruna Ravichandran, Kieran Taylor and Pete Waterhouse.

Based on learnings gained from numerous customers who have already embraced CD and DevOps, it highlights key practices for starting this journey, related ROI metrics and other useful tips.

— Anand Akela
December 15, 2016
A Ferrari and DevOps: More Similar Than You Might Think

In a world where customers aren’t short of options, all businesses are characterized by the need to achieve customer delight. From a technological standpoint, a large part of that hinges on fast-tracking the release of high-quality software. A release every quarter is being replaced by a release every week and sometimes even sooner. Expectations have skyrocketed while the timelines have shrunk even more. It is now imperative for all the different components to sync together effectively to create a competitive advantage for the business that can be sustained over a period of time.

All the water-cooler talk around DevOps notwithstanding, it’s true identity still varies vastly based on the passionate opinions of participants with varied schools of thoughts. It also bears mentioning that while all of their varied opinions carry a sliver of truth, they also are significantly separated from the heart of the matter.

To better understand the situation, let’s jump into a story: Once upon a time there was a monk who owned a Ferrari and had no interest in selling it. Every morning when the monk left to teach his mindfulness class, there were three blind men who were captivated by the sound of its engine and the smell of burning rubber. And, yet, they couldn’t see the very object that had captured their fancy. So, one fine day they decided to touch the Ferrari and exchange notes.

The first man touched the broad wheels of the Ferrari and exclaimed that it was a large contraption made of soft rubber. The second man ran his hands across the exquisite curves of the car and said it was like an ancient Greek statue, while the third one placed his hand on the Ferrari’s windows and concluded it was a moving glass palace on wheels. Although each was right in his own way, none came even remotely close to capturing the essence of a Ferrari.

By now, you don’t need a monk to tell you that the story of DevOps is very similar. For some, DevOps is all about inculcating the right culture so that different groups can work together seamlessly to achieve a unified goal. For others, it is about establishing the right processes and practices that are in sync with an organization’s business goals. And for those with an axe to grind or proprietary tools to sell, DevOps is all about achieving automated nirvana.

However, the ground reality is that software development teams constantly are facing increased pressure from business leaders to deliver faster than ever before. The business leaders, in turn, are under the hammer of market forces that require them to accelerate or die. The need of the hour is to deliver high-quality software at the rate of knots, while untangling any that might impede the time to market.

Continuous Everything

We at Happiest Minds believe the simple approach to DevOps is one that is “continuous” and at its core has the agile mantra of “people over processes and processes over tools.” The idea of continuously evolving and adapting to changing requirements and demands has been captured in what we call the 7Cs of DevOps:

The main objective is to ensure agile delivery by embracing continuous planning, continuous development, continuous Integration, continuous deployments, continuous testing, continuous monitoring and continuous feedback.

However, the cultural component of DevOps cannot be overemphasized. A large part of the success or failure of any DevOps engagement depends upon how willingly it is embraced within an organization and the kind of executive sponsorship it receives from the powers that be. The three widely recognized cultural models that most organizations come under are pathological, bureaucratic and generative. Needless to say, organizations that are riddled with a pathological or bureaucratic culture are likely to experience the least amount of success with DevOps because such organizations tend to cover up failures and eventually pin them on the most susceptible scapegoats.

The breeding ground that DevOps needs to flourish is a generative culture where information is shared freely and openly, the leadership encourages employees to learn and experiment with new ideas and failure isn’t looked at as the end of the world but rather an opportunity to learn and grow.

Eventually, organizations will have to embrace DevOps as an integral part of their strategy and not just as a liberal, forward-thinking experiment that scores them some brownie points. But it will take some doing, both at the grass roots and in the board rooms. One has to remember that a lot of people are easily attracted to a Ferrari, but perhaps not to the grind that goes into owning one.

The idea of having a successful DevOps program is much the same—it’s not just about engaging the best vendor or choosing the right tools or paying lip service to creating the right culture; ultimately, it requires overcoming organizational inertia, resistance to change and making a long-term commitment to the philosophy that takes a larger view of how DevOps can help businesses stay one step ahead.

About the Author / Arsalaan Kashif

Arsalaan Kashif is associate director of Marketing, Product Engineering Services at Happiest Minds Technologies and has a keen interest in all emerging areas of technology and innovation. Having worked with Unisys, Oracle and HCL Technologies for over a decade, he has experience with taking to market products and services across areas as diverse as application services, cloud computing, DevOps and big data analytics to name a few. Outside of work, Arsalaan enjoys watching noir films and reading John Irving classics. Connect with him on LinkedIn.

November 28, 2016
Pokémon Go Shows DevOps Changes Human Behavior

Everywhere you go lately, you can see people acting strangely. They’re walking streets they never walked before. They’re waving their smartphones around in odd ways. And they’re high-fiving each other for no apparent reason.

And they’re doing it because of DevOps.

Of course, not everyone immediately thinks about Pokémon Go as an artifact of DevOps—but that’s what it is. It is code written, continuously modified and continuously promoted to production based on changes in workload performance and user feedback, implicit and explicit. It is also the most downloaded app on iTunes ever.

More importantly, Pokémon Go is visibly changing human behavior. That’s something worth considering as organizations seek to survive and thrive in the application economy.

Doing Things Differently vs. Doing Different Things

Most development is done so that customers or employees can do things differently. There are lots of apps that make shopping easier or deliver better analytic insight for decision-making. And those apps certainly provide business value by removing obstacles to revenue or by helping companies optimize allocation of resources.

But Pokémon Go doesn’t merely allow people to do something differently. It drives them to do something entirely different—location-based and augmented reality gaming.

Pokémon Go isn’t the first or only app that changes human behavior. Uber and Zipcar changes how we get from place to place. Square changes how we do retail. Pokémon Go, however, is an especially dramatic manifestation of how apps change behaviors. People are doing something they’ve never done before because of some software—and because that software “went viral.”

That’s an important concept to bear in mind as organizations seek to optimize the effectiveness with which they leverage technology in their businesses. Are you just trying to write apps that help your users do something a little better? Or can your apps enable and inspire entirely new behaviors that people will find worth embracing—and therefore will also promote across their social networks?

The Role of DevOps

DevOps is central to this endeavor in several ways. First, when you’re doing something new, you by definition don’t know what you’re doing. So you have to keep going through cycles of testing to get things right. If those cycles are slow and you don’t take the time to test all possible use cases—such as geolocations, devices, operating systems, hardware, diverse transaction, etc.—because you have trouble putting the right test data together or it takes too long to provision the necessary environments, you will either be late to market or release something nobody likes.

To avoid these types of pitfalls, you need a streamlined and automated end-to-end DevOps pipeline that optimizes your delivery value chain and eliminates constraints and dependencies across the software development life cycle. Implementing this type of continuous delivery tool chain will allow your DevOps teams to continually improve the quality of your applications in a shorter time frame.

Second, even once you get things right, they won’t stay right for long. The folks at Niantic were most certainly surprised by just how viral their app went, so they had to scramble to overcome performance issues in the field. They also are dealing with some negative feedback from true Pokémon aficionados who are not so smitten with how gameplay diverges from their long-beloved Nintendo brand.

Niantic’s ability to keep riding its initial viral download success will be closely tied to its ability to address these issues. And that’s also best done with an automated DevOps process—along with Agile disciplines—that allow the company to keep refining both its code and the way that code runs in production and ensuring the performance of the IT infrastructure that supports the user experience of the app.

Luring the Wild ‘Customon’

Perhaps the most powerful lesson from Pokémon Go isn’t for developers. It’s for business leaders. Unfortunately, many non-IT executives still view DevOps and related investments in digital capability as an operational issue for technologists—rather than as an existential issue for the business itself.

But it is decidedly the latter. Pokémon Go isn’t just about having a good idea for a game—any more than Dollar Shave Club, which Unilever just bought for $1 billion—it’s about having a good idea for a company. You have to be able to execute. And in the application economy, you can’t have execution with speed and quality without DevOps.

So if you’re still struggling to get upper management to invest in funding your DevOps initiative, maybe it’s time to put away the PowerPoints and pull out the Pokémon instead. We’ve rarely had a more dramatic example of how applications can impact human behavior—and how the ability to get code into production quickly and successfully can impact your business.

About the Author / Aruna Ravichandran

Aruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across the Application Performance Management, Infrastructure Management and Continuous Delivery product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a Bachelor of Science degree in computer science from Bangalore Institute of Technology.

August 5, 2016
Learning in the Continuous Customer Economy
We live in a continuous customer economy. Buyers in the 21st century are continuously discovering, adopting and discarding products and services online, telling us—very loudly and unequivocally—that value isn’t perceived in the actual product itself, but rather in our ability to change a product continuously. So, it’s now about the options to change the product, not the product options themselves.

This utter lack and loss of brand loyalty puts companies at an insane disadvantage. They’re living with a “see you later” digital mindset, where it’s easy for consumers to say goodbye to something they know online for an opportunity with the newest, next best thing.

Take this to the next logical business level and you see why continuous transformation of your organization is so critical. If you can’t continuously transform the way you deploy your people, processes, skills and resources, so everything is aligned with the consumer’s “see you later” mindset, there’s no way you can keep up with customers, who are continuously discovering, adopting and discarding products at what seems like warp speed.

Obviously, this means learning and acquiring new knowledge fast.

The same old knowledge, the knowledge of the past, just doesn’t work in the world of now. But, more profoundly, to continuously transform your organization and meet customers where they are today, you need to learn how to learn.

Yes, sure, you have to learn from customers and gain an understanding of what they want and need. But every organization does that today. It’s no longer enough to simply grasp that insight and intelligence and run with it. No, you have to continuously improve how you learn from customers in this fluid and fast-changing world.

Why? Because, at the end of the day, continuously improving how you learn is the only way to continuously transform your organization. And, thus, continuously improving how you learn is the only competitive advantage you have.

Continuously Improving What—and How—You Ship

Assume, for a moment, that you’re shipping an update of 1,000 lines of software code each week.

That’s great.

You’re likely using continuous delivery.

But if you can’t continuously improve how you’re learning from customers and continuously improve the teams inside your organization, you can’t ship continuously improved products. So, you need to improve what you ship and how you ship to continuously transform your organization.

Here’s an example of how this works.

Let’s say your software development team senses the customer wants an improved red button that’s square instead of round. Okay, development of an improved red button proceeds and is completed in one week. But, at the same time, the team creates an automated test for the red button as well as clear metrics for determining if the red button is actually the problem. Remember, the idea that the button needed changing is a hypothesis until it has been tested with customers.

So, in addition to shipping the new square button to some customers, the team keeps some subset of customers using the round button. The customer test is then simply whether the click rate of the square and round button differs.

Let’s imagine that the processes are not currently in place to enable the development team to receive these metrics, as many teams are kept in splendid isolation from the results of their work. Then the establishment of this relationship, perhaps with the web operations team, is also going to be required.

This is as much a requirement of successful deployment of these features as the features themselves. The focus on the delivery of function, as well as developing internal capability, is a core principle of continuous transformation.

The Two-Product Principle

This is the Two-Product Principle.

Think of the product we ship to the customer as “Product 1.”

Meanwhile, the internal capabilities we wish to develop—our view of what we need to improve while we build—is “Product 2.”

To recap two critical points:
- You always ship twice—you ship an improved product externally and you ship improved capabilities internally.
- All of our product decisions, what to build and what to deliver, are theory until the customer actually uses the deployed product and we learn from that interaction.
If you take these two critical points to heart, then your organization will do all it can to shorten the time to deployment and action to shorten the time to gain new learning in the market. This limits the length of the costly business guessing game, the cash-draining theory time.

Continuously Learning at High Velocity

The way you can do this is by continuously shipping, continuously delivering, continuously learning how to improve how you learn and deliver—continuously improving your internal capabilities and continuously transforming.

Unfortunately, many organizations that want to increase velocity go faster without improving their ability to learn at this new speed.

The implications of this short-sightedness are profound: When you’re leaning and looking backwards, you’re not improving how you learn from your customers in real time and, instead, you’re adding to your risk going forward because you’re so out of step, and out of touch, with what the market wants and needs.

Every Act of Design is an Act of Feedback

Too many companies fail to obtain crucial feedback. They throw a ball up in the air and walk away before it actually lands. We see this in software development when an organization releases a new quarterly product or feature and returns four months later; sadly, this approach doesn’t allow for much effectiveness tracking, or much learning, or much improvement.

Which is why every single action in the continuous transformation process needs to be an act of design. The act of design is an act of feedback. And, in continuous transformation, you’re continuously getting feedback—whether you’re shipping product externally to a customer or you’re making changes inside your organization.

The bottom line is that you need to continuously test your assumptions about the world, as well as your effectiveness in responding to those assumptions, if you want to keep up with continuously changing customers in the continuous economy of the 21st century.
May 30, 2016
DevOps Brings IT Out of the Shadows

One of the biggest threats to organizations today is shadow IT—unsanctioned and unknown technologies and applications being employed by maverick users. Shadow IT represents a security risk for your company—the IT department can’t defend and protect technologies and assets it doesn’t know about—and should be eliminated. One of the best defenses against shadow IT is DevOps.

When I worked in the trenches as a one-man IT department—part network admin, part tech support—there always were one or two individuals who knew enough to be dangerous. As frustrating as it was to deal with completely clueless users who didn’t know the difference between the computer and the monitor and weren’t even really sure where the power button was, those who knew enough to go rogue and reconfigure their devices or introduce new applications and services were a more existential problem for the organization. In today’s era of BYOD and cloud services, shadow IT is a scourge significantly greater than what I faced.

Don’t get me wrong—I’ve also been on the other side of that equation and I understand the motivation that drives shadow IT. Users just want to get their jobs done, and the people in the trenches know better than anyone what the hurdles are and how to fix them. Requesting new technologies or capabilities from IT is a cumbersome and tedious process at many organizations, so in the name of expediency users just do what they need to do on their own.

DevOps can help solve the shadow IT problem in a better and more sustainable way, though. There are two benefits that DevOps brings to the table that minimize the potential for shadow IT: More rapid development and empowering individuals.

First, an IT organization that has embraced DevOps will be quicker to respond to requests from users. Replacing the traditional software development life cycle with a more agile and continuous pace of development means that feature requests can be incorporated much faster.

Second, one of the cornerstones of DevOps is the underlying culture—the breaking down of silos and removal of barriers and bureaucratic nonsense that get in the way of efficient progress. Essentially, those rogue technologies and applications that comprise shadow IT in other organizations are simply a part of the larger DevOps whole in an organization that has embraced DevOps. There is even a term ascribed to users outside of traditional IT/developer roles who develop solutions: “citizen developers.”

The 2015 State of Citizen Development Report explains in more detail what a citizen developer is: “Citizen Developers are empowered problem-solvers from the various lines of business who have the drive and determination to engage in app development even though they lack traditional coding skills.”

That isn’t to suggest that in a DevOps world everyone can just go set up virtual servers, or store data on personal cloud services and that it’s OK. It just means that when users are given the tools and freedom to develop solutions that have the blessing of IT and the rest of the organization, they don’t need to function in the shadows.

Embracing DevOps and the citizen developer movement enables IT to work in harmony with users to develop solutions that work rather than fighting against each other and ending up with shadow IT servers, applications and cloud services that IT isn’t even aware of. Organizations that are concerned about the impact of shadow IT should look at ways to harness the power rather than just trying to ban shadow IT completely.

February 16, 2016