Skip to content
No-Code Automation

Scaling No-Code Automation of Processes with Industrial DevOps

The automation of processes has played and continues to play an essential role in companies. Available data and networking offer almost unlimited possibilities today. But to use this chance, companies need to become more agile. Thus, many opportunities remain untapped because the complexity of automation across departmental boundaries brings risks and challenges that are difficult to assess. The question is: Which methods and technologies are suitable for safely mastering complexity and the associated risks now and in the future?

Industrial automation has changed

The goals of automation have changed. It is no longer a matter of producing many similar products as cheaply as possible, as it was still the case in industrial mass production. Instead, the focus is on flexibility and quality. The goal of Industry 4.0 has long been customizable production from low volumes to one-offs (batch size 1) that can keep up with the costs of mass-produced products.

Systems are digitalized, connected, and automated across departmental boundaries to achieve this. The more networking progresses, the more complex processes and automation become. Adjustments and changes have to be made more frequently, such as adapting production to new product variants, optimizing or implementing business decisions. Continuously developing a digital system and putting current versions into operation is known in DevOps as Continuous Delivery (CD).

Flexibility through frequent adaptability

Continuous Delivery is one of the goals of software companies when DevOps comes into play. DevOps is an umbrella term for values, principles, methods, and technologies to make frequent changes to complex systems and deploy them to production.

Another goal of DevOps is to enable customer-centric working. In this context, the focus is on the customers. Decisions are measured by the quality of the outcome from the customer’s standpoint.

But how did it all begin? Through agile methods in software development (Dev), updates emerged at increasingly shorter intervals. The deployment was the IT Operations (Ops) departments’ responsibility, but they were not prepared for so many updates. The resulting conflict was resolved by close collaboration between software development (Dev) and IT operations (Ops), and DevOps was born. Today, DevOps helps to develop gigantic, highly complex software systems and to apply hundreds of changes every day.

Industry 4.0, Smart Factory and Industrial DevOps

On its way to a Smart Factory, the manufacturing and processing industry has to solve similar problems. The methods and techniques that already exist in DevOps can be applied to the industry. To match the unique requirements of manufacturing, they are extended by key technologies like the Internet of Things (IoT), sensor technology, or cyber-physical systems. Other technologies used for digital transformation, such as cloud computing, artificial intelligence, agile methods, and Big Data are used in the DevOps approach for years.

As is already the case in banks, insurance companies, or retail, the increased use of software leads to a fundamental change in manufacturing companies. They are evolving into software companies with production facilities. It seems only logical to use the proven methods of software companies as a blueprint for the agile transformation. The DevOps approach in the manufacturing and processing industry is called Industrial DevOps.

Combining the physical world of machines and production facilities and the digital world of software is challenging. Skilled workers have the knowledge and skills of their field of work, but they are usually not programmers. Programmers, on the other hand, cannot be experts in every specialist area. High demand for communicating requirements is the result, which costs time and comes at the expense of flexibility. The solution currently discussed for this dilemma is a new type of programmer who is a specialist in her domain and can automate and adapt processes independently with No-Code or Low-Code. Programmers will not become obsolete, but they take responsibility for another abstraction layer.

A new kind of programmer

No-Code enables professionals without programming skills to automate and customize processes as part of their daily work using a graphical user interface (GUI). These Citizen Developers are specialists in their domain or department of the company. They can best decide what is required. Lengthy communication with IT and software development is no longer necessary. The time between identifying a need and implementing a solution is reduced drastically. Flexibility increases because changes are applied during day-to-day operations.

Furthermore, small targeted changes are associated with less risk than large projects. If a change does not bring the desired result, it can be rolled back. The advantages of No-Code are apparent. Nevertheless, decisions must also include difficulties and criticism.

Criticism of No-Code and Low-Code

Programming is more than just developing solutions that work. It is also about ensuring that the entire system remains maintainable and expandable for a long time and even after many changes. In software development, we talk about quality. Examples of inadequate quality are:

  • too complicated solutions
  • missing documentation
  • bad readability (difficult to understand)
  • unnecessary functions
  • dependencies where there should be none

     

No-Code and Low-Code are criticized for not applying effective methods to ensure the quality of solutions. This leads to the degeneration of the entire system and is at the expense of maintainability, extensibility, and ultimately operational reliability.

Quality is also a goal of DevOps and, therefore also of Industrial DevOps. Clear yet flexible, modular structures form the basis for quality. Collaboration, in other words working together in a team and across team boundaries, is an essential factor. Solid processes to implement changes quickly while ensuring the quality of the solution brings everything together.

For No-Code platforms, this means supporting these quality factors with appropriate functions is required.

No-Code, modular structures, and collaboration

The titan No-Code platform supports workspaces. A workspace is customized for the requirements of a department. A team sees what is needed to automate its processes and create a module that is managed autonomously by the domain experts of the respective specialist department. Clear interfaces are defined for communication with other departments or applications in the network (tools). Of course, in the sense of DevOps, the departments concerned must work closely together. 

A team workspace is comparable with microservices known from software technology. Microservices are modules with well-defined interfaces of which a team explicitly assumes responsibility. This approach creates an architecture that mimics the organizational structure.

Cognitive load and Conway’s law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

Melvin E. Conway

A system is, for example, a complex product such as a software solution, a machine, or a technical device. Production environments or IT infrastructures are also examples of systems.

In their book Team Topologies, Matthew Skelton and Manuel Pais show how team organization and technical solutions are interdependent. This phenomenon, known as Conway’s Law, can be used effectively to reduce people’s cognitive load in the organization. If Conway’s Law is not taken into account, but instead, organization and technical system are considered independently, workarounds and decreasing quality of solutions will occur. Team Topologies and DevOps, consider the enterprise as a socio-technical system. People, organizational structures, and communication channels (face-to-face or digital) are included in the consideration. All aspects are captured. If you only look at one of both sides, you are blind in one eye and miss opportunities and problems. Signs that Conway’s Law is not being sufficiently observed are:

  • high mental load on the teams
  • too many different tasks at the same time
  • frequent reorganization of teams and processes
  • decreasing motivation
  • frequent, unforeseen disruptions to the process

     

Conclusion

Continuous delivery of new and improved digital processes is not a project but a business objective. Of course, culture is an essential factor on the way to the goal, but not the only one. Creating company-wide digital connections without losing the flexibility that is intended through declining quality requires a modular architecture that is oriented along with the company’s structure. For customer benefit to be at the center of entrepreneurial activity, technology must not create any obstacles. It must be part of the daily work and must not stand out as such in a negative way.

Modular architectures help to adapt new technologies at scale, digitalize new business areas and take safe steps toward a more agile production. Potential obstacles and risks can be better identified and avoided.

Empowering professionals in departments to automate and regularly adapt processes without the help of IT experts may seem like a paradigm shift. However, in DevOps and the organization of modern, successful companies, the autonomy of specialist teams is the path to better decisions, faster reactions, and more tolerance to unforeseen events (resilience). The reason for this is the proximity of the specialists to the information required.