I Just Want To Deliver The Right Solution The First Time (Europe 2021)

Simple right? It should be. Delivering reliable software is an important part of accelerating your digital transformation. Teams often need to get back to the basics of their software development and delivery lifecycle. They do this using insight they can derive from understanding the value flow through their delivery toolchain. With a focus on value stream management and catching security defects early, delivering application reliability depends on automation across both the DevOps and AIOps ecosystem. Join this session to hear stories and insights from simplifying the delivery toolchain by implementing GitLab Ultimate for IBM Cloud Paks and using IBM Automation to collate and orchestrate your deployment into production. This session is presented by IBM.


James Hunter



Vick Kelkar

Director of Alliances, GitLab



Hello, thank you for joining us. My name's James Hunter, and I'm joined by from get lab. We want to talk to you about delivering the right solution. The first time, if you're a developer or project manager you've been working with industry for awhile, it's probably a phrase you've said yourself, or you've certainly heard from your teammates, colleagues, partners are out or the business. I'm looking at this I've worked in industry for, um, uh, over 15 years now, I started off as a, as a coder, um, and moved into architecture work. And what kinds of work on a variety of different different projects ranging from IOT embedded based projects in the military and aerospace environment. Then moving into, um, other types of projects working in the financial sector. I've been working over the last few years with number of fintechs as well, and helping them to do, to develop a rapid, uh, solutions.


And what's particularly interesting across all these different types of projects are what it means by. I want to deliver to the right solution. The first time they have 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. It's getting the culture, right? It's enabling the team to work together collaboratively, um, as well as introducing automation where it is appropriate within the, um, the nega, uh, but in the program. So if we look at some of the highly regulated industries, um, where I'm working, where they can take every action can require manual sign-off before it progresses in those industries, that's absolutely fine. But of course it does take a number of years in order to get to a particular release. And then if we look at the fintechs where they can deliver a solution within a matter of hours, the con the, the variation between the type of projects are completely different, but the principle remains the same.


We wanted to deliver the right solution the first time. Well, the reason for that of course, is we all know that software drives our businesses. If, um, the Tesla is basically, um, an iPad with appeals, right? Um, and if that's the pattern that many organizations are following, then their ability to deliver, uh, to develop and deliver software has a direct impact on their business results. So businesses are demanding lots of things from the it organization. Um, they're asking us to modernize, uh, technology platforms, move on to cloud, uh, break up monolithic architectures into microservices and so on. But what they're really asking for is to reduce the risk, reduce costs and become more agile to the demands of, um, of the business. So that's what they're talking about, whether they're asking us to modernize the technology and the platforms, they're also asking for new capabilities, the business wants to introduce new services, the partnerships, new ways of interacting with the end-users.


So they're asking for new solutions, which they expect the it and software developers, um, to, to deliver there. Also the businesses also utilizing more and more, uh, third party data sources and data services as well. And they're asking the software development and delivery teams to extend existing applications and capability or develop, integrate, um, new solutions with utilizing the third party services and the data stores as well. So they're asking us to develop those integrations, but also maintain them whenever they're being, being changed and updated by our third parties or, or internal sources. And of course, throughout all of this, what's become most prevalent, particularly over the last 18 months, or there's always been a significant lead, important aspects of development is security. And that of compliance security. They're asking us to make sure that the application is that we develop and deliver our secure, that the customer data is secure, that the customer interactions is with is secure.


And of course, the way that the company is perceived is that is one that recognizes and respects the security of its end users. Then there's compliance, compliance works in, um, in, from two different perspectives. There is the compliance for how we develop and deliver software. So being able to track and audit who does, what, what processes were followed, how did we actually develop our software? That's very important. Then there's also the regulatory requirements that comes from a particular industry where the business wants the, uh, the software development and delivery teams to ensure that they can produce the appropriate regulatory requirements that are required from the industry for this particular business as well. So security has to be embedded throughout the entire life cycle of a software development delivery project and their businesses asking us to make sure from a compliance and from a regulatory perspective that we can deliver the right solution the first time.


But we know this is a stretch, right? We know that the it teams are software development and delivery teams are being asked to do so much more. Um, um, then this is, uh, it always seems, seems feasible. There's never enough hours in the day. That's certainly been my experience, some of the challenges that we face and we're certainly hearing about from, um, projects. Um, uh, more recently is some key challenges, lack of collaboration when a software development and delivery team is made up of a number of, uh, teams, um, both outsource partners, systems integrators, internal teams, third parties, and others. Um, as well as multiple tools being across, being used across those multiple development teams, it makes it difficult to ensure smooth collaboration, certainly things like, um, uh, video conferencing and the massively increased use of that over the last, uh, six, 12 months or so has helped to evolve a con uh, a culture where people are integrating and communicating more, which is good.


