James Hunter

Hello, thank you for joining us. My name's James Hunter, and I'm joined by Vick Kelkar from GitLab. We want to talk to you about delivering the right solution the first time. If you're a developer, a project manager, or you've been working in this industry for a while, it's probably a phrase you've said yourself, or you've certainly heard from your teammates, colleagues, partners, or throughout the business.

I've worked in the industry for over 15 years now. I started off as a coder and moved into architecture work. I've worked on a variety of projects, ranging from IoT and embedded-based projects in military and aerospace environments, then moving into financial-sector projects. Over the last few years I've worked with a number of fintechs, helping them develop rapid solutions. Across all of those project types, what people mean by, "I want to deliver the right solution the first time," has very different contexts. It's not just about using tools. It's not just about coding faster. It's not just about doing certain aspects in a more automated manner. It covers all sorts of things: getting the culture right, enabling the team to work together collaboratively, and introducing automation where it is appropriate within the program.

In highly regulated industries, every action can require manual sign-off before it progresses. In those industries, that's absolutely fine, but it can take years to get to a particular release. In fintechs, they can deliver a solution within hours. The variation between project types is completely different, but the principle remains the same: we want to deliver the right solution the first time.

The reason for that is that software drives our businesses. If a Tesla is basically an iPad with wheels, and if that's the pattern many organizations are following, then their ability to develop and deliver software has a direct impact on business results. Businesses are demanding a lot from IT organizations. They're asking us to modernize technology platforms, move onto cloud, break up monolith architectures into microservices, and so on. What they're really asking for is to reduce risk, reduce cost, and become more agile to the demands of the business.

They're also asking for new capabilities. The business wants to introduce new services, new partnerships, and new ways of interacting with end users, so they're asking for new solutions that they expect IT and software developers to deliver. The business is also using more third-party data sources and data services, asking software development and delivery teams to extend existing applications and capabilities, or develop and integrate new solutions using third-party services and data stores. Those integrations must also be maintained whenever they are changed and updated by third parties or internal sources.

Throughout all of this, especially over the last 18 months, security and compliance have become even more prevalent. Security means making sure the applications we develop and deliver are secure, customer data is secure, customer interactions are secure, and the company is perceived as recognizing and respecting the security of its end users. Compliance works from two perspectives: compliance for how we develop and deliver software, including tracking and auditing who does what and what processes were followed; and the regulatory requirements of a particular industry. Security has to be embedded throughout the entire software development and delivery lifecycle, and the business is asking us to make sure, from compliance and regulatory perspectives, that we can deliver the right solution the first time.

But we know this is a stretch. IT teams and software development and delivery teams are being asked to do much more than always seems feasible. There are never enough hours in the day. Some key challenges we face, and hear about from projects, start with lack of collaboration. When a software development and delivery team is made up of outsourced partners, systems integrators, internal teams, third parties, and others, and when multiple tools are used across those teams, it is difficult to ensure smooth collaboration. Video conferencing has helped people communicate more over the last six to twelve months, but from a data-source and technology perspective, significant collaboration challenges remain. Those collaboration challenges lead to delays and potentially low quality in delivery.

We also have challenges around quality and security vulnerabilities. With multiple teams, tools, and data sources, we need to ensure appropriate privileges to pass and share data, such as test data or end-user requests that may include personal, medical, or financial data. We need to understand how we are managing those aspects in the environment and ensure we are embedding assessment of security vulnerabilities throughout the development and delivery lifecycle. With multiple tools, teams, and data sources, executing that security assessment appropriately every time becomes extremely difficult.

Then there is the challenge around multichain dependencies. If you're working with multiple integrations, APIs, or third-party services, you may have a different delivery or release from each component connected into a solution, sometimes provided by multiple service providers. That complexity across tools, data sources, and data services affects speed of delivery. The business expects new solutions, updates, and migrations quickly, but IT struggles to implement at the expected speed because of the complexity of multiple toolchains. We sometimes refer to this as the toolchain tax, which prevents optimal software development and delivery.

