Application modernization: The importance of an opinionated workflow

In earlier discussions, we highlighted the importance of aligning modernization efforts with business outcomes and corporate strategic alignment. We also explored the challenges associated with modernizing applications in an enterprise environment, including siloed culture and unexpected regulation or policy problems. Considering these factors, it becomes clear that achieving the desired value from modernization requires an approach that takes into account enterprise-specific details. It's important to note that this approach may not always result in the ideal or perfect technical solution. To help us navigate these challenges and achieve the desired outcome, let's explore the concept of opinionated workflows.

What is an opinionated workflow?

This is not a new concept:

• The Rise of Opinionated Software
• Non-opinionated vs. Opinionated Design

Some of the writing about opinionated workflows revolves around SaaS (software-as-a-service) products. However, I would like to focus the discussion around the concept that an opinionated workflow can provide outcomes aligned with our strategic goals, that are immediately usable in a specific enterprise environment because many of the choices (e.g., security, audit and compliance) used to arrive at the outcome have been pre-configured by members of the enterprise who know these standards best. 

With the right opinionated workflows, you can improve the velocity of both the developer feedback loop as well as the operations feedback loop. As stated in previous articles, these loops are necessary to deliver the agreed upon outcomes during the modernization effort, and also make it so that the newly modernized application can actually be operated with the existing operations culture of the enterprise. Improvements in the operation culture can be done during the modernization project. However, if an application modernization outcome requires the entire operations culture of the enterprise to also be modernized, the project might very well badly miss its timelines and budget constraints.

Let’s talk about the characteristics of a good opinionated workflow with respect to the specific challenges found in enterprises.

Characteristics of a good opinionated workflow

Should provide a valuable outcome to the feedback loop

As previously stated, the opinionated workflow should provide an outcome that benefits one or both feedback loops. Examples might be

• standing up a deployment tool (or chain of tools) with configuration for teams/users to consume right away, or
• creating environments that are configured to be compliant and are immediately accessible to the team requesting them.

Frictionless outcomes

Users consuming the output of the workflow (e.g., the deployment tool, environment, etc.) should be able to use it right away, without extra steps. There should be no reading of confluence pages to figure out complex post-configuration steps and no requesting permissions to use the artifacts, tools or environments provided by the opinionated workflow. The opinionated workflow should produce all of this, based on requester information and the goal they want to achieve.

Room for enterprise-specific customization

An ideal opinionated workflow is one that not only provides frictionless outcomes (e.g., tools, services, environments) for teams, but also provides configuration points behind the scenes so the outcomes being produced can be tweaked to work in that enterprise from an audit or compliance point of view. It's not beneficial to the team if they get an environment that fails all enterprise scans or is missing required hardening steps. The people in the enterprise who are aware of these requirements should be involved in configuring the opinionated workflow to produce compliant outcomes.

Everything is observable

When it comes to the opinionated workflow tool itself and the outcomes it provides, everything should be observable. This could include integration with existing tools (e.g., an APM tool like New Relic) or custom observability solutions. Observability stack should not only include services and environments system metrics but business level objectives as well.

Workflow should support swim lanes for developers and operators

Swim lanes are an important concept when it comes to cross-silo communication. A swim lane is a workflow that a team (e.g., developers from a line of business) can use (e.g., getting access to logs in a non-prod environment) without having to interact with other teams (e.g., operators from the infrastructure team). This means the developers are not opening tickets, sending emails, or Slacking with people to get what they need.

In a previous article, I outlined the importance of the “experiment” sub-loop when teams are trying to build.

In this loop, there can be lots of deployments, with the express purpose of creating a certain state in the deployed application and then looking at what shows up in the logs and metrics. If a lot of effort is required to get these, experimentation will suffer, which will affect both the quality and speed of product delivery.

Likewise, operations should be able to do their updates and patches to the infrastructure with minimal downtime for the developers.

Having such swim lanes can allow all required feedback loops to work concurrently, greatly improving the ability to get quality outcomes.

A good opinionated workflow should provide such swim lanes to both satisfy the needs of the consumers of the outcomes of the opinionated workflow provider, but also check the boxes of those auditing and assessing those outcomes.

Red Hat OpenShift: An example of an opinionated workflow for enterprises