But when from a data source perspective and the technology perspective, there are still significant challenges around that collaboration, of course. And when we have challenges around collaboration, then that leads to, um, some of the delays that we see and the low quality that can potentially come from, um, delivery of a new solution. So we also have challenges around the quality and security vulnerabilities, but we have multiple teams, multiple tools, multiple data sources being used, ensuring that we have the appropriate privileges to pass and share data. For example, test data or feeding in, uh, updates or requests from an end-user, uh, that may or may not include personal data or medical data or financial data. We need to understand from a delivery perspective, how we're managing, um, all of those aspects within our environment, but also ensuring that we're embedding the assessment of security vulnerabilities throughout our development and delivery life cycle.


These are essential components, which when we have multiple tools, multiple teams, multiple data sources, it becomes extremely difficult to ensure that we're executing that sort of security assessment appropriately every time across our delivery lifecycle. Then we have the challenge around a multi chain dependent dependencies. Now you probably face this yourself. Typically, if you're working with multi, um, uh, multiple, uh, integrations or API or third-party services as well, this is where we end up with a different delivery, a different release from each component. It's being connected into a particular solution, sometimes being provided by multiple providers and service providers and, uh, and the like, so that complexity across the tools that data service sources and, um, uh, data services are also, um, affecting the speed of delivery, which means that the business is expecting these new solutions and these updates and these migrations very quickly, but the, it struggles to implement at the speed, the business expects because of the complex, um, uh, complexity around having multiple tool chains.


And we sometimes refer to this as the tool chain tax, which prevents the optimal delivery of software development and delivery. So we know this is what software development teams want to do. I spend lots of time talking with lots of different teams and having my own teams learn and having been a developer as well. We know that in order to deliver the right solution, the first time we want to produce this very nice infinity symbol type of lifecycle, which we've all seen before. But to be clear, it's not quite a nice, smooth infinity circle. We know that software development teams would have bring in ideas, create the stories, your epics, or your requirements management, um, do some design work, user experience, design, architecture, work, whatever it is that is necessary for the particular project. From there, we're going to be able to develop our code and our integrations, our updates, whatever it needs to do.


And then we deploy that into our test environment. We want to go to standards like environment, uh, fill in any missing components. We can test, um, functionality, integrations, performance, and security as soon as possible, and as frequently as possible through our lifecycle, then based on the results of the level of quality for our solution, we want to release that. We wants to instantiate the, uh, the environment, the live environment that is required to execute our solution or our component of the solution that we want to kick off monitoring automatically. We want to be able to predict when problems are going to happen or identify them when they have happened. We need to do something about it. So then we need to resolve that hopefully automatically through playbooks and things like that, or feed back in through a change management request for, um, some, uh, for an activity for people to go and work on.


And that's what brings us back into that development and delivery life cycle approach. Now all of these assets and all of these activities need to be stored and managed in some sort of configuration management that allows us to have that traceability, auditability, that ability to roll back, should we need to, for any particular, um, uh, version asset or reason within the delivery life cycle, but what we also need is to be able to feed the assets and the activities from across the entire life cycle into a value stream management capability. So we can understand the flow of value, not just the state of the assets and activities throughout the different life cycle. Once we start to create and enable this type of environment is end to end from ideas to resolution of problems, being that back in storing everything in configuration management, feeding to value stream, we're in a position then to ensure that we deliver the right solution the first time, every time.


But there's a challenge for this. And that is the number of tools and the tool chain tax. If you compare it to our mobile phones, we have a lot of apps on our mobile phone, and if we had to have access a different device for each application, we just wouldn't do it, right. It's just not practical. Um, it would be a very difficult to move things around. We'd forget passwords, all that sort of thing. It just wouldn't happen. So there's no reason why we expect our software development teams to do the same, to use a significant number of tools in order to do the job where we can simplify those and bring those all together. So the problem that customers, um, are talking to us about at the moment, um, how do we manage this complexity? How do we ensure we're embedding security throughout thyroid software delivery life cycle, and how do we can connect into the rest of the, the business, through our operations and other components as well.