Software development teams want to produce the familiar infinity-symbol lifecycle, but it is not a smooth infinity circle. Teams want to bring in ideas, create stories, epics, and requirements management, do design work, user experience design, architecture work, or whatever is necessary for the project. From there, they develop code, integrations, and updates, then deploy into the test environment. They want to stand up test environments, fill in missing components, and test functionality, integrations, performance, and security as soon and as frequently as possible. Based on the quality of the solution, they release it, instantiate the live environment required to execute the solution or component, kick off monitoring automatically, predict when problems will happen or identify them when they do happen, resolve them automatically through playbooks where possible, or feed them back through change management for people to work on.

That brings us back into the development and delivery lifecycle. All of those assets and activities need to be stored and managed in configuration management so there is traceability, auditability, and the ability to roll back for any version, asset, or reason within the delivery lifecycle. We also need to feed the assets and activities from across the entire lifecycle into a value stream management capability, so we can understand the flow of value, not just the state of assets and activities. Once we enable this end-to-end environment, from ideas to resolving problems and feeding them back in, with everything stored in configuration management and fed to value stream management, we are in a position to deliver the right solution the first time, every time. But the challenge is the number of tools and the toolchain tax.

If we compare it to mobile phones, we have a lot of apps on one phone. If we had to access a different device for each application, we just wouldn't do it. It would be impractical, hard to move things around, and we'd forget passwords. There is no reason to expect software development teams to use a significant number of tools to do the job when we can simplify and bring them together. Customers are asking how to manage complexity, embed security throughout the software delivery lifecycle, and connect into the rest of the business through operations and other components. The simple answer is to simplify. We simplify infrastructure by moving to cloud and moving the elements of application and business operations that we can into the cloud. We simplify business activities with business automation and services that support the business out of the box. And we need to simplify software development and delivery, and simplify how we embed security assessment and security vulnerability assessment into that lifecycle.

To support this, IBM developed a relationship and partnership with GitLab as a way to simplify end-to-end software development and delivery. I'm delighted to be joined by Vick, who's going to talk a little bit about how GitLab, and specifically GitLab Ultimate for IBM Cloud Paks, supports software delivery teams.

Vick Kelkar

Thank you, James. I'm excited to be part of this session today. My name is Vick Kelkar, director of alliances with GitLab, and I'm here to talk about GitLab Ultimate, the DevOps platform delivered as a single application. The approach we are taking is to help clients, enterprises, and organizations with their DevOps practices by increasing automation. We want to help developers be more self-sufficient and help organizations with their collaboration approach.

When you talk about the software development lifecycle and delivering your application with the right security the first time, what tools do you need? Normally you talk about project management, issue tracking, source code management, and continuous integration and continuous delivery. But through GitLab Ultimate for IBM Cloud Paks, we are also focusing on other aspects of the software development lifecycle. We want to address security and compliance needs that James touched on, help developers be more self-sufficient, and help them realize where dependencies are and where security vulnerabilities may exist as they're building an application early in the lifecycle. Then they can deliver that application correctly, with all the checks and balances, the first time around, not iterating in production.

That's the idea behind the platform. We are introducing everything through a single intuitive interface so the entire organization can collaborate through that single interface and shared data model. That is what will accelerate automation and DevOps adoption in the organization. Today we are introducing new capabilities in the platform itself. James talked about heavily regulated industries, so we want to introduce workflows that address shift-left or DevSecOps concerns early in the lifecycle, so you can address those concerns early, not in production, and deploy to a resilient system like OpenShift or IBM Z.

Another capability is real-time feedback. Having a review application for developers allows organizations and teams to look at changes, discuss them, and collaborate before committing those changes back from the feature branch into the main branch. It's about helping developers collaborate and helping with automation so they can take an application to a production environment. I will hand it back to James to talk about what that will look like.

James Hunter

Thank you, Vick. That feedback and collaboration connects business requirements with development, and also feeds into the ability for a team to operate at its optimum level. It's not just about technology, automation, and tools. It is also about engaging teams to make sure they are included and feel included, because that's how we optimize the output and delivery of the team.

