Barriers to Automation: Silos and Legacy Code
November 14, 2018

Viktor Farcic

What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation?

At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? If we can create robots that assemble cars, we can surely create a Jenkins job that builds software, runs tests, and deploys containers. Car assembly is undoubtedly harder to accomplish than building software. Yet, an average company does not adhere to that logic. Why is that?

Two main culprits prevent many companies from automating all the repetitive process: silos and legacy code.

I often encounter companies that have a lot of small pieces of the process automated, but without an overarching pipeline that joins those pieces into a fully automated process. As a result, not much is accomplished since the whole process still needs to wait for handovers and (often long) manual actions.

The reason behind missing pipeline that envelops the entire process is the lack of responsibility for a product. Different silos do their stuff (e.g., coding, testing, deployments), and nobody understands the big picture. At least, not those that are capable of redesigning and refactoring applications and writing automation scripts. Instead, silos keep introducing manual approvals and handovers because their parts are done, and they don't care or even know what's happening next. To make things more complicated, when you do decide to join those disparate pieces of automation into a product-oriented fully-automated pipeline, you'll realize that it cannot be done. You will not be able to assemble those automation snippets into a pipeline because they were not designed to work together. Even when you do, you'll face a challenge with legacy code.

The most common problem with automation is legacy code. By definition, legacy applications are those that were not refactored and those that did not keep up with the changes in the industry. That does not mean that all the apps that started their life long time ago are legacy. But, instead, that those that did not keep up with time are. Now, you might ask why does that pose problems with automation? The answer is simple. The applications that are not designed to be buildable, testable, and deployable (according to today's standards) cannot be moved through their life-cycle through automation. At least, not without too much effort that often results in slow delivery and an insufficient return of investment.

If we accept that silos and legacy applications are often preventing automation of the development process, the answer to the initial question is straightforward. Automate development processes of the new applications. Design them in a way that the are automation-friendly. Do it correctly from the start, and you'll see immediate benefits. Make sure that you pick an application that is managed by an autonomous team that is free from administrative obstacles and does not need to wait for others (silos) to continue their work. After all, why would you invest in automation with applications that you do worth the improvements? If you really want to improve older applications, you'll refactor them. You'll make their architecture better and, during the process, you'll make them more automation-friendly. Automating something that you do not want to refactor is a waste of time. Legacy means that you gave up on it so just keep it rotting. Similarly, automating a process that requires handovers from one team to another is also a waste since the lean time is going to slow you down no matter how much you automate individual pieces.

All in all, automate deployment processes of the applications managed by self-sufficient teams and those you do believe are worthy candidates, not those you let rot for too long (legacy). Once you make the decision which applications should have an automated development process, embrace automation fully. Do not pick and choose what to automate. Instead, write an automated pipeline that envelops the whole process, from a commit to a code repository all the way until a release is ready for production. If you do that, you'll embrace continuous delivery. Now, you might think that's too much, but I would argue that it's not. Writing code is always unique. It's not repeatable. Everything else, after we commit that code, is a repetition of the same steps, over and over again. As I already stated, it's silly NOT to automate repetitive steps, unless the applications are not designed to be automatable.

To summarize, pick an application that is a good candidate for automation, design it (or refactor it) to be automation-friendly, make sure that it is managed by a single team, and automate the whole delivery pipeline from a commit all the way until it reaches production. Instead of automating a segment of a pipeline for all applications, automate the entire process for a selected set of applications. Embrace continuous delivery (or deployment) entirely.

Viktor Farcic is a Senior Consultant at CloudBees

The Latest

December 11, 2018

Companies expect increased reliance on Cloud Native Applications (CNAs), however security concerns could prove to be a major obstacle, according to The State of Cloud Native Security ...

December 06, 2018

The general consensus tends to be that in the world of agile and DevOps, ITSM teams are increasingly being left behind. But the truth is, in more forward-thinking IT organizations, this isn’t the case. The fact is that ITSM is playing, or at least should play, a growing role in support of agile and DevOps initiatives. But this role still remains limited due to the fact that DevOps teams, and their management, are (more often than not) leaving them out as a tool of choice ...

December 05, 2018

The industry is revealing increasingly optimistic attitudes towards mainframes, with 93% of executives and 92% of all respondents viewing the mainframe as a strong long-term platform – the highest level in five years – according to the 2018 Mainframe Research Report from BMC ...

December 03, 2018

ActiveState surveyed developers and programmers in 92 countries to better understand their pain points and assess how businesses can better work with their organizations. The survey results establish a starting point for understanding the challenges that coders confront when working with open source runtimes ...

November 29, 2018

Organizations with established DevSecOps programs and practices greatly outperform their peers in how quickly they address flaws. The most active DevSecOps programs fix flaws more than 11.5 times faster than the typical organization, due to ongoing security checks during continuous delivery of software builds, largely the result of increased code scanning, according the latest State of Software Security (SOSS) report from CA Veracode ..

November 27, 2018

The push to make banking products digitally ready (and very quickly) has spurred the old “buy vs. build” debate in bank IT departments: Should we build our own software from scratch in-house? Or do we buy off-the-shelf solutions from third-parties? And while this dichotomy may have been a suitable mentality years ago at the start of the digital transformation revolution in banking, it simply no longer fits with the reality of today's more complex development landscape ...

November 26, 2018

With the rise of next-generation technologies, businesses have access to more data than ever, creating opportunities to develop new channels for revenue. Contributing to the increase in data is a growing reliance on the external supply chain. However, with the influx of data comes the necessity to understand the entire third-party ecosystem; its benefits and risks. Some of the most devastating breaches have been attributed to a third party ...

November 20, 2018

In today's digital economy, monitoring is a must. Your customers must be able to access your website and your apps, interact, purchase — and monitoring is one way to make sure this keeps happening. But the first question has to be: What should be monitored? With this in mind, APMdigest asked experts from across the IT industry for their opinions on what IT departments should be monitoring to ensure digital performance ...

November 19, 2018

Software developers and security teams have a well-known antagonistic relationship. Dev teams often feel plagued by the restrictive security standards placed on them by security teams that inhibit their ability to rapidly write applications, while security teams view developers as one of the biggest threats with which they have to grapple. There are three core challenges that must be addressed in order for security and DevOps to be in lockstep ...

November 15, 2018

Serverless infrastructure environments are set to become the dominant paradigm for enterprise technology deployments, according to a new report — Why the Fuss About Serverless? — released by Leading Edge Forum ...

Share this