So to address, um, the complexity around this, there is a simple answer, and that is to simplify. We simplify our infrastructure by moving to cloud and moving the elements of our application and business operations that we can into the cloud. We simplify our business activities by bringing in a business automation and other business services and components that allow us out of the box to support the business better. And we need to simplify the way that we approach software development and delivery and simplify the way that we embed security assessment in security, vulnerability assessment, into that lifecycle. So to support this, um, IBM developed a relationship and a partnership with, um, with get lab as a way to simplify that end to end software development and delivery. I'm delighted to be joined by Vic. Um, so it'd be great if you can say a few words from your perspective about the partnership and our approach together to simplify software development and delivery.


Thanks, James, happy to be part of this conversation. And we are absolutely thrilled to be partnering up with IBM on this offering or get lab alternate for IBM cloud facts. The idea behind this collaboration is to help clients enterprises and organizations on their dev ops journey, right? So we are helping the clients realize the dev ops approach that they are taking today and help them and accelerate their DevOps adoption throughout the organization. So let me talk briefly about get lab ultimate the dev ops platform that is delivered as a single application. Uh, the approach we are taking here is we want to help the clients and enterprises and organizations with their dev ops practices by increasing automation, right? So we want to help the developers be more self-sufficient. We want to help organizations with elaboration approach. And when you talk about software development life cycle, and, you know, delivering, uh, your application, you know, with the right security the first time, you know, what does that take?


You know, what are the, uh, you know, tools you will need, right? So when you talk about software development, life cycle, normally you talk about project management, issue tracking and things of that nature. You talked about source code management. You talk about continuous integration and continuous delivery, but through the get lab ultimate platform for IBM cloud packs, you know, we are also focusing on some of the other aspects of software development life cycle. So we wanted to address some of the security and compliance needs that James touched on in previous slides, right? So we want to help developers be more self-sufficient help them realize where the dependencies are, where the security vulnerabilities may exist as they're building that application early on in the software development life cycle, so that they are able to deliver that application correctly with all the checks and balances the first time around not iterating in production, right?


So that's the idea behind this platform. We are introducing, you know, everything through a single intuitive interface so that the entire organization is able to collaborate together, uh, through that single interface, through that single share data model. So that's what is really going to accelerate the automation and the dev ops adoption in the organization. And the way we are doing that today is by introducing a couple of new capabilities, uh, in the platform itself. So James talked about, you know, heavily regulated industries. So, you know, we do want to focus on introducing workflows that are addressing the shift left, or, you know, dev sec ops concerns in your software development life cycle, early on in the process, so that you're able to address those concerns early, uh, not in production so that, you know, you can deploy to a resilient system, uh, like OpenShift or IBM Z.


Uh, another quick one that I wanted to highlight about the capability in the platform is this real-time feedback. Uh, you know, having a review application for developers allows the organizations and various teams to look at the changes, uh, discuss the changes, collaborate on the changes before they commit those changes, uh, back from the feature branch into the main branch. So it's all about helping developers, uh, collaborate with automation, uh, so that they can take that application to your production environment. And I believe this is where I will kind of back to James to talk about what that will look like.


Thank you bet. Yeah. And that's an important part of that feedback, that collaboration that feeds into connecting the business requirements and business, uh, that we talked about earlier with the development as well, but also it feeds into another very important part I'm going to come onto later, which is the, um, um, the ability for teams to operate at his optimum levels, because it's not just about technology, it's not just about automation and tools, but also how do we engage the teams to make sure that they are, um, included and feel included because that's how we optimize the, um, the output and delivery of the team as well. And that's a very important point that VI raises that feeds into that ability of the team to, um, to, to execute on in an optimum way. But it's also about, um, uh, utilizing augmentation as much as we can as well.


Um, so we want to enable that culture and building that culture with those real time and feedbacks, um, the connection through a single data source that single experience as well, and apply AI and automation as much as we can across, um, across the software development and delivery life cycle and the operations life cycle as well. And that's where it becomes key. For example, when we exit key performance tests against our application in development, we want to be able to use that data in production to make sure that as we're monitoring our live environment, we're comparing against the performance of the tests that we get an idea of what we expected of the application and use that to derive insights and predict problems before they actually occur. And we want to feed back results as well. Um, problems, uh, from operations. We want to feed back into architectural design work as we go later on.


So it's about connecting both the software development and the operations side, applying artificial intelligence. So we can get those insights, get those predictive insights in both development and into operations as well. And this is where we see some of the unique value coming from IBM, where we start connecting in elements of artificial intelligence and operations and, and software development and delivery as well. So effectively what we're trying to achieve in order to deliver the right solution. The first time, this is what the IBM solutions is all about and working with get lab as part of our overall solution, want to improve development and delivery operations, reduce security and compliance risk. And so we can all deliver reliable solution solutions as fast as possible. And this is the essence of what we tried to do within the IBM devils group. Just so you're aware, uh, IBM dev ops has made up of a number of components from the development side.