It is also about utilizing augmentation as much as we can. We want to enable and build on that culture with real-time feedback, connection through a single data source and a single experience, and apply AI and automation as much as we can across the software development and delivery lifecycle and the operations lifecycle. For example, when we execute key performance tests against an application in development, we want to use that data in production so, as we monitor the live environment, we compare against the performance test and understand what we expected from the application. We can use that to derive insights and predict problems before they occur. We also want to feed back results and feed operational problems back into architectural design work. It is about connecting software development and operations, applying artificial intelligence to get predictive insights in both development and operations. This is where unique value comes from IBM, connecting artificial intelligence, operations, and software development and delivery.

Effectively, to deliver the right solution the first time, the IBM solution and GitLab partnership are about improving development and delivery operations, reducing security and compliance risk, and delivering reliable solutions as fast as possible. IBM DevOps is made up of several components. From a development side, we support GitLab Ultimate for IBM Cloud Paks, an end-to-end delivery platform. If you need enterprise scale, we support deployment into legacy and enterprise environments. Test Automation Server supports creation, execution, analysis, and insight into quality. Velocity gives enterprise scalability around governance, regulatory reporting, and optimization.

When those are put together with simplification at the development level, infrastructure moving onto cloud, and business services such as Cloud Paks, IBM begins to pull all of these together. Cloud Paks support operations, security, data and AI, integration, and other areas. Infrastructure is simplified through OpenShift and support for mainframe capabilities on IBM Z. The delivery platform, GitLab Ultimate for IBM Cloud Paks, sits in the middle, allowing teams to create integrations, new work, and new solutions, and deploy them as fast as possible, correctly the first time.

I also want to touch on something very important to me personally: the mental health of developers. There is a lot of pressure on development teams to deliver solutions as fast as possible, and the business expects them to get it right. Most software developers don't want to spend their time doing spreadsheets and PowerPoint. They enjoy coding. If you have a coding background, you know the feeling when you're working on a project, look up, and realize it's half past eleven at night and wonder what happened to lunchtime. That feeling is the passion and fulfillment we have as software developers when we're in a project and feel that we're making a difference. But that is not the case every day for developers, and we need to be aware of that.

Having tools and an environment that allow collaboration to occur more easily and frequently, so developers, business stakeholders, and operations all feel involved in the success of a project, is really important. We need to understand and monitor the mental health of developers, and across the whole team. The success of the project depends on how well the team can operate together. They can operate better when there is a simple way to collaborate, simple objectives around security, compliance, and reporting, and they feel like they're making a difference. From there they enjoy developing solutions and get that buzz we've all had when developing code. Working in a more collaborative team environment makes a difference. They feel like they are making a difference, not just having work thrown down onto them and being told they're not delivering fast enough. That's not acceptable for businesses that want to deliver the right solution the first time. Vick and I were talking about successful projects, good mental health, and being able to share that as well. Vick, did you want to share that now?

Vick Kelkar

Yes. This is worth highlighting: when you have happy developers, you lead to better outcomes and better productivity. It's not just developers, but also adjacent teams. If security and compliance teams feel part of the conversation, they are more willing to collaborate with their counterparts in development, QA, or SRE teams. It is extremely important to look at it holistically, and mental health or happiness of the team should also be one of the key performance indicators, in my opinion.

James Hunter

I absolutely agree. That's at the front of our minds from an IBM perspective when we're creating technology and solutions to support teams: how can we ensure business success by ensuring the best mental health and optimization of the teams?

That's what we wanted to talk to you about today: how do we deliver the right solution the first time? It's a combination of culture, technology, tools, automation, AI, and also supporting and monitoring the mental health of the development team and other stakeholders involved in delivering the solution. We refer to this as DevOps innovation and AI-powered automation, bringing these elements together through a simple, single-experience software development and delivery platform through GitLab Ultimate for IBM Cloud Paks, supported by other components that execute the business, such as test automation, AI Ops integrations, OpenShift, and mainframe components. Those become supporting elements that enable software development and delivery teams to deliver the right solution the first time.

If you'd like to learn more, there is a link on this page. We would love to speak to you. We want to help your teams improve delivery operations, reduce security and compliance risk, and ultimately deliver reliable solutions the first time. Thank you for your time, and Vick, thank you for joining us today as well. If you'd like to reach out to us, here are our email addresses, and we hope you enjoy the rest of the conference. Thank you.

Vick Kelkar

Thank you.