The fall of the wall: Breaking the barrier between Development, QA, Security, Operations and the Business, depends on which elements?

This is my first article…and just is my humble opinion, some ideas and thoughts

It may sound a bit awkward, but within DevOps communities, Agilist communities and Open Source communities, we (I apologize for generalizing) believe that everyone is transforming digitally, and is doing so through the cultures we promote.

The truth is that NO, there are many who are missing this and are lagging far behind. The global situation pandemia with COVID-19 has evidenced a lot of this (in the school of my daughters, for example, they are still learning how to hold remote conferences to teach classes).

I consider that our Technology communities should be inclusive and open, where we can speak to a language understandable to several persons and roles like an Investor, an Executive, an Agricultural entrepreneur, a Programmer and more. Because technology is what can enable them to achieve their goals much faster and at less cost.

My professional experience in the last 10 years has been relatively based on the area of Pre-Sales and Solutions Architecture in companies that integrate solutions to deliver services and products to other Companies of any size and sector, solutions that accord value to the Business, and above all value to human beings .

Although the increase in the adoption of Agilism and DevOps in the World has increased, it is true that there are still many sectors left behind in traditional models and legacies, those that were not born in the time of the Cloud Native era, or Cloud 2.0.

Traditionally, organizations structured in two large areas, separated by a “big wall”: on one side the development, using their own models, standards and methodologies, and on the other side operations with their models and methodologies, but not only that, there is also the team of QA, Security, Compliance, Innovation and of course … The Business.

If we zoom to the Project aspect and DevOps teams, ¿how can we approach to avoid force them to think that a Developer must learn and be a specialist about Virtual Networks, and an Operator that needs to learn to write code in Python?

Have we asked ourselves if these professionals want to learn these practices with the same passion and seriousness with which they have attended their current specializations?

From my humble point of view, that message is missing “something”, and for that and other reasons, roles like the famous “FullStack Developer” have their days numbered (which is another debate). The phrase “full stack” is really just a business buzzword (for me), not an engineering designation.

DevOps is a trend where followers are growing rapidly, especially among midsize companies, more agile for change, in which development and operations collaborate on the same team to ensure that changes to applications are executed as quickly as possible and with the minimum of problems, adding value to users and keeping the business open to adapting to market changes, consumer tastes, among others, which means that all these professionals will have more hours to dedicate to his family, his hobbies, and not solving problems by being reactive.

So let’s avoid creating new unfortunate “phrases” around DevOps culture.

But what can we say to large companies that do not yet know how to transform in order to adopt these beneficial models?

The software generation has created a new methodology that disputes the fame of Agile, Continuous Delivery (CD) is positioned as a trend in the delivery of computing processes that can be transferred to all kinds of sectors of our Countries and departments in the organization. What does it consist of and what benefits does it have?

Personally, I want to give a more simplistic or Human-Being-oriented point of view, with the aim of aiming better to break those barriers that we mentioned.

Continuous Delivery (CD) has similarities with Agile, especially since both has the same beginnings, both were born thanks to the innovative strategies carried out by the information technology sectors (especially what was born in Cloud). CD emerged as a software development methodology, which instead of applying improvements in volleys, the process is carried out gradually, so that the customer has the software code step by step, and thus be able to control its functionality continuously.

In 2010 with the publication of the book “Continuous Delivery” written by @Jez Humble and @David Farley, when this methodology began to sound strongly in the business world, it will cover the techniques to create this continuous flow of version deliveries to pass a production more safely and functional.

Much of the barriers come from the confusion, the mythical message about culture, and the resistance generated by listening to it that way … (let’s avoid creating something like the “FullStack Developer”) this confusion has brought about mixing what is DevOps with the necessary requirements or the necessary benefits when implementing DevOps.

Being practical, in order to make the message digestible to EVERYONE that are still very traditional and resistant to change (by ignorance, not by election), we must tirelessly repeat that the objective is to help an organization or people to build products and services supported by IT, that is, supported by software, more fast, better quality and with a lower cost (it should be highlighted when we talk to the C-Level and financial people)

Another great challenge is that DevOps squads around the world must make a crusade to help organizations like Banks, Retail, among others, first to THINK about new modern applications, and then to build those new Core applications that allow them to move from their legacies to applications born in the cloud, but because they will take advantage of the benefits that the Public Cloud offers.

We cannot remain in philosophy, in the message of insisting on moving and transforming without helping them in a practical and tangible way to do so, adapting known and proven practices to organizations.

These organizations at least need to have a roadmap, with benchmarks, estimated times, and a high-level risk matrix that allows them to meet at the board of directors’ table to evaluate and make decisions.

Let’s rescue some principals now:

• DevOps is a methodology or a culture for creating good and high quality software. And you must know very well what problem you want to solve with that Software, and for whom you want to solve
• DevOps is based on integration and collaboration between software developers and system administrators (but also QA teams, Security teams, etc.), not on the conversion of a developer as administrator, or an administrator as developers.
• DevOps allows you to build software faster, with higher quality, lower cost and a high frequency of releases that quickly meet the needs of customers and users who consume these products and services. And again, you must know very well what problem you want to solve with that Software, and for whom you want to solve

Technology has been integrated into almost all aspects of our lives today, so why is there a delay in some Social Communities, Organizations, Countries and Companies?

Now, i will mention the common barriers that i have encountered in LATAM, which is the Region that i guees i know well:

1. Money (Costs and Budget): Businesses are wondering if they should invest even more in training numerous new DevOps squads, invest in Cloud Infrastructure (and what will they do with IT On-Premise investments?) Invest in Agile Couches, etc., we need to help them understand this phase.
2. Knowledge — Lack of training: Above all, training oriented to the characterizations of each company, not so much in training on technologies in general (Jenkins, Terraform, Containers, Kubernetes, Python, JSON, etc.). They must first understand the problem to be solved, then the Business, its Domains and Dependencies, and then be able to transfer it to a technological Model.
3. The excess of bureaucracy within organizations — far from true agility : Here is a real challenge, since it involves shaking the comfort zones of certain groups, it is not an easy challenge. But if we focus on the benefits, and with a good guidance, we will achieve it.
4. Lack of infrastructure: Can we implement all that you tell me in current equipment, ? An already quite suggestive barrier.

Personally, I am sharing my message to the Development and Operations teams I meet to drive the adoption of DevOps from below, and consequently CD, I am saying simply:

You don’t need to know EVERYTHING to adopt DevOps, what you should know is that the work will now be 100% collaborative,

• Focus on executing people-centric actions,
• Encourage continuous improvement
• Invite failure to enter your house, mistakes will make you better, and the faster you identify mistakes, the better the result
• Build with the end in mind, and…again: you must know very well what problem you want to solve with that Software, and for whom you want to solve

You should feel responsible for the Solution and Final Product, even if it has nothing to do with lines of code or with the Security resource settings. You will be integrating autonomous and multidisciplinary teams, but cross functional