We support to get that ultimate for IBM power pack, which is that end to end delivery platform. And if you should need to scale from an enterprise perspective, we support that through deploying, um, into legacy and enterprise environments, uh, test automation, server supports, um, the creation, execution analysis, and, uh, insight into quality and then philosophy, which gives us enterprise scalability around, um, governance, regulatory, or reporting and optimization, um, as well. But when we put all those together, I talked earlier about simplification is not just at the development level, but from the infrastructure as we move on to cloud, um, from a business perspective, as we move into things like cloud packs or other services as well, and this is how IBM begins to pull all of these together. So we have a number of cloud packs to support things like operations, security, uh, data and AI integration, um, and a whole host of others.


I've just put four on the slide here. Um, our infrastructure, we simply simplified through, uh, open shift. And as Vic was talking on, I support for a mainframe support and capabilities on the Z as well. And our delivery platform with ultimate IBM power packs, it's in the middle, which allows us to create and develop those integrations. Then you work and you create your solutions and deploy them as fast as possible correctly the first time. And we have a number of six services that support that, but also a point I wanted to touch on, which I think is very, it's very important personally, to me, the number of things that I've worked on for and with over the last couple of decades or so, is it the mental health of developers as well? There's a lot of pressure on the development teams to deliver solutions as fast as possible, and the business expects them to get it right now.


Most diverse software development developers don't want to spend their time doing spreadsheets and PowerPoint, right? They, they enjoy the coding those times when, um, I I'm sure if you're, if anybody, if you've got a code, a background yourself, you've been working on a project, then you look up and you suddenly realize it's half past 11 at night. You think, wow, what happened to lunchtime, right? That feeling that you get, that that's the passion that we have as software developers and the, the, the, the fulfillment that we get, where we're into a project, we feel that we're making a difference, but that's not the case every day for developers. And we need to be aware of that as well. So having the tools and the environment that allows, um, the collaboration of fit was referred to earlier on, um, occur more easily, more frequently. So developers, business, stakeholders, and operations, all feel involved in the success of a project is really important.


We need to be able to understand and monitor the mental health of developers as well, not just developers, but across the whole team, but I'm talking specifically around, uh, the development team, because the success of the project completely depends on how well the team can operate together and they could operate better when there is a simple way to collaborate. There are simple objectives around security and compliance and reporting, and they feel like they're making a difference as well. And from there, they feel like they're, um, they enjoyed developing the solutions. They get that buzz that we've all had, um, where we've been developing code, working in a team and we'll captive environment makes a difference. And they feel that they're actually making a difference, not just having stuff thrown down onto them, and then being told and not delivering fast enough. That's not acceptable for businesses to deliver the right solution the first time. And Phil and I were talking about this a little bit earlier, and Vic, you had a point about, um, the successful successful projects and having good mental health and being able to share that as well as wondered if you wanted to share that, uh, now as well.


Yeah. You know, I think this is something worth highlighting is when you have happy developers, right? You lead to better outcomes, you lead to, um, better productivity and it's, it's not just developers, but it's also the adjacent teams, right? If the security compliance teams feel part of that conversation, I think they are more willing to collaborate with their counterparts in development or QA or, you know, with that team of SRS. So it is extremely important to, you know, look at it from a holistic view and mental health or happiness of the team should also be one of the key performance indicators, in my opinion.


Yeah, I absolutely agree. And that's something that's at the front of our minds as well, where we, from an IBM perspective when we're critiquing technology and solutions to support teams to do that is how can we, uh, ensure the success of business through ensuring what the best mental health and the best optimization of the teams as well. So that's what we wanted to talk to you about today. So we want to thank you for your time is how do we deliver the right solution the first time isn't as a combination of culture, technology tools, automation, AI, and also supporting and monitoring the mental health development team and the other stakeholders that are involved in delivering solution. So we wanted to talk to you about, um, what we refer to 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 plants, I think supported by other components that execute the business, be that test automation, um, execution, uh, AI ops integration, open shift in the mainframes of components around that.


But 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 about this, then there's a link on this page. Um, and we would love to, uh, to, to speak to you, both FIC and myself, and we want to help you help your teams improve the delivery operations, reduce their security and compliance risk, and ultimately deliver the reliable solutions, um, for the first time. Well thank you for your time and think I'd like to thank you for joining us today as well. And if you'd like to reach out to us here, our email addresses, and we hope you enjoy the rest of the conference. Thank you. Thank you.