DEVOPSdigest

Most organizations were already embracing transformation initiatives to improve efficiency, increase flexibility, and strengthen both employee and customer experiences. Whether it was about incremental improvements or complete digital transformation, the recent pandemic accelerated and widened the scope of such efforts. Automating a lot of manual processes and activities quickly became the norm, especially since manual efforts did not fit well with an increase in remote work.

What also became more prominent was the inability to keep up with the demand for such transformation. Not just creating new applications but dealing with the need to rapidly adapt existing ones. Even with low-code platforms speeding up the construction of applications, the overall speed of solution delivery often feels glacial.

Fortunately, this problem has been seen before, and over the past few years, addressed better than ever before, even if it was only happening in one corner of the overall industry. I'm talking about DevOps. The fusion of development and operations sprang from the need to evolve beyond the rigid, monolithic software release practices common in legacy environments. In a nutshell, DevOps is all about operationalizing and automating much of the software pipeline — the "building / testing / packaging / releasing / configuring / monitoring as code" mantra — to get development, testing, security, etc. in lockstep. It embraces an agile mindset of continuous integration, continuous delivery, and rapid iteration that leads to high application quality and availability.

DevOps required new tools, new techniques, and new ways of thinking. Its biggest fans tend to live in the part of the industry that writes code, that works on large-scale commercial efforts, especially in hosted cloud-delivered offerings. But we who deliver a long tail of bespoke business applications can learn a lot from them.

The world of business applications has polarized into two extremes. The first one is old-school waterfall projects; monolithic, "boil the ocean" efforts plagued by analysis paralysis, reams of documentation, endless meetings, and long delivery cycles. They're still there, largely because clients effectively demand them by insisting on firm fixed price arrangements funded by one-time budget allocations.

The second extreme would be the abdication of business application creation to people without development experience, namely citizen developers. Ad-hoc solutions built outside the direction and oversight of professionals. Neither approach is ideal.

Incidentally, it's not about code- vs. low-code, either. Professionals have embraced both. And some citizen development involving scripting is de facto code. This is about a mindset.

A DevOps mindset applied to business process automation looks like this:

Continuous

Much like software, business processes are continuously evolving. People and processes change over time, and the organization's automation must be able to change alongside. Rigid, monolithic automation initiatives — just like monolithic software releases — are not the way modern organizations should approach digital transformation.

Citizen developers tend to treat their efforts as "one and done," rarely having the vision and ability to understand how an application must be maintained and evolve. They build for an immediate need, not a larger or longer-term organizational requirement.

Instead, organizations should expect the equivalent of a Continuous Integration / Continuous Delivery (CI/CD) process automation pipeline, where processes continuously adapt as needs change.

Iterative

While iterative and continuous are closely related, I separate this out for a reason: for many organizations, automating a process will be the first time the process has been explicitly explained and documented. In fact, consensus as to what the process is (or should be) might not even exist. Simultaneously, processes will inevitably have exceptions, and it may be difficult or impossible to accurately predict these beforehand.

As such, it should be expected that early automation efforts will be found wanting. In fact, that "need to get everything right" is part of the problem with monolithic initiatives. Much like an agile mindset for software development, process automation benefits from iteration.

That said, both continuous delivery and frequent iteration can create a problem when it comes to process automation, because many automation platforms (most, really) are not designed to support change in a production environment. With most platforms, that change is laborious, and with others it can charitably be called hacking. It is thus important to look for tools and platforms that are built around the need for change.

Which brings us to our final commonality between process automation and DevOps:

Shifted-Left

An artifact of the lengthy release cycles in software development was that it allowed adequate time for separate quality assurance, security testing, and remediation. With DevOps, there is an obvious desire to shift these parts of the process left (i.e., earlier) in the cycle, such that security, quality testing, issue identification, and fixes are all handled as part of the development itself. Mind you, it's not (for example) that developers must suddenly become security experts; it's that DevOps and SecOps must work collaboratively.

For process automation, what needs to shift left is process identification. As touched on above, automation might be the first time these processes are actually documented. Even so, if there is anyone who understands the process, it's the people — users — who take part of it. This is one reason why organizations are starting to adopt a hybrid approach of citizen-assisted development.

Instead of citizen development giving birth to applications that get orphaned close after, or IT-led initiatives that create processes that fall to earth in usage, the citizen-assisted model shifts left to create sustainable teams that are made up of innovators and curators working together.

With citizen-assisted development, business stakeholders and users can be assigned the task of creating something (perhaps using a low-code / no-code tool) that illustrates what they want. Professional developers are assigned the responsibility for turning those prototypes into things that really work, considering exceptions that must be handled, integration that cannot be taken for granted, data access security, etc. The collaborative result makes process part of the automation.

In short, companies are starting to realize that process automation is best approached through a DevOps lens: citizen-assisted development but with IT in control; agile (not monolithic) design and deployment, with in-production tweaking and iteration to fit the automation to the process. And it's about time.