Red Hat OpenShift is an example of an opinionated workflow for creating and managing customized Kubernetes clusters, which in turn can manage the contains that can power our developer feedback loop. But also, OpenShift adds tooling and opinions that can satisfy operational, security and audit concerns.

Enterprise customizations

Kubernetes has arisen as the accepted operational plane for running containerized workloads. But getting a Kubernetes cluster running in the enterprise that meets all the audit and security requirements of the enterprise might be too difficult for a development team. That said, different application teams might require clusters with different characteristics (based on their different workloads).

This might be troublesome for operations teams trying to support applications teams across the enterprise. This often results in developers having to open tickets and/or have meetings with operations, slowing down any sort of feedback loop, but helping to better address standards and spec enterprise specifics.

Add to this regulator requirements for workloads that touch customer data and/or increased risk of cyber threats should the application have public egress. Most major cloud providers provide a hosted Kubernetes option, which can help with some of the management toil and security hardening for operations teams. But, regulatory requirements and workload specific customizations are limited with a managed Kubernetes on a public cloud.

This is where OpenShift comes in. It provides an opinionated approach to a Kubernetes cluster that gets us our outcomes (containers to run applications to power our feedback loops), while meeting our required standards and providing the observability that the operations team needs for their feedback loop. 

OpenShift’s default configuration is shaped by running in highly regulated environments. Already many choices have been made to satisfy most security-conscious enterprises, but still provide you with plenty of options to add configuration and customizations for various use cases.

Here is an example of where OpenShift can be tuned to meet the PCI standards: Red Hat OpenShift Container Platform for PCI DSS V3.2.1.

Developer swim lanes: Observability of apps in a cluster

OpenShift provides a swim lane for product teams with its application console, API and CLI. Using either option, a development team can access application and infrastructure statuses as well as logs and metrics without having to reach out to support. This shows my swim lane, along with a frictionless outcome (my app running for me in an environment).

As can be seen in the screenshot of the Application Console, I’m able to see logs and metrics on demand (great observability). As a developer, I have all I need to work through an issue or an experiment. Provided the operations team has injected the right opinions, this is all configured in a compliant manner. This means no one is going to suddenly appear and take this tool away from the Dev team at a critical moment in the project.

Now for those of you with a keen eye, you may ask, how did this get built and deployed in OpenShift? Where is the pipeline? This of course should also be addressed, but for the purpose of this article we are focusing on getting a usable/compliant run time with little to no friction via OpenShift (our example of an opinionated workflow).

Operating swim lanes: Observability of clusters

Meanwhile, OpenShift gives the operators of the clusters a means to update the cluster with minimal or not noticeable downtime for developers running workload on it.

This means operators can make necessary security changes to running environments with minimal effect on developer momentum.

Should an enterprise decide to move certain workloads to the public cloud, a cluster in that environment will provide the same Console, API or CLI for the teams (swim lanes are maintained). In this case, there might be different customization required because the public cloud has more attack vectors, but once applied the clusters can be created and maintained in the public cloud in the same way as in the private datacenter.

Selecting an opinionated workflow for software projects

How does one go about choosing a product that provides opinionated workflows? Here are a few ideas.

Should have a visible community working on the product

If an enterprise depends on a product that provides an opinionated workflow and has spent the time to integrate it into their environment, the company providing the opinionated workflow starts to become very important. If this company dramatically increases their prices, deprecates the product, or goes out of business, it can be a problem for their enterprise customers. So, selecting an opinionated workflow that is open source and has an active community can be an advantage. At the very least, if the project becomes active and is open source, an enterprise can build a team to continue improving and enhancing the product for their use.

What’s nice about an open source community is that the level of activity (present and historic) is visible. Including the feature request and bugs users are finding. With closed source, a company might be struggling to maintain the product prior to deprecating it. This struggle would not be visible to a client looking to adopt the product.

Has a healthy learning and implementation community

The product providing the opinionated workflow should have support to enable enterprise users to succeed with it. The company that makes the opinionated workflow should have good training, samples and tutorials.

Again, using OpenShift as an example, a quick search on Amazon brings up many options—you can already see the book I chose to start my OpenShift journey. On Udemy, a similar assortment of options can be found. This means, as a developer, if you get stuck, there are options to learn.

Supports swim lanes for developers and operators

