IBM Rational DevOps for Government Part 1 of 4: Why Governments Should Pay Attention to DevOps. Today is the first in a series of short

Transcription

1 Today is the first in a series of short recordings from IBM made especially for government on the topic of DevOps. Today's recording is entitled, Why Governments Should. We're lucky to have Paul Bahrs with us. Paul is Chief Architect for Emerging Technologies in our Lab Services Team. Paul is a thought leader in modern software, delivery processes and technologies. He leads the development of best practices and adoption strategies for clients across industries and worldwide. He has over 30 years of technical experience and leadership in software and systems delivery, application lifecycle management and DevOps. Paul is an active participant in the IBM Architecture Board initiatives and a patent author. Paul has a B.S. and an M.A. in mathematics from the University of Florida and has participated in international open and government standards organizations. I asked Paul to talk about DevOps specifically in the context of government industry due to his extensive work with government clients. My name is Laurel Dickson-Bull. I am offering manager for IBM Rational's public sector. Paul, thanks for participating in this series of podcasts. Many of our listeners know about DevOps already, but just to -1-

2 level set, would you please summarize the meaning of DevOps as IBM defines it? Thank you for the introduction, Laurel. I'll tell you that DevOps is an exciting topic in the software delivery industry today, including the government sector. From IBM's approach, we see DevOps as an enterprise capability for continuous software delivery, enabling organizations to seize market opportunities and reduce the time to get customer feedback. This capability unites people, practices and technologies and the information across your organization that supports software delivery process. For government, this means applying the DevOps approach, associated best practices, agencies and departments can now respond faster and with higher quality to citizen expectations. So, where does DevOps fit in with the Agile, with agile development? And for those of us familiar with SAFe agile development, where does DevOps fit in? Good question, Laurel. One way to think about DevOps, it's as the right practices from the existing competencies, like agile and lean, applied to meet business goals that I noted before. DevOps takes the best practices from agile, like the notion that to produce higher quality -2-

3 software you have to react quickly to changing requirements and deliver only what is needed in order to increase quality and reduce risk. That's a big part of DevOps. And so are lean principles. The idea of reducing excess work and rework and consequently saving time and cost through collaboration and reducing activities that are wasteful. That's also a part of DevOps. SAFe -- or, the Scaled Agile Framework -- is agile for the enterprise. These ideas fold nicely into DevOps and allow our clients to be at once agile and frugal. Oh, I think we can coin a new term here, frugile. I like that, Laurel. Although probably a better way to phrase it is frugal DevOps because moving to automation and better practices for software and systems delivery is good, but doing it with a frugal approach is the way to really save time and cost with software and systems. And then when you mature, your ability to employ analytics in this process of software and system delivery you can become very predictable. And only then will government agencies have the bandwidth to start innovating, transforming and making the strides in technology and service delivery where we all want from our governments. -3-

4 So, now let's go back to DevOps. A DevOps practice for software and system delivery is, above all, collaborative from the way business decisions are made, how contracts get written, collaboration across agencies and inventors and system integrators. We know that the government ecosystem is complex. It's composed of vendors, system integrators, contract agreements, regulations; and on top of these, are schedule, budget and resource constraints. The more collaboration we have among the various contributors within a project or program, the more correct the outcome will be. With DevOps, for example, we don't want to wait for the vendor to deliver files or an executable at the end of a 12-month period after requirements were set 18 months ago. That's a surefire way to get the wrong solution. Instead, through a DevOps approach, collaboration with vendors starts at the beginning of strategic planning, goes through requirements definition and contract phases and continues through the building and testing phases of the vendor deliverable. Paul, I'm glad we started this conversation. In my role as worldwide offering manager for -4-

5 the public sector, I have a unique vantage point to see how IBM has helped clients in governments all over the world. Now, here are a few examples. The first one is from Russia, a government analytics agency in Moscow increased its design efficiency by up to 40 percent, reduced project complexity and improved overall operating management when it implemented a comprehensive asset management and project lifecycle management solution. The next example is a railroad technology company in Beijing, and they were able to enhance employee efficiency, increase product quality and visibility and they also improved the resource use and reduced project costs when they implemented an IBM software solution to support product research and development. A country government...i'm sorry, a county government in Minneapolis here in the United States, increased productivity, improved collaboration and accelerated development times, thereby reducing time to market when it implemented a comprehensive IBM solution. Laurel, these are some good examples of where IBM has helped with various entry points for continuous software delivery or what we call DevOps. The next time we talk, I'll discuss some U.S. government examples that I've -5-

6 run across recently in my experiences with customers and go into more detail about the value of DevOps for these folks. Great, that sounds great. Thank you, Paul. This is the first in a series of podcasts produced by IBM Rational Software for Government. Watch for the second recording, U.S. Government Clients Who Have Adopted DevOps. [END OF SEGMENT] -6-