Containers are executable units of software that package application code along with its libraries and dependencies. This package is then able to run in any computing environment, whether it be desktop, traditional IT, or cloud infrastructure.

When running, containers take advantage of “operating system virtualization” that separates resources (CPUs, memory, etc) to run the package in isolation.

Overall, containers are a lightweight approach to developing and testing applications, allowing users to have a quickly available and consistent environment, ready for them at any time, regardless of their location.

Based on market and sponsor user research, we identified that containerizing their applications and environments to accelerate development and testing is a prime opportunity area for this work.

They identified the importance of being able to treat code in a more modular way, making it easier for application code maintenance and quick development across large teams. This approach allows teams to avoid the usual bottlenecks of skills and knowledge spread across different roles and knowledge bases.

With this, we identified that helping these large organizations by creating z/OS-specific tooling would enable them to take advantage of the benefits of modern development practices that newer, and thus less z/OS-skilled, developers would be familiar with.

… containers can fundamentally alter how enterprises operate and deliver value to their customers

Tech Bytes for Business Leaders: Containers, August 2021

I joined the z/OS Containers design team at a time when the product was almost ready to be released to the market. Before it’s released, there was a need to ensure this new experience for z/OS and mainframe developers was informed directly by them, and to mitigate any risks that could arise if the solution didn’t align with a significant portion of our intended market. There was a request to conduct a beta with potential z/OS Containers customers.

Before releasing the z/OS Containers product, we needed to: 1) make sure the product was responsive to the needs of z/OS and mainframe developers, and 2) confirm that our solutions aligned with a significant portion of our intended market. Based on this, I planned and facilitated a beta with potential z/OS Containers customers.

As the representative of the design team on this effort, I collaborated with the business teams, client representatives, and the broader design community to ensure that we identified sponsor users who would be a good fit and had the time available to participate.

In planning and preparing for the beta, I created a research plan that I validated with the development and business teams to ensure we were working towards a clear and shared goal for feedback from sponsor users.

To track our research, I implemented a weekly readout to our cross-functional partners. These readouts ensured that sponsor user feedback reached the correct audiences, and created a designated space to record further notes and findings.

Below is the initial timeline I planned for the beta experience. However, during the initial sponsor user check-ins, there were some major technical issues with the provided images and drivers for setting up and using the product.

To ensure proper completion of the beta experience, we had to fix these issues mid-beta. With the added complication of new sponsor user participants wanting to join the beta alongside the initial cohort, we were off our initial planned schedule. I coordinated adjustments to the timeline to accommodate these changes. With this new schedule, we were able to get deeper feedback across all of our beta scope while maintaining a strong momentum to completion.

The findings from the beta provided key insights that helped the product move forward, as well as identified future user engagement research to explore after the general release of the newly named z/OS Containers Platform.

Along with these insights, the design team was also able to uncover technical issues that we addressed during the beta experience. These technical issues ranged from container build errors and script errors to new client needs for obtaining images and running them smoothly on their own systems. As we wrapped up the beta experience, we walked away with a strong sense of how this product aligned with the potential market. We successfully moved z/OS Containers to a general release.