As discussed, it’s key that the opinionated workflows enable tools or APIs allowing teams across silos to work independently of each other. This can mean providing a console for developers to get logs on demand (like in the OpenShift example above) or providing technology options that can be run locally for developers. Often, a developer just wants to kick the tires a bit on something. That is a good thing and should be encouraged. But some ops teams will shut this down by wanting to know why a developer wants something and forcing them to get approvals to obtain it.

Red Hat provides something called Code Ready Containers (CRC).

This is like OpenShift lite for developers to play with on their own machines.

It’s perfect for developers to learn some fundamental concepts that will help them be more proficient without having to run the infrastructure-provisioning gauntlet. Also, unlike experimenting in the public cloud, it will not cost the enterprise anything for developers to run.

Why not build your own?

Build vs. Buy is a constant discussion within enterprises. Ideally, if done with the right people, building can be the perfect solution. But the challenge lies more in what happens after it is built; this is where the wheels usually fall off.

• Will the enterprise invest in this custom product long term?
  • Often people are more keen to build than they are maintain, there needs to be an investment in both
• Is there a plan to deal with attrition of talent who have knowledge of the custom product?
• Can the operations team provide production support for the custom product and/or the opinionated workflows it produces?

There is another factor to consider as well. There are security challenges and issues that can only be discovered in a product when it runs at scale. Continuing with the OpenShift example, the platform has been running at scale in enterprises for some time. Lots of issues have been discovered and fixed. When you build something in your own environment, be prepared for those issues to surface that can only be discovered at scale. Some of them might be challenging to fix once users are on your product.

In going down this route, an enterprise needs to accept these challenges and agree to fund the efforts around them for multiple years. This is not a small task and will require a serious, long-term commitment (and money). But if done right, it can not only provide a great solution but build something the enterprise can be proud of. But this journey is not for every enterprise. Many will struggle to maintain the necessary talent over time. 

Adopting something new

What about something that meets the needs of the project, but is brand new, meaning it does not have the production use cases and community that something more established has? This can be risky. However, if this new project/tool provides some unique capabilities, it could give a huge advantage to the modernization effort. Also, if the team building the project is willing to collaborate, perhaps to get those early production use cases, your project might find itself with some unexpected engineering horsepower.

This decision comes down to stakeholders of both the application and operations team to determine if they are comfortable with the potential risks. Sometimes enterprises can have some difficult barriers for getting new tools into production. But again, someone has to go first (even Kubernetes had a first customer at some point). Is yours the culture to do something like this? Only your team; Wise Sage, Technical Lead, representatives from operations and your business sponsor can make this decision.

Will everyone like using the outcome from an opinionated workflow?

Up to now, I’ve focused on the benefits of opinionated workflows from the perspective of overcoming enterprise challenges. However, what about the users who will interact with the opinionated results of an opinionated workflow?

It’s been my experience that a percentage of developers in any given enterprise environment will outright reject an opinionated outcome provided by an opinionated workflow. The size of that percentage depends on the enterprise.

Reasons for this rejection might be

1. having a desire to personally make the opinions that lead to outcomes,
2. being knowledgeable as to how all aspects of the workflow works and not liking an outcome being produced without their involvement, or
3. wanting to be the team to build such a solution. In this case the previous comments on Build vs Buy or adopting a new technology might be relevant. But there has to be an intention to take this to a production. It can’t just be a learning experiment

If an enterprise has too many of these people that fall into one of more of these options, the opinionated workflow tool/platform will fail.

That said, given the challenges established previously (specifically around attrition and usage of third-party vendors), a percentage of people in the enterprise environment will just want to do a job and go home. Perhaps these resources are only there for three to four months. They might not care or have the time to learn about how to make the right choices around security or compliance or learn a new CI/CD tool. In a situation like this, an opinionated workflow that provides frictionless outcomes is ideal.

In conclusion

When chosen correctly, an opinionated workflow can greatly benefit an enterprise environment by helping resources that are not inclined or in a position to make all the required choices to immediately use the technology they need.

In terms of a modernization project it can be highly effective in producing the required outcomes, and speeding up the required transformative changes, with less chance of getting entangled in processes unique to the enterprise, provided the opinionated workflow supports custom configurations.

Of course, even after you have selected the ideal team, put your plans in place, engaged an appropriate strategy, and implemented an opinionated workflow, in enterprises there are sometimes factors outside of your control that can still lead to project problems, which is the subject of my next article.