Skip to main content

Tapping Into the Creative Side of Software Development

By DTCC Connection Staff | 4 minute read | January 12, 2024

DTCC’s Marc Masri shares insight on DTCC’s IT DevSecOps journey and how automation is at the heart of our success. Below are links to content he has published on this topic:

In a previous article, I discussed how software development is both science and art. While writing software code is very much a science, there is also a human element that involves framing a problem and then thinking creatively about ways software can solve the problem. Software application development is a creative process that requires not only technical skill, but inventive ingenuity.

With that in mind, let’s discuss how reducing toil, or manual, repetitive, and automatable tasks related to production services, in the release management process can free up additional resources to allocate the more creative aspects of software development.

Removing “Toil and Trouble”

Preparing an application release post development can be a complex process. Traditionally this involved several individuals who must manually review, validate, and sign off on artifacts in preparation for a production release. This can create a disturbance in the flow of development and frustrate agile squads who find themselves toiling about rather than rolling directly into their next sprint. When process and procedure soak up time and energy, then brain power/creativity is diverted from the pursuit of finding innovative solutions.

With this in mind, we have streamlined many of our processes to reduce toil – and the troubles that manual processes can cause – with the creation of our Self-Service Platform (SSP). One prior example relates to managing firewall network traffic. Previously, new firewall requests to monitor and control network traffic had a multi-step siloed delivery process with bottlenecks. By streamlining and automating the workflow, however, we achieved lower environment firewall delivery improvements by as much as 90%.

While this is one example of an efficiency improvement, over time we have synergized much of the tooling and processing related to release management. Some of these improvements include:

  • Necessary but manual processes: Our system analyzes and flags any issues as the code is being developed, rather than relying on testing at the end to find problems.
  • Request/Ticket review: Automating processes eliminated redundant requests, which required one human to create and another human to review. Not only does this eliminate toil, it also delivers a level of precision in organizing the release that could not be achieved with the old manual processes.
  • Legacy technology: We examined our tools, looking specifically for gaps and bottlenecks that slowed release and found that legacy technology was being used for specific types of deployments. In some cases, different tools were used to build and deploy across environments (dev-prod). Our team rationalized these tools and capabilities bringing multiple separate processes into a single, simplified development and release management process. The end result was a synergy between the DevSecOps Delivery Pipeline, Agile and Release Management systems.

Why now? Monolithic to Microservices-Focused

Modern software requires more frequent and more complex releases. Most modern business applications are microservices-based, which means the software is made up of many separate parts or components. Each component can be managed and developed separately from the rest of the application with the ability to change and test multiple components and package them into a single release.

A monolithic approach is managed by a single, unified entity and any change requires the entire system be tested, validated, and deployed, with multiple changes requiring multiple deployments. Breaking those parts into a greater number of smaller pieces can offer real advantages, such as managing the quality and scale of the software in the long-term. But there’s a small catch: all of these smaller parts must come together at release and run-time. So, while a monolithic approach may have required just a single deployment, a microservice application will require many smaller deployments, perhaps deployed in a particular order.

To help visualize this, let’s think about a travel website designed using a microservices-based architecture as an example. One part of the system manages the search function, while other parts manage reservations, payments, and other functionality. There are also capabilities such as sending customer updates, monitoring reservations for changes, and more. All of these are separate functions within the overall ecosystem. If a change is made to an individual part (such as enhancing a search function with filters), the code can be edited for the individual part being changed and then tested and deployed without needing to also test the reservation, payment, and other systems.

We were able to streamline and build this modern microservices architecture into our own DevSecOps and Release processes. As a result, this enhances our deployment process as we can change, test and deploy multiple components individually, while packaging into and managing a single release. These enhancements speed up our deployments, as changes are packaged and require a single set of approvals, instead of requiring approvals for each individual change. Furthermore, it reduced risk, by eliminating the manual orchestration of each microservice deployment during the release.

Making Room for Innovation

With fewer steps and fewer approvals, there is less email and back-and-forth communication, and less time spent on non-innovative pursuits. We also dramatically reduced the volume of paperwork created in the process.

By taking this holistic approach to process automation and eliminating bottlenecks, we also made it possible to do more with the same team. We can now support a much greater volume of deployment than ever before, which enables us to deliver more innovative solutions at a faster pace.

Innovation is not a straight line to the end solution. Innovation often means having an idea, testing it, failing and having to try again to find a viable solution. Freeing developers from unnecessary tasks reduces toil, and that creates more space for innovation.

Marc Masri - Image Profile
Marc Masri

DTCC Executive Director, Enterprise DevSecOps

dtccdotcom