Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why software architects should lead continuous delivery

Juni Mukherjee Owner, Continuity

In many organizations, release managers have been tasked with driving the process of continuous delivery (CD). You'll get better results, however, if you put a software architect in charge. Here's why.

Qualifications and conflicts

CD is all about deploying quality software frequently, in an automated fashion, to production. Adopting CD means committing to the automated delivery of software. But the release manager's job is to manage releases that are executed manually. If you do CD right, everything becomes automated, which means that the release manager's role won't be needed anymore. By asking release managers to automate releases, you're asking them to put themselves out of a job. Furthermore, even if you create a partially automated environment, you'll have far fewer manual tasks, and your release management team will shrink every year.

Release managers are professionals, and they may very well support the organization's goals over their own job security. As the releases become fully automated, they can seek new opportunities within the organization.

However, other release managers may not be so supportive if they believe success in this endeavor will put their jobs at risk. Clearly, putting a release manager in charge of driving CD can create a conflict of interest.

But there's another reason why you shouldn't put release managers in charge of CD: software architects are more qualified.

The software architect advantage

Software architects should take the lead in moving CD forward because the CD pipeline is best designed by people who have an eye for architecture. CD isn't just a process improvement problem—it's a highly technical initiative that affects everyone in the organization and the organization's ability to innovate. CD reduces time to market for new features, thereby helping the business stay ahead of its competition. This makes software architects the most qualified to lead CD initiatives.

The design of your CD pipeline should closely reflect the architecture of the product that flows through it. If your product architecture is too coupled, and requires the validation of a highly integrated environment, the tangled, overly complicated pipeline job dependency graph that results will be detrimental to your feature delivery cycle time. If your teams are attached at the hip, they won't deliver unless everyone they depend on and everyone who depends on them is ready. This leads to long lead times before your check-ins go to production.

Software architects can influence your overall test architecture as well. Depending on where your organization is in its architectural journey to service-oriented architectures and, ultimately, microservices, you can make your test strategy simpler and test cycle times shorter, without compromising quality.

Looking beyond tools

Release managers in charge of CD often assume that the choice of tool is the most critical factor in speeding up the CD pipeline. The tool is indeed important, but it cannot solve architecture coupling issues or an overly complicated test strategy problem. While tools can make a big difference, the most important issues are still your vision for the product and the tests required.

Release managers may attack CD as a problem to toss between one tool and the next. The downside of fixating on tools is that CD isn't just a tooling problem. You should establish the process first, because becoming fixated on one tool can get you stuck within the confines of what that one tool can and can't do.

Only software architects have the experience to understand and appreciate software development, software testing, and software release challenges. They can unlock engineering value in the product, the tests, and the CD pipeline so that engineers are able to develop, test, and release software more frequently, enabling the business to make money. Why would you trust such an important job to anyone else?

Keep learning

Read more articles about: App Dev & TestingApp Dev