Improving Time to Value: Process and Parallelization

There is a common lament at Christmas time. It is cried from the tops of roofs and from underneath the prickly boughs of pine trees.

"When one light goes out, they all go out!"

This is the cry of someone who is stuck with lights strung in a serial circuit. I won't digress into a lecture on why this is the case, but suffice to say that a single, burned out bulb is a blocking factor.

This is not true for those blessed with lights strung in a parallel circuit. One bulb can fail while the others go on burning brightly.

What's this got to time to value and applications? Everything. Because as it turns out, traditional IT is really driving to production in a serial circuit, while modern app developments is burning at all hours on a parallel one.

Process

In a recent blog, Pivotal Global Field CTO James Urquhart puts forth an important picture of continuous IT that focuses, appropriately, on process over product. He calls it the Path to Production.

The idea of a Path to Production is really about process and, for traditional IT, parallelization. This concept is core to modern application development and architectures. The very decomposition of apps into individual, focused components (sometimes called microservices) naturally leads to parallel development. This is because smaller teams are working on different components at the same time. This, ultimately, is what makes Agile work as a mechanism to achieve greater velocity and decrease time to value for applications. It's not smaller teams. It's not smaller apps. It's the parallelization achieved by leveraging these concepts in the development and delivery of applications.

The same approach applies to the Path to Production. That is, those production components (services) necessary to implement scale and ensure security of applications is part of a much larger process and some of it can be developed and delivered in parallel.

What stands in the way is traditional IT. Serial IT. Waterfall development methodologies that spilled over into the pool of production. We build networks as serial channels because data flows serially through the network. From the router to the firewall to the load balancing to the app server to the database. Data flows in a predictable path from one end of the network to the other. And so we implement and deliver those application services in the same way: in a predictable, serialized process that follows naturally the data path.

That's not going to work anymore.

Firstly, because there are now multiple data paths. Not just the data paths that traverse N-S and E-W, but the ones that veer off in other cardinal directions. NE to a cloud to retrieve a script. SW to retrieve sprites and web fonts. WSE to grab a map and embed it in our app.

But it's not just the distribution of data paths that makes parallelization of the path to production necessary today. It's the search for efficiency and speed, a.k.a. optimization.

Parallelization

To pick up the speed necessary to execute on today’s time to value expectations parallel development is necessary. Not just in app dev, but in core IT, as well. If we look at the breadth of application services in use by organizations today, we can see multiple areas in which parallelization can aid in speeding up deployment.

It isn't so much that traditional IT is siloed. After all, the result of a microservices architecture is tens or hundreds of tiny siloed teams, each focused on a very targeted set of application functions. Traditional IT is already siloes within siloes. The problem is that Agile development practices encourage parallel development within its siloes, and traditional IT is still stringing along production processes in a methodical, serialized way.

It's the hand off between teams that's problematic and the way in which we mirror network traffic in our path to production. It's not a serial process, and whenever we can parallelize development and delivery of services we should.

That means cross-functional team structures that encourage collaboration sooner rather than later.

By parallelizing processes through adoption of more Agile practices across all concerns, organizations can achieve greater speed and efficiency in their path to production.

Process is the Product

As James alludes to, the Path to Production is really a process. And processes are composed of steps. As any black-belt Six-Sigma process ninja will tell you, speeding up that process is about finding and eliminating inefficiencies. In production, those inefficiencies appear as wait times (handoffs) between rigid, serialized steps in the deployment process.

Tools can help. But ultimately improvement will require a long, hard look at processes and a search for opportunities to parallelize delivery of application services as part of your Path to Production.

Culture - specifically a culture of collaboration - is not optional. It has a very real impact on behaviors and practices. Team structure alone dramatically changes pipeline automation, with traditional single-function teams falling behind their contemporary, DevOps driven counterparts. Push for more collaborative team structures. In that same vein, a collaborative team should be aligned on key metrics. Shared metrics enables NetOps and Security to work toward continuous deployment without penalty. Right now, nearly three-quarters of NetOps are measured on NETWORK UPTIME. Frequency of deployment barely registers for them. They are going to focus on keeping the network up because that's what they have to focus on. Shared metrics give NetOps permission to focus on what the business needs - faster, more frequent deployments. 

Finally, empathy is required. You're all on the same team and - it may surprise you to learn - value the same things. NetOps are just as likely to place a high degree of importance on pipeline automation as DevOps. Remember, DevOps has a ten-year head start on NetOps in navigating and overcoming obstacles around integration, tools, and skillsets. Collaborative teams can help by promoting standardization on tools that span from delivery to deployment (like Jenkins and GitHub/GitLab).

The path to production is not a product. It's a process. And it's a process that needs to be collaborative and delivered in parallel whenever possible to improve time to value and enable successful application deployments.