Make DevOps a Reality at Your Agency

Make DevOps a Reality at Your Agency

Make DevOps a Reality at Your Agency

1

Contents Why DevOps? 4 What Makes DevOps Happen? 5 Technical Solutions to Cultural Challenges in DevOps 7 Culture 8 Defining the Importance of Devops to Government 11 Engraining DevOps in North Carolina 12 Overcoming Barriers to DevOps Adoption and Deployment 15 Automation 16 Leveraging Microservices & Containers for DevOps 19 Measuring 20 Enabling Constant Evolution in DevOps 23 18F Answers Your DevOps Questions 24 Delivering Better Digital Services with DevOps 27 Sharing 28 What’s Next for DevOps? 30 About & Acknowledgments 31

Executive Summary Agencies are embracing digital channels to better engage their audiences, increase their reach, become more transparent and even improve efficiency. As a result, daily operations and IT teams are more closely tied to developers and the production cycles they leverage.

That process of collaboration and coordination, when executed effectively, is called DevOps. But it’s a process that’s easier said than done. As we explain in this guide, there are common misconceptions about what DevOps is, why we need it and what it looks like. There are also debates about what you need to accomplish DevOps goals. Can you acquire a collaboration tool and call it done?

In this guide we argue that, more than simply using an office communication platform to maintain constant contact, DevOps involves a shift in culture to embrace collaboration and risk. It also requires automating processes, measuring results and sharing best practices across departments and even agencies.

This guide will explore the culture, automation, measuring and sharing (CAMS) model of DevOps, explaining what tools, technologies and processes agencies will need to streamline and maximize their digital product development cycles. We’ll also answer some of your most pressing questions and counter common misconceptions about the role of DevOps in government.

DevOps is the future of the private and public sectors.

This guide will help you step into that future.

Make DevOps a Reality at Your Agency

3

Why DevOps? More than 25 percent of global companies employed DevOps as a strategy by 2016, according to Gartner.

Now, more government agencies are also starting to adopt the practice.

Why? Because there are real problems in traditional application development processes that DevOps can fix. As government increasingly relies on digital services and technology to meet citizen demands, this fix is becoming critical to ongoing operations.

The Handoff Problem In any organization that creates its own technology applications or software, there are two broad teams that complete that task: developers and operations staff.

Traditionally, these teams follow a linear development process. Developers create code for the service, based on broad parameters provided by agency leaders. Once the developers build the product, they send it to the operations team to deploy and manage. That’s the IT staff who manage distribution and daily maintenance of your digital services.

This handoff is often referred to as “tossing it over the wall” because operations and development staff pass the product off without truly understanding how each team is using the application. It’s like there is a wall between them that prevents transparency or real communication.

That wall creates all sorts of problems. Because developers don’t have a clear view of how operations will use the service, the product they create often doesn’t stand the test of real-world deployment.

The new service can disrupt existing workflows, overload or damage current IT systems, compromise security or even fail regulatory requirements because developers didn’t have enough information during development.

In some instances, operations teams create workarounds to use the service. More often, they have to toss it back over the wall so that developers can fix bugs, increase security or alter other features.

When errors are significant, this reversal can be especially disruptive to other coding projects, as developers focus on immediate fixes to the already deployed service. On the other side of the wall, operations personnel are left waiting for their needed applications to be improved and redeployed. Both sides lose time and resources while the product is tossed back and forth. End users suffer too, because they have to wait longer to access a completed online government service.

The DevOps Solution DevOps is a project management methodology that solves the problematic product handoff between developers and operations staff.

Instead of operating in silos, both teams collaborate on a project from start to finish. They’re using the same platforms, speaking the same

DevOps is the melding of developers and operations staff operationally, culturally and technically. In addition to fostering collaboration, it can significantly improve agency processes with benefits like: QUICKER DEVELOPMENT. Because developers and operations teams don’t have to waste time throwing code back and forth over the metaphorical wall, they can release iterations of their product sooner.

And when they need to make changes or improvements to those applications, they can do so faster because both teams have a shared understanding of the project’s functions and goals.

GREATER QUALITY ASSURANCE. Even as workers deliver more services faster, they don’t have to sacrifice quality, thanks to two distinct attributes.

First, DevOps allows both teams to see the full scope of a project. That means they have a better understanding of how any single change — say, a change in a line of code or an update to a hosting platform — will affect the rest of the application. In traditional development processes, one change could derail an entire project. That’s far less likely because of DevOps’ collaborative workflow.

Second, automation replaces many human processes within DevOps. We’ll dive into that in greater detail later in this guide. But for now, know that DevOps reduces human error by automating many core development and deployment functions.

BETTER END PRODUCTS. When they use DevOps, developers and operations workers gain a better understanding of the product they’re working on. Developers get to know the real-world conditions in which their code will operate. Operations teams learn what makes their services tick and why they were built that way. Together, both teams can make better decisions about how to build and deploy services, and that results in a better product overall.

HAPPIER END USERS. Ultimately, DevOps helps government agencies better serve citizens in the Digital Age. As users increasingly expect government resources to be provided with the same mobility, agility and utility as private sector services, agencies seek ways to quickly meet those demands. When they turn to DevOps, they’re able to deliver those services and meet citizen expectations.

language and sharing everything in real time.

A GovLoop Guide

4

What Makes DevOps Happen?

There are a wide variety of approaches to engraining DevOps into an organization’s process and culture, but common misconceptions about the process can hinder progress.

According to Adrian Webb, a strategist at the General Services Administration’s 18F, the three most common misunderstandings his team hears when teaching agencies about DevOps are:

DevOps is all about automation & tooling.

You can hire DevOps into your organization.

When an organization thinks DevOps can be solved purely through the purchase and application of technology they end up wasting time and money because the people on the teams are not set up for success in implementing a DevOps driven culture. The automated delivery systems in these organizations, if they are able to integrate them, are not as robust and reliable as systems built by organizations who focused on how teams work together first. DevOps is meant to solve a people problem.

Many organizations see DevOps in the media and think, “we need that because it does great things.” Then, they go looking to create DevOps teams or positions.

While teams and employees can serve as effective DevOps catalysts, DevOps is focused on the holistic system, not about a team or individual. If the process is centralized, the buy-in and shared ownership from the other teams needing to participate will not be there, and attempts to build a lasting DevOps culture will fizzle. DevOps needs support from agency leadership and employees, not a

DevOps can be implemented by a single functional team.

Unfortunately, an eager engineering or operations team alone are not going to be able to effectively implement or spread DevOps in their organization, because they will most likely have resistance from other teams they work with, as DevOps requires a time, learning, and cultural commitment. Only when we include all of the teams involved in delivering quality software and services can we hope to truly make a lasting impact through DevOps practices in our organization.

DevOps is everyone’s business.

permanent consultant or special team.

As Webb explained, the designation of DevOps is flexible, meaning that different organizations can adopt different parts of the process to match their mission needs. Nevertheless, there are industry standards for what is essential to DevOps. The most common standard is CAMS. CAMS stands for culture, automation, measurement and sharing. In 2010, two DevOps industry leaders, John Willis and Damon Edwards, defined these principles as the core tenets to any DevOps process. Since then, other theorists have occasionally expanded the list, so you may see other acronyms like CALMS (adding “lean” to the mix). However, CAMS is generally agreed upon as the core to any DevOps strategy.

In the remainder of this guide, we’ll explain how each of these components plays a part in improving digital application delivery. We’ll also answer commonly asked questions about each tenet.

Culture Automation Measuring Sharing

Make DevOps a Reality at Your Agency

5

DEVELOP. TEST. DEPLOY. REPEAT. netapp.com/solidfire

NetApp Distribution Partner

©2017 NetApp, Inc. All Rights Reserved. NETAPP, the NETAPP logo, and the marks listed at http://www.netapp.com/TM are trademarks of NetApp, Inc. Other company and product names may be trademarks of their respective owners.

A GovLoop Guide

6

INDUSTRY SPOTLIGHT

Technical Solutions to Cultural Challenges in DevOps An interview with Rob Gordon, NetApp Federal Chief Technology Officer for SolidFire DevOps can help agencies achieve real results in terms of efficiency, speed and product quality. However, reaping those rewards isn’t always a clear or easy task for departments new to the agile workflow of DevOps. Many teams are unsure which technologies they require to implement iterative development processes. Others worry that the tools they need won’t integrate with the legacy systems that plague government organizations.

But in a recent interview with Rob Gordon, Federal CTO of NetApp, SolidFire, we learned that technology isn’t the true inhibitor to DevOps. NetApp provides data and cloud storage solutions for government innovators.

Specifically, a scalable, integration-ready and automated solution like SolidFire can be a critical tool to overcome the more peoplefocused challenges of a new process.

“The challenge with DevOps is more often cultural than technical,” Gordon explained.

“There are turf wars between IT and Dev teams. Much of the infrastructure is considered ‘sacred equipment’ and, as a result, departments are afraid of losing control over the infrastructure. There’s also the idea that knowledge is power, and if you share this knowledge, then your worth to the company lessens. Unfortunately, this mindset hinders any advancement towards DevOps.” On top of territorial concerns, many new DevOps adoptees worry about the risk to budgets and workflows that a different process can bring. To confront those cultural aversions, Gordon suggested starting with a core group of champions who can help normalize and standardize the DevOps process within an agency. That approach is a stark contrast to many of the “edicts passed down from high-ups” that he said he often sees in government agencies.

“You have to start with a small project and a small team,” Gordon said. “You can’t boil the ocean at once. You need to identify nextgeneration leaders within your agency who are determined to make DevOps happen.”

That iterative approach to DevOps can mitigate many of the cultural concerns to adoption, but only if it is enabled with the right technologies that are scalable, integration-ready and automated.

For agencies to follow an incremental approach to DevOps, they’ll need technologies that can not only meet the needs of small teams, but also scale as new projects are added to the DevOps process. This scalability cuts costs and risk for agencies, because they don’t have to substantially invest in DevOps workflows up front. Instead, they can start small to learn what is and isn’t working. Once the process is fine-tuned and lessons are learned, agencies can quickly scale their technologies as user workloads, data storage and computing needs accrue.

When DevOps gets off the ground in one department, agencies may want to transfer that process – and the tools that support it – to new departments that operate in different IT systems. For that reason, agencies also want technologies that can easily integrate with other tools and systems – even the ones that are outdated.

“At the end of the day, whenever you look at any DevOps solution, you need to look at the entire suite of tools and the infrastructure it operates within,” Gordon said. Look for a solution that can easily overlay onto existing infrastructures – no matter what they look like – so that the DevOps tools don’t disrupt existing workflows unnecessarily. That way,

Make DevOps a Reality at Your Agency

7

new users are more likely to incorporate DevOps into their processes, rather than reject it as an incompatible tool.

To that same end, you’ll want to find solutions that automate as much of the scaling and integration as possible. Things like workload management, storage allocation and data reduction shouldn’t fall to IT administrators or other personnel as DevOps expands in your organization. “Those types of myopic details that we worry about with traditional architectures have to disappear or you won’t be successful in scaling DevOps,” Gordon said.

Without automation, developers and IT staff couldn’t focus on constant code deployment – the ultimate goal of DevOps. Instead, they’d be bogged down in manual, time-consuming administrative tasks. If the technology doesn’t foster a culture of productivity, it simply won’t be adopted, Gordon explained.

Ultimately, the barriers to DevOps adoption are cultural. However, many of the obstacles to new processes – things like risk aversion, legacy silos and workflow disruption – can be overcome with the right tools. That’s why many agencies are adopting solutions like NetApp’s SolidFire.

SolidFire provides scale-out infrastructures, self-healing high availability, guaranteed quality of service, and in-line data reduction architected for the Next Generation Data Center. Plus, the SolidFire deployment consists of a single system, contains no management silos, and is designed to automate the most time-consuming administrative tasks. Those attributes – scalability, integration and automation – are exactly what agencies will need to overcome the barriers to DevOps and truly succeed.

CAMS

Culture At its heart, DevOps is all about culture – but not the one we most often associate with government. This iterative process involves significant collaboration and information sharing across departments and technologies.

That means the technical, regulatory and – you guessed it – cultural silos of government must be significantly reduced for DevOps to work.

A DevOps culture is collaborative, where employees across departments are in constant communication and trust one another to share ideas, problems and solutions. It also embraces rapid change. Whether it’s a line of code that needs to be switched or an entire product that needs to be rethought, DevOps personnel have to be ready to quickly change course without losing sight of their ultimate objectives.

This culture of rapid but stable change should be embedded in the structure of your agency.

A DevOps organization is often managed by very few people at the top of the organizational chart, allowing for more horizontal information sharing and decision-making. It also grants more leeway for lower-level, non-acquisition personnel to scope and re-scope projects as new needs arise. But ensuring these rapid developments and decisions don’t derail teams requires better coordinating or even structurally reorganizing teams to make sure they are effectively collaborating.

A GovLoop Guide

8

If DevOps is a good idea, what would prevent people from embracing it?

Although DevOps can produce significant efficiency and quality benefits, don’t be surprised if you run into cultural barriers to adoption. One or all of the following apprehensions may cause employees to resist the process change: ɚɚTERRITORIALISM: Privacy concerns, preferences over data or code formats, and/or discomfort with criticism may make certain people or groups more possessive of their data, processes and tools. Additionally, you can’t discount the prevalence of simple tribalism, especially in teams that aren’t used to working with others. ɚɚAVERSION TO RISK: DevOps minimizes a lot of risk in digital service development and deployment. But with any new process, mistakes and lessons are unavoidable along the way. Riskaverse employees may be reticent to adopt new procedures for that reason, even if the ultimate goal is to increase security. ɚɚDISCOMFORT WITH ITERATIVE DEVELOPMENT: DevOps requires deploying less-than-optimal products in the early stages of development in order to garner feedback and ultimately improve the final product. Many employees, however, may be worried that those early, suboptimal products will reflect poorly on them and their work. ɚɚTECHNICAL DISCOMFORT: While the actual process will largely involve your technical staff, the core tenet of collaboration will extend beyond your programmers and developers. But keep in mind that many people in the federal workforce are not accustomed to new technologies, especially tools that encourage informal, asynchronous and constant communication.

What do you look for in people who fit the DevOps culture?

How do you gain leadership buy-in for DevOps? In government, the biggest hurdles to DevOps implementation will often be preconceived notions about the technology, processes or risks associated with a new process. But champions at the top of your organization are necessary to push the cultural and operational changes that DevOps requires. That means a big step toward building the culture of DevOps starts with dispelling misconceptions about the approach.

Whether employees think DevOps requires expensive tools, less accountability or processes that don’t match government regulations, confront any false ideas that your leaders may have. The measurement and sharing components of DevOps will also help here, but you should start messaging DevOps before you get to the end of a project.

Formal meetings and presentations about DevOps can help educate leaders and employees to some degree. It’s more effective, however, to involve agency leaders in the process whenever possible – inviting them to witness development and deployment or even use the tools your teams rely on for collaboration and development.

Make DevOps a Reality at Your Agency

9

As 18F’s Webb noted, you can’t hire DevOps into your organization. You will occasionally see job postings for a “DevOps engineer,” but those often simply marry the role of developer and operations staff. That’s a difficult position to fill, and it’s probably not worth your effort to seek one person with niche skills across two separate technology fields. Plus, that misses the point of DevOps: collaboration.

Instead, look for people who can fill traditional roles, like front-end developers or IT administrators, who are willing to embrace non-traditional workflows. If candidates already have practice with tactics like Agile development or Scrum, that’s a good sign they’ll be able to work in a DevOps environment. If not, be sure to ask cultural fit questions during interviews to gauge willingness to collaborate, share knowledge and embrace change.

But be careful. You don’t want to fully replace your existing team. Be sure you include current developers and other staff in your DevOps journey, so you don’t lose the institutional knowledge of your technologies and processes.

Modernization to Secure the Mission

Visit us at Booth #461 AFCEA Defensive Cyber Operations Symposium June 13 – 15, 2017

www.unisys.com/federal A GovLoop Guide 10

INDUSTRY SPOTLIGHT

Defining the Importance of DevOps to Government An interview with Peter O’Donoghue, Vice President of Applications Services at Unisys Federal Systems What is DevOps? The question continues to plague both the public and private sectors.

While many technologists have applied their own definitions to DevOps, there’s still significant disagreement over what DevOps really means.

“DevOps presents an opportunity for agencies to transform how IT work get done,” according to Peter O’Donoghue, vice president of Applications Services at Unisys, a leading provider of application development solutions and systems integration services.

“DevOps is in an early adoption phase in government and sometimes it is misunderstood. The true long-term value and what types of benefits are that are yet to be realized,” he said in a recent interview.

As a result, it’s challenging to holistically embrace DevOps thinking at scale when there’s inconsistent agreement on the meaning of the term. “The most important thing for DevOps success is the change in mindset that teams experience when they broaden their perspective from simply working in their own silo to really understanding that they’re connected in one value chain to support the government mission,” O’Donoghue said. “Participating in one value chain, seeing how everyone’s work connects to everyone else’s and committing to removing friction in the process is the basis of DevOps. The vision of DevOps is achieved by teams working collaboratively to continually improve the quality of application releases with clear and increasingly faster feedback loops. Teams using DevOps principles improve application development velocity, security posture and operational performance all at the same time.”

O’Donoghue defines DevOps as “the application of lean thinking across the entire IT value chain.” That practical definition avoids the pitfalls of overly prescriptive approaches that often result in applying a technique or tool that doesn’t fit current agency needs and workflows. At the same time, focusing on the lean thinking of DevOps helps organizations stay mission-focused and thinking holistically.

Organizations are striving to define what DevOps should look like at their specific agency. Unisys provides guidance to help distill that broad definition into a practical DevOps roadmap. Using their DevOps maturation approach, Unisys partners with agencies to baseline their DevOps maturity and culture, and defines an achievable set of projects to incrementally adopt DevOps thinking, methods and automation solutions.

“Any IT practitioner at the frontlines of this government digital revolution knows that the time between someone specifying a requirement and that requirement being manifest in a production system is nonvalue added to the mission of your agency,” O’Donoghue said. “Government acquisition, contract management and governance processes have been organized based on promoting healthy competition, assuring separations of concerns and the use of independent verification to drive quality.“

“As a leader in application development and systems integration, Unisys has mined lessons learned across its portfolio of government and commercial customers to adopt a broad view on what DevOps actually is and how to mature customers’ practices,” O’Donoghue concluded. At the same time, “Our practical maturation approach ensures that we meet each customer where they are on their own journey of DevOps adoption.”

To reduce time between identifying and fulfilling a requirement, agencies should extend their lean thinking beyond the scope of application development across all of their processes to mitigate their specific roadblocks to increased efficiency. Agencies should resist overly specific or tool-oriented definitions of DevOps – which often result in optimizing a single step in the application development process or solving one specific concern in running IT operations. That’s why O’Donoghue said you need this lean-focused yet flexible definition of DevOps – it allows organizations to tailor their approach to best fit their needs. It also recognizes that applying DevOps thinking is not a one-time event; rather it requires a continued focus on improving quality and velocity.

Make DevOps a Reality at Your Agency

11

To realize sustainable benefits, agencies needan approach to DevOps tailored for them that aligns to their culture, processes, policies, technology investments and contracting strategy that facilitates incremental adoption. DevOps is real and can help agencies meet their missions by accelerating development to create better, more secure, more stable and user-friendly technologies for their stakeholders. In order to reap the most reward from DevOps thinking, agencies should partner with seasoned Private sector partners to help them on their adoption journey who can help accelerate a comprehensive transformation in getting IT work done more efficiently and cost effectively.

Engraining DevOps in North Carolina An interview with Billy Hylton, Digital Services Director at State of North Carolina

While we see pockets of innovation in state and local government, the overarching perception of the public sector is one of slow evolvement. In a recent interview, Billy Hylton, Digital Services Director for the state of North Carolina, explained why government has gotten that reputation – and how DevOps can speed up progress.

“Traditionally in enterprise IT and large organizations like a state government, there are a number of controls and testing in place to keep everything secure and meet requirements,” he said. “We cover those controls well but then, at times, we don’t move at a pace to meets the business’s needs.”

In his interview, Hylton shared how DevOps has transformed the way his team manages the digital footprint of North Carolina so they can move more quickly to improve citizen services.

Hylton’s team started their DevOps journey about three years ago, when they began migrating the websites of various agencies to one content management system. Now, DevOps is becoming a standard process for managing the state’s Digital Commons platform, a single portal that allows employees to curate and update more than 30 related government websites.

“DevOps makes sense for us because we’re trying to move fast to meet business needs – that is creating websites, applications, and new functionality quickly and effectively,” he said. “At the same time, there’s an accountability piece that we have to maintain, and

balance with our efficiencies. DevOps helps us reconcile those two things, which are often in tension.”

In addition to fostering collaboration between developers and operations staff, the department has seen significant efficiency benefits from the process. In fact, Hylton said his team is now in a process of continuous development, meaning they are consistently updating and improving the Digital Commons platform, rather than scheduling long, waterfall cycles of code deployments. “That’s crucial for us,” he said. “In our case, we have so many websites on one platform, we have the constant need to do patching, keep the system secure and roll out incremental changes.”

His team is also building out prioritized lists of tasks using a shared task management tool, so that developers constantly have a clear idea of where to allocate resources. Next, the team will focus on building continuous integration capabilities, allowing developers to integrate code into shared repositories several times a day.

However, this goal, as well as the general expansion of DevOps in North Carolina state government, isn’t without its challenges. As Hylton explained, developing a new process within an individual department can be challenging because that department often interacts with, or even reports to, other teams who have separate processes. Enterprise-wide IT change management processes can potentially be in conflict with the fast, iterative pace of DevOps.

A GovLoop Guide

12

“DevOps practices bring our two sides together: the need for agility to meet business needs quickly, while also being mindful of policy, standards of security and legislation.

We couldn’t get to where we are today doing things the traditional way.”

Additionally, when other departments rely on closed technologies, rather than open source tools, Hylton said it can be difficult to integrate DevOps. His team uses Drupal and a Git repository for most of their work, while other parts of North Carolina government use more closed systems. That makes it difficult to share code and development across department boundaries.

That’s why his team has focused on engraining DevOps within its own processes first. Then, it can spread best practices to other departments gradually, as team members learn lessons from DevOps processes internally. “I’m being a little cautious because we’re trying to push the envelope a little bit and innovate,” Hylton said. “But at the same time, we want to be considerate of our colleagues and existing processes in place.”

To acclimate other department users to the DevOps cycle, Hylton’s group hosts weekly coding sessions in the government’s data visualization studio. Personnel from various departments are invited to come and assist developers in executing specific tasks within the Digital Commons platform. These “coding dojos” help spread the ideals of DevOps and involve non-IT professionals in the process.

“DevOps lends itself to ongoing collaboration and a growth of skills to harness the capabilities of others outside of our team,” Hylton said. “There definitely is an ethos that everyone can participate and learn. Not everyone is a hard core programmer, but there are pieces that they can play in the process.”

That’s the ultimate objective for Hylton – applying DevOps when and where it makes sense for his team, rather than trying to push it to the entire government at once. “That’s the advice I would give,” he said. “Don’t focus on what exactly DevOps is or think about the five tools or technologies you need to put in place. It is more about a mindset, and identifying what practices and values from DevOps fit into your business model.”

For Hylton, that means collaborating across teams without pushing the process where it doesn’t make sense from an operational or technical standpoint. Nevertheless, he’s confident that DevOps will grow in practice across North Carolina government.

“DevOps practices bring our two sides together: the need for agility to meet business needs quickly, while also being mindful of policy, standards of security and legislation,” Hylton concluded.

“We couldn’t get to where we are today doing things the traditional way.”

Make DevOps a Reality at Your Agency

13

Propel your agency mission further and faster

Accelerate your mission with HPE’s Application Delivery Management Attain speed and quality at scale with intelligent Application Life Cycle Management and complete Continuous testing solutions for your toughest agency requirements. Transition from react and response to predict and optimize, furthering your mission faster and saving your valuable time and budget. Discover the New. Visit saas.hpe.com/software/alm-octane

A GovLoop Guide

14

INDUSTRY SPOTLIGHT

Overcoming Barriers to DevOps Adoption and Deployment An interview with Ashish Kuthiala, Senior Director of Enterprise DevOps and Agile at HP Enterprise Software As government transitions away from linear application development processes and into the new era of collaborative processes, application development is becoming quicker, cheaper and more efficient. Instead of operating in their traditional silos, developers and operations staff have begun to work together on projects from start to finish.

However, similar to most innovative processes, this DevOps adoption does not come without challenges. In an interview with GovLoop, Ashish Kuthiala, Senior Director of Enterprise DevOps and Agile at HP Enterprise (HPE) Software, discussed these challenges and offered a few ways agencies can overcome them.

Unsurprisingly, one of the biggest challenges agencies face when adopting DevOps is culture. Kuthiala explained that traditionally, organizations are used to the typical manufacturing process in which the app goes from team to team down the line of development.

“With the team-to-team process there is usually a one-way flow, unlike DevOps, which has a lot of feedback loops so everyone on the project knows what is working, what is not working and what is acceptable to the customer,” he said. “You have to change that mindset when you adopt DevOps.” To overcome the challenge of a resistant team, Kuthiala recommended adopting an organization wide continuous improvement approach. He compared the approach to running a marathon – if you train every day for six months, you will get better at it. If you want to continue getting better, however, you can’t sit back and say, “I’m done,” after the marathon. The same logic applies to DevOps – improvement doesn’t happen if you don’t have

an end-to-end strategy that continues after launching an application.

To successfully implement DevOps, it is important to strategically plan what the development process looks like. Once an organization is ready to adopt DevOps, HP Enterprise Software services can help agencies get started by providing professional services and workshops plus open source tools to seamlessly stitch together this development process.

Kuthiala explained that HPE Software’s DevOps end-to-end framework allows organizations to pick and choose where they want to start their DevOps journey and what pieces of DevOps they will leverage to fit their needs.

The first phase of the end-to-end strategy is DevOps continuous assessment. This is where applications and operations initially break down silos, and it lays out how employees will get on the same page about what is being developed. The biggest things to consider here are what is being developed and if there is infrastructure to support it.

Once an agency has a tentative road map for their DevOps journey, they can implement continuous integration and testing, which focuses on automating processes around the code that is being built and all systems that work with that code. Integration is key to successful DevOps and HPE helps facilitate that by creating those integrations to assist with automating and delivering a continuous integration and testing environment through HPE Software’s software services.

The continuous release and deployment phase is where agencies can start building a better feedback loop, allowing agencies

Make DevOps a Reality at Your Agency

15

to put better and more quality code into production faster than before. Continuous operations is the final phase of the continuous pipeline and works to address the integration between operations and applications to ultimately close any remaining gaps after the application is in production.

The continuous framework allows employees to collaborate throughout the development process and deliver new software features to users quickly and efficiently. The pipeline automates the software production line, making the continuous loop that is key to successful DevOps. For example, the moment a developer writes a change in code, continuous deployment automates the integration, testing, deployments in different environments and security checks. “Automation and continuous monitoring allow all of these things to happen the moment code is changed so the application is always production ready,” Kuthiala explained. Through automation, the continuous pipeline approach makes deploying DevOps significantly easier, which can help alleviate cultural resistance to the change in organizations.

Ultimately, adopting DevOps as an alternate project management approach allows agencies to develop, deploy and maintain applications more seamlessly, making internal operations more efficient and effective and allowing agencies to offer the citizens who use these apps a significantly better user experience. “These changes cannot and will not happen overnight,” Kuthiala said. “But with a tolerant culture willing to take risks, agencies across the government can see improvement in their application development processes.”

CAMS

Automation A primary objective of DevOps is to accelerate digital product delivery to the point that you’re almost continuously updating and releasing new code. You can’t do that without automation – the replacement of manual processes with autonomous controls and processes.

Rather than having a developer run through lines of code to check for consistencies, IT systems can continuously do that – syncing updates from across staff and work environments into one testing environment and then running checks on that code.

Remember that DevOps is about increasing speed without sacrificing quality or security.

Automation helps preserve the quality of your products by reducing the potential for human error in processes such as developing, testing and deploying code. It can also automatically scan for vulnerabilities and other errors after deployment.

Automation is the most resource-intensive part of DevOps in that it inherently requires tools and technology to happen. But it also has the potential to provide the greatest benefits. Not only does it safeguard your production cycle, it also allows your developers and operations staff to ignore the turnkey components of the development process so they can focus on highlevel strategy and development.

In addition to reducing the introduction of errors, automation helps improve efficiency.

A GovLoop Guide

16

What tools do you need for automation?

Again, the tools you’ll need depends on what parts of the process you’re automating. The most common tools support continuous integration and delivery, management, or analytics.

But whatever tools you acquire, you’ll want to consider a few key attributes, including:

What should we automate?

To achieve the ultimate goal of any Agile or DevOps process – continuous delivery – you’ll need automated testing. Automated testing allows code to be automatically and constantly checked for bugs, vulnerabilities or integration errors before it goes into a live environment.

You can also automate other processes.

Tech Beacon offers a great list of other contenders for automation, including provisioning of a test environment, gathering deployment metrics, orchestrating the project pipeline and even code deployment.

Overall, you’ll want to look for processes that can be expedited through automation without sacrificing quality or security. In the best use cases, automation will actually improve those attributes.

ɚɚSCALABILITY: DevOps rarely takes root in an entire organization at once.

In most instances, a couple of teams will implement the process, reap the rewards and then start spreading best practices to other groups. You’ll need automation solutions that can quickly scale from a small group of users to an entire organization, without accruing significant costs or requiring IT staff to deploy it. For this reason, many DevOps and collaboration tools are cloud-based. ɚɚADAPTABILITY: Because you’re working with data and code spread across teams, departments and even locations, you’ll need solutions that can quickly integrate with disparate IT solutions and environments. ɚɚACCESSIBILITY: Similarly, you want to make sure your code, whether deployed or in a test environment, is available to anyone who needs to view or use it. That requires a central repository that can collect information from across an enterprise and make it accessible to others. ɚɚSECURITY: Finally, as with any government IT procurement, you must ensure that any solution is secure. In DevOps, this can be tricky because many robust and free tools aren’t made with the public sector use case in mind. Make sure you involve security and procurement personnel in any technology decision, even if the tool itself is free to use.

Make DevOps a Reality at Your Agency

17

Is there a downside to automation?

When people think of the cons to automation, they most often think of job loss. At least when it comes to DevOps, that isn’t really a concern. If anything, automation helps DevOppers do more important work, better. It doesn’t fully replace any role in an organization.

Nevertheless, there are some pitfalls to look out for when you’re automating workflows. First, beware of automating processes that are already flawed. As one expert noted, “Automation is about taking once manual processes and placing technology around them so they’re inherently repeatable. If your processes are bad or flawed, then you’re just making bad processes happen faster.”

Similarly, make sure you’re picking automation tools that fit your processes and needs. With new tools being released every day, it’s easy to get distracted by the latest, flashiest piece of software – especially when it comes at a low price tag. However, if that technology doesn’t match your workflow, you could end up causing more disruption than acceleration to your processes.

Finally, beware of how continuous delivery can impact your end users. Automation should help your developers deploy code faster, but it shouldn’t result in webpages or digital services that are constantly changing in dramatic ways. There is a balance to strike between automation and stability. Let your user needs guide that balance.

A GovLoop Guide

18

INDUSTRY SPOTLIGHT

Leveraging Microservices & Containers for DevOps An interview with Richard Lucente, Middleware and PaaS Solutions Architect at Red Hat

Government knows that DevOps isn’t just about the tools, and that it’s not only limited to developers and operations. At its core, DevOps is a culture of collaboration and communication among parties involved in the creation and delivery of software applications and services. What many agency leaders are now discovering, however, is the correlation between DevOps and tools like microservices and containers.

In an interview with GovLoop, Richard Lucente, Middleware and PaaS Solutions Architect at Red Hat, discussed how government can best harness microservices and containers for their DevOps implementation. Red Hat is a leading provider of open source solutions and DevOps tools and processes.

What exactly do microservices and containers have to do with DevOps? Microservices are small, single-purpose applications that collaborate using application programming interfaces (APIs) to deliver services. Containers are closely allied with microservices and are separate entities that use the same server resources to run applications. Combined together, microservices and containers can allow government to build more complex applications that can better integrate with other applications.

Lucente pointed out that containers and microservices can be helpful in an agency’s DevOp’s journey because they promote small, incremental change as well as minimal differences between development and test environments and the final production environment. For government agencies, deployment to production can be a long, painful process where constrained budgets and public scrutiny make failure anything but an option.

“Deployments tend to be traumatic events involving many folks and long hours to complete,” Lucente said. “Organizations tend to combine many features and capabilities into larger and larger deployments to minimize the frequency that the deployments occur.”

on Red Hat Enterprise Linux to help develop container-based applications quickly. These containers can then be deployed on any Red Hat container host or platform, including Red Hat Enterprise Linux or OpenShift Container Platform 3.

But what microservices do is flip that approach by encouraging smaller and more frequent changes to the production environment. “Microservices provide a way to deploy capabilities behind well-defined and managed interfaces where each service is free to evolve on its own without impacting other services,” Lucente said.

Rather than assembling a container development environment from scratch, Red Hat’s Container Development Kit delivers container tools in a Red Hat Enterprise Linux virtual machine that can be used on familiar enterprises, like Apple macOS, Microsoft Windows or Red Hat Enterprise Linux system.

Additionally, your IT team doesn’t have to worry about configuration, as those details can be handled by Vagrant, an open-source tool for creating and distributing portable, reproducible development environments.

When agencies adopt microservices and containers, they can expect several benefits.

In addition to easier deployment cycles with microservices, containers also offer faster deployments with fewer defects. “Containers enable more strategic focus for IT staff rather than the care of individual and often problematic legacy applications,” Lucente said.

Additionally, containers are efficient in their use of memory and storage since each container is typically a single process within the computing environment. Rather than install and boot an entire operating system, as is the case with virtual machines, containers simply start a process on the host machine.

Because start up and shut down times are so quick, this also leads more readily to selfhealing architectures and rapid provisioning of new capabilities.

Knowing these benefits, how can agencies get started with microservices and containers? A container development toolkit is helpful. Red Hat offers OpenShift Container Platform, a full-stack container development, hosting, management, and orchestration platform. For those looking to get started quickly, Red Hat also provides a pre-built Container Development Kit based

Make DevOps a Reality at Your Agency

19

In addition to such tools, Lucente advised that agencies encourage open discussion as a key component to successful DevOps implementation. “Avoid a culture of fear at all costs,” he added. “Instead of retribution and judgment, encourage innovation.”

From Lucente’s experience, agencies are most successful with DevOps when they are realistic about their goals. He suggested that high-achieving organizations create small, focused teams for a specific achievable goal. Then, build a limited set of applications or services leveraging DevOps and supporting technologies like containers.

Once other groups in the organization see the faster delivery of high-quality features and capabilities, they’ll want to share in that success.

“That’s how adoption grows from a small seed outward,” Lucente concluded.

“These initiatives also enjoy the support of management, so the culture becomes more open and willing to embrace change.”

CAMS

Measuring As with any new process, managers often wonder how they can measure a return on the cultural and technical investment it takes to implement DevOps. But the simple answer is that you can’t really measure DevOps. That begs the question: How is measuring a core tenet of the process? One DevOps leader, Michael Cote, explains: “DevOps is an immeasurable process with respect to ROI, because its value is nearly impossible to measure independently and precisely.”

That’s because there are all sorts of tools, processes and people involved in DevOps, and each of those components is likely impacted by non-DevOps factors throughout the lifecycle of

projects. In government, for instance, changes in regulations, budgets and administration staff are common variables.

Nevertheless, measuring is crucial to DevOps. By measuring the outcomes of your projects, and how efficiently you got there, you can prove the value of the process to others in your organization. Measurements also allow you to course-correct in real time, as metrics negatively change with alterations to your process.

The trick is to make sure you’re measuring the right things, without getting caught up in the DevOps label.

A GovLoop Guide

20

When do you measure success?

The answer to this question might seem obvious. If you’re measuring a project, you want to do it at the end so you have a full picture of what happened, right? Wrong.

What metrics do you track?

How do you measure an ongoing process?

Trick question! You don’t. We mentioned earlier that Cotes and other DevOps practitioners don’t measure the process itself. Instead, they measure the success of individual projects that are executed using DevOps ideals. That still lets you know what’s working with DevOps without having to try to prove the entire concept at once.

This project-by-project approach allows developers and operations staff to compare how different components of DevOps are impacting outcomes. If one project management tool rapidly accelerates a software release while another program is stalled using a separate tool, teams can quickly determine where to change the ingredients of their DevOps recipe.

As one DevOps engineer points out, you can measure more than just numbers to prove the value of the process. There are also cultural and influence outcomes, such as a team attitude of continuous improvement or noticeable knowledge sharing, that can make big impressions on the efficacy of an organization.

But when most people talk about measuring in DevOps, they’re looking for quantifiable increases in efficiency that they use to prove the value of the process to internal stakeholders or citizens. Some common metrics of DevOps success include: ɚɚFrequency of software releases ɚɚVolume of code defects or errors ɚɚResources (time or costs) per product release ɚɚPercentage of failed deployments ɚɚMean Time to Recovery following failed deployments ɚɚVolume of customer or user tickets ɚɚUptime and performance of services Overall, you’ll want to pick metrics that show that your teams are working together to create better products, faster and at less cost to your agency.

Make DevOps a Reality at Your Agency

21

You do want a full view of how DevOps is impacting your process and outcomes, but you can’t do that one time. You have to continuously measure – even before you start DevOps! Measuring the efficacy of pre-DevOps workflows lets you understand where and how new processes can make the biggest impact. It also offers you a baseline to which to compare your progress with new processes in place.

Once you start implementing collaboration, automation and more, continue to measure on a daily basis. As with any new process, you’ll make mistakes. Constant measurement will help you identify those errors and correct them quickly, before they really impact your work.

At the end of your production cycle, you can still execute a product post-mortem.

Those sorts of debriefs are more common in waterfall cycles, but they can still serve a purpose in DevOps. They let you measure (and hopefully celebrate) your success. More importantly, they make sure everyone knows how DevOps is working and how to move forward with the process.

PARTNER AWARDS 2017 Cloud Partner of the Year 2016 Public Sector Partner of the Year 2016 Middleware Solutions Public Sector Provider of the Year 2015 Public Sector Partner of the Year 2014 Cloud Partner of the Year 2013 Public Sector Virtualization of the Year

WWW.DLT.COM/REDHAT

1.800.262.4DLT

INDUSTRY SPOTLIGHT

Enabling Constant Evolution in DevOps An interview with Greg Agana and Rick Stewart, Solutions Sales Professionals at DLT Solutions At its heart, DevOps is a process that involves culture and collaboration. Nevertheless, a robust DevOps process that truly delivers on the promises of continuous development and deployment will also involve technology.

As more government organizations pursue DevOps, IT leaders often find that the technical components of the process are undervalued or ignored. As a result, procedures are put into place to accelerate production and integrate different teams, only to find that the agency’s infrastructure can’t support those new protocols.

To better understand this problem, GovLoop spoke with Solutions Sales Professionals Greg Agana and Rick Stewart at DLT Solutions, a Red Hat reseller that provides agencies with trusted open source technologies. Agana and Stewart also explained how containers within flexible cloud models can help alleviate many of the technical barriers to DevOps. “When you have a rapid, iterative type of development practice, you also put pressure on the IT operations team,” Stewart said.

“They have to keep up with you in terms of providing an adequate environment and resources in order to keep up with a quicker development schedule.”

Agana also noted that for many projects, agencies have to work with multiple entities. “For an application to move from the time it’s developed into its various testing environments, and ultimately out in production, there might be several teams, contractors or companies that touch that application in order to get it in front of the end users,” he said. Those other organizations often operate in different IT environments that make integration of workflows difficult – especially from a technical perspective.

Agencies can’t expect to fully reap the rewards of DevOps without first overcoming the challenge of constant application and service handoffs across diverse IT environments. Thankfully, there is a technical solution to that problem: containers.

Agana explained: “Containers encompass a single application, including all its different binaries, libraries and the dependencies it needs to function. So, you can pick up a container running on Server A and move it to Server B. That application will run exactly as it did on Server A, even if the server operates in a different environment.”

Containers are a critical piece to the puzzle of DevOps technology. However, Stewart went further to explain that agencies need a supporting infrastructure that allows for that deployment, management and orchestration across servers. That’s where cloud computing comes in.

With cloud, IT administrators can spin up the necessary computing power to handle these rapid handoffs without building costly physical infrastructure. They can also allocate computing resources where they’re needed, as they’re needed – following a development cycle rather than remaining static. Plus, cloud environments enable agencies to make the most of their existing infrastructure, even when they access applications developed in alternative IT environments.

Lastly, our experts added a word of caution.

Agana said that more than just making sure you use a scalable cloud model, you have to choose one that is flexible to the evolving needs of an iterative development cycle. “IT administrators can take a misstep in adopting a certain technology from a very specific cloud service provider and inadvertently locking in themselves in the future,” he said.

Make DevOps a Reality at Your Agency

23

Lock-in prevents developers and IT operations staff from evolving as their DevOps processes and applications rapidly innovate. In contrast, an open source technology, like Red Hat’s OpenShift Container Platform, lets IT staff pick and choose their cloud infrastructure components, as they need them. If one application or service no longer supports the workload of their practices, it can be quickly replaced without halting productivity for developers or other staff.

That’s the ultimate goal of DevOps – to enable rapid and constant evolution of applications to meet the ever-changing needs of IT staff and end users. But that can’t happen without technology to power and contain that evolution.

Red Hat and DLT realize that DevOps is about more than collaboration. “DevOps is the practice of aligning your operations people with your developers to ensure that each team has the adequate resources, when they need them, to produce a high-quality product, at the most efficient cost.” Stewart concluded.

Agana agreed: “The philosophy of DevOps is only manifested when you have resources that are consistent over a long period of time.” Those resources are containers that allow applications to continue development across myriad environments. Cloud computing assists that rapid movement by allowing resources to be provisioned across the development cycle.

18F Answers Your DevOps Questions

18F is the innovation shop established in 2014 within the General Services Administration (GSA). To accomplish its mission of building “effective, user-centric digital services focused on the interaction between government and the people and businesses it serves,� the agency adopted DevOps. In a recent interview, Adrian Webb explained how and why the process is being leveraged at 18F.

How did DevOps take root at 18F? DevOps is generally considered a cross-functional community of practice dedicated to building and maintaining effective systems at scale, which has been a driving goal of 18F since we began. We focused heavily on building a collaborative culture, automating as much of the operations process as possible through acquisitions and building our own tools, and dedicated ourselves to many DevOps principles.

We developed a close working relationship with our infrastructure, engineering and design teams that allows us to deliver to our government partners and citizens more efficiently. To ensure we are integrating DevOps in a successful manner, 18F seeks out DevOps talent and many other talented government and private sector practitioners.

DevOps was adopted as a production practice at 18F because it is rooted in sound principles that have been shown to work for large and small organizations. It is also not a one-size-fits-all-model, so we can customize our processes based on the guiding DevOps principles, the most important being systems thinking, iterative feedback loops, and fostering a culture of experimentation.

Have you faced any challenges in using a DevOps production process?

There are many challenges with adopting DevOps practices into organizations. DevOps requires that we look at the organization as a holistic system, eliminating or bridging the silos that often feel like protection. It becomes more important to understand those we have to work with in other teams, to find common ground to build on, and develop a shared language. This is built on cross-team collaboration, which can be difficult when we are used to silos and more functional separation of work.

DevOps builds on both the technical and the cultural aspects of the organizations delivering software. Since there is really no single accepted definition of DevOps, there are many organizations that see DevOps practice as automation and tooling. The DevOps journey often becomes driven by the pursuit of technology, not the original goal of getting teams working together effectively. Organizations need to understand that adopting DevOps requires rethinking not just technology and processes but the culture of the organization.

These principles provide a lens to compare our internal processes to an ideal, allowing us to grow over time in an effective manner to achieve our mission. As a government innovation shop, we value experimentation immensely.

A GovLoop Guide

24

What results have you seen from the use of DevOps at 18F? The most immediate effect DevOps principles have had here at 18F is that they allow us to work more effectively together to deliver the software and services that we and our partners need relatively quickly. We have worked to build cross-functional project teams composed of designers, engineers, product managers, strategists, acquisition professionals and operations folks. This allows us to develop effective channels of communication between the parties working on the project with different perspectives, which helps us catch a lot of potential issues early.

We have focused on building out a portfolio of shared services, such as cloud.gov, login.gov, the Federalist platform, and contributed to the evolution of the Consumer Financial Protection Bureau eRegulations platform. We are also incubating other ideas through an inclusive investment process to validate and develop new services. These automated services allow us to focus on the activities where we can contribute the most value. Our researchers can easily deploy new web sites for partners if needed, because we have focused on compliant and usable tools to make our lives and the lives of our partners easier.

We have been working with some agency partners to spread DevOps principles at various levels of their organization. It ultimately takes time to totally acclimate oneself to the types of change that DevOps requires, but it can be adopted with different strategies, so our partners with willing cross-functional management are beginning the process in an iterative fashion. DevOps fits nicely into our focus on iterative user-centric design and agile delivery practices, so we are teaching our partners the principles by example as we are working with them on our mutual projects. We focus on showing results to our partners in regular cycles, or sprints.

You also hold trainings on DevOps for other agencies to learn the practice. What has been the reception of these trainings?

For agencies that haven’t adopted a DevOps approach, how do you suggest getting started?

DevOps faces some hurdles in government due to regulatory requirements in place, so it’s essential to get buy-in from a CIO or higher, and to have them invest in their teams with the resources to execute. To get started with DevOps, an agency needs to have a heartto-heart with various managers and agree that their objective should be to work effectively together to deliver quality mission-focused software and services quickly. This shared understanding will allow the teams to see themselves as part of a whole, working for the same cause. This is foundationally important when adopting DevOps internally. This will take many discussions with various managers that may not currently work together, but most importantly, are willing to try.

Once agency teams agree on the shared understanding then they should consider working the Three Ways principles and the generally accepted CALMS principles into their high-level strategy. This should be a collaborative exercise so that each team feels ownership of the outcome. DevOps does not require costly technology or reorganization.

It does not require that you hire certain people or adopt certain processes. DevOps is about freedom to deliver, so the objective is to align organizational strategy and tactical execution with the DevOps principles and successfully applied patterns.

To learn more about collaboration across government, the 18F staff curates a mailing list devoted to DevOps topics. Anyone with a .gov or .mil email address can join by emailing listserv@listserv.gsa.gov, the message should have no subject and the body should say “subscribe DevOps-Today (Firstname Lastname).” If you want to subscribe anonymously, send the command “Subscribe DevOps-Today Anonymous” instead.

We have had a few types of trainings we have pursued, such as DevOps trainings and materials on DigitalGov, talks at ACT/IAC, and workshops with groups of managers wanting to work more effectively together at our partner agencies. The reactions to our trainings have been positive, and there seems to be a lot of interest in the topic.

We get a lot of questions about what exactly DevOps is, and how it can be applied in their organization to drive efficiency improvements.

For this reason, automation is a hot topic.

DevOps is a very nebulous subject for many managers, and there is an incredible thirst for knowledge based on hearing the DevOps buzzword associated with innovative companies. Government is learning to put these guiding principles into practice while complying with regulations.

Make DevOps a Reality at Your Agency

25

Application Performance Monitoring for metrics-driven DevOps Master DevOps complexity and accelerate innovation in government by working with Dynatrace to: • Improve service delivery for citizens • Measure performance throughout your development pipeline • Move to the Cloud with confidence

Try the only solution ranked a leader in the Gartner Magic Quadrant for APM for 7 consecutive years and counting! dynatrace.com/trial

AI-powered, full stack, automated.

Monitoring Redefined.

A GovLoop Guide

26

INDUSTRY SPOTLIGHT

Delivering Better Digital Services wth DevOps An interview with Andreas Grabner, DevOps Activist at Dynatrace In an increasingly digital world, agencies must learn how to properly develop and maintain digital services for constituents. However, the silos and communication barriers that divide the government IT workforce can hinder an agency’s ability to develop, implement, monitor and improve digital services. When applied successfully, DevOps best practices can break down these barriers within an agency to facilitate seamless, efficient, and effective digital service delivery.

But it can be difficult to adopt this approach.

While undertaking a DevOps transformation, agencies must change communication cultures, implement unified and automated deployment pipelines, and institute holistic monitoring systems. These steps will solve common issues that government development and operations teams face while creating more useful digital services for constituents.

Andreas Grabner, a DevOps Activist at Dynatrace, an application performance management company, has helped agencies use DevOps best practices and technology to optimize the way their IT teams function.

GovLoop spoke with him to discuss the benefits of scaling DevOps to deliver better software faster in government IT teams.

First, Grabner explained that the key advantage to adopting a DevOps strategy is that it evolves the organizational culture of a digital services team for the better. “DevOps means a cultural change where everyone that participates in the full end-to-end delivery pipeline takes responsibility for their actions,” he said.

Grabner clarified that the ultimate goal in software development is to quickly deliver high-quality software that is useful for constituents. Instituting DevOps practices allows developers, testers, operations, and contractors to collaborate as a team working toward a common goal or outcome.

Grabner has found that one of the best ways to synchronize and track the software development process is by using a unified metrics-driven software delivery pipeline. “By using similar tools, and similar data, government agencies can solve communication issues and break down barriers,” he pointed out. “Having one tool that captures data from the different phases of the software development lifecycle all the way from development to production provides teams with consistent information, full circle, that they can analyze and make better decisions from. Everyone that pushes changes through the delivery pipeline should be confident that these changes benefit the constituents.”

“Common development and deployment platforms help project teams better communicate with each other, and incorporate collective intelligence to master the velocity and complexity of operations as part of the integrated application delivery,” Grabner added.

“We should measure every single step along the way to make better decisions on whether a change we want to push through is good or not. If it is not a good change we can stop it earlier in the pipeline,” he continued. “This practice is called Shift-Left and enables you to find performance, scalability and architectural -related issues early in the pipeline and allow only ‘good builds’ to reach production.”

Once feedback is incorporated, agencies should think through “Shift-Right” metrics to determine if the changes are actually helping end users. The benefits of those metrics include reduced risk, improved reputation and a source of “truth” for DevOps collaboration.

As government agencies build more complex applications to meet mission requirements and take advantage of new architectures such as cloud they need to automate as

Make DevOps a Reality at Your Agency

27

much as possible to keep up. Dynatrace takes a unique approach to DevOps monitoring by automating data collection and analysis and infusing it with known, common coding issues. “During the development process, our platform captures a lot of data, and we have found that if you have all the data, you can actually make better decisions,” Grabner said.

Dynatrace has also found that leveraging artificial intelligence is the only way to enable automation and achieve the development speed required. “Bringing AI into the pipeline enables developers to make better automated decisions on more complex data,” Grabner said.

DevOps is helping agencies deliver better digital services because it is breaking down organizational silos to improve communications, streamline workflows through unified platforms and monitor data for potential issues before it is deployed in applications. These steps are helping agencies develop and maintain better digital service applications for constituents effectively and efficiently. Although some agency leaders may still see DevOps as an obscure concept, using certain practices and platforms can have a real impact on your agency’s operations and ability to carry out its mission.

CAMS

Sharing The final necessary component of DevOps is sharing. It’s really the dominant mechanism that makes the whole process work. Arguably, you could execute DevOps in an organizational vacuum, where only your IT and development teams use the process. But even that requires sharing ideas and code.

Real, extensive sharing in DevOps has both operational and cultural benefits.

For one, it can improve efficiencies by reducing duplication in both services and efforts. That saves money for agencies. It also lets employees focus on important, mission-critical issues rather than wasting time on duplicative work.

At the same time, sharing allows workers to

make better, in-the-moment decisions because everyone has a common understanding of the processes and goals of their shared work.

Sharing is also the best way to get personnel outside your IT operations and software development team involved in DevOps. By sharing processes and outcomes, security, finance and procurement teams can learn from your collaboration-fueled success. They can also start incorporating their valuable perspectives into your products, making them more secure and cost-effective.

A GovLoop Guide

28

What do you share in DevOps? The short answer is everything. The long answer is a list of potential shared components, including: ɚɚCODE: This is the most obvious shared item. You can’t work on the same digital service at the same time if you and your collaborators don’t have a way of sharing the code that comprises your product. But what many people forget is that your project’s code might be able to help others outside your project team.

Keeping in mind regulatory and security restrictions, publish your code on open source spaces like GitHub to help other agencies get started with their digital projects. ɚɚUNDERSTANDING: To effectively collaborate, IT staff and developers must have a mutual understanding of the project’s goals, challenges and the solutions you are willing to deploy.

Of course, because you’re using agile workflows, these attributes may change over time. That’s why it’s critical to set up constant communication channels for teams to use.

How do you share DevOps? Given all the things you’ll share within the DevOps process, it makes sense that you’ll need to use a variety of sharing mechanisms. What those are will largely depend on your agency’s communication preferences and available media, as well as what components you’re trying to relate to which parts of your organization.

No matter what you’re sharing, though, it’s important to use an assortment of modes to reach the largest audience possible.

You’ll want to mix formal methods, like presentations and product demos, with informal tactics to give people a real sense of DevOps and its results. And don’t underestimate methods that allow non-IT and development staff to actually get involved in the process. Tactics like North Carolina’s “coding dojos,” as well as collective ideation or brainstorming sessions, can let non-IT staff contribute to even the technical aspects of DevOps.

ɚɚTOOLS: Communication platforms like Slack or Cisco Jabber are examples of shared tools that DevOps teams will need to make the most of the iterative, collaborative process. Testing environments, code repositories and other shared tools will help teams work asynchronously, from different locations. ɚɚBEST PRACTICES: Just as you get the best final product by continually testing it with other users, you’ll create the best DevOps cycle by constantly sharing your practices with other teams, organizations and sectors. Through sharing, you can understand how your processes affect others, learn from other teams’ best practices and even gain more support or resources.

DOC_COURSE_V1

Make DevOps a Reality at Your Agency

29

Is security a concern when it comes to sharing in government?

As with any government informationsharing project, security and privacy are top concerns in DevOps. In fact, as more valuable information is consolidated into central tools, it’s even more important to make sure that your data and code repositories are secure. So, even as you explore new innovative processes for development, don’t neglect the tried and true best practices of cybersecurity.

Luckily, the process of DevOps can actually make security a little easier to incorporate into your shared solutions. By constantly interacting, communicating and sharing information with your security personnel, they’ll gain a better understanding of what safeguards your teams and processes need. They’ll also be able to quickly react to new vulnerabilities you discover and provide solutions, as long as you keep them involved in your DevOps journey.

What’s Next for DevOps in Government?

DevOps is more than just a buzzword or a passing fad. It will be how agencies ensure that their digital services are agile, useful and ready for the future.

Although it is impossible to predict what technologies or software platforms will emerge in the next decade, adopting DevOps practices will prepare agencies for any innovations by modernizing public sector IT culture, organizations and solutions. The handoff problem, budget constraints, demand from constituents for online services and the need to keep up with the private sector are not problems that will go away on their own. To alleviate or solve these issues, government will need to use DevOps practices because the framework directly targets these challenges in IT development and operations.

The trend of agencies moving to DevOps cultures and organizational structures is only going to continue in 2017 because early adopters have already started to see improvements in their programs and IT systems.

Other agencies are noticing and learning from the transformation processes of these early adopters. This will lead to more government programs, policies and digital services being designed and infused with DevOps practices.

Early successes will further fuel a culture of innovation across government, which will make future innovations easier to implement. We have discussed how DevOps involves changing the culture of an agency to embrace innovation, and this culture change will benefit agencies beyond any one project or administration. Innovation within an agency will be facilitated by an external DevOps community, which will help government solve new challenges that arise from technologies and enhanced business processes.

Other agencies will be drawn to adopt DevOps practices in the future because DevOps will be crucial to the future success and efficiency of agencies. The framework allows government to develop digital solutions quickly and

effectively by eliminating the “handoff problem,” which has hindered government innovation and collaboration for decades. By streamlining workflows and standardizing code, DevOps will also allow agency employees to seamlessly implement and benefit from new cloud solutions and cybersecurity measures.

This means that DevOps will give public servants more bandwidth and resources to perform mission-critical functions. Tightening budgets will continue to be an issue, so agencies will need to find new ways to alleviate these constraints. Instituting DevOps practices will be a prudent way for agencies to reduce development and operating costs because the framework is designed to curtail wasted manpower, time and money.

If agencies save money and resources on their internal processes, it means they can spend more on helping constituents. By breaking down the organizational barriers between development and operations teams, agencies can ensure that, from conception to implementation, digital innovations focus on advancing their agency’s mission and reaching as many constituents as possible.

Constituents are looking for more digital solutions from government that mimic private sector innovations, so instituting DevOps at agencies will continue to be the best way to modernize government digital services and IT development processes.

The future of DevOps is bright because it is too effective and efficient for agencies not to use. It will help government IT professionals alleviate chronic challenges in agencies, such as resistance to innovation, “the handoff problem” and budget constraints, while accentuating positives such as streamlined processes, agile IT systems and increased resources for mission-critical functions.

As more agencies recognize the benefits of DevOps, IT leaders will implement the framework into more internal workflows, and constituents will benefit as a result.

A GovLoop Guide

30

About & Acknowledgments About GovLoop GovLoop’s mission is to “connect government to improve government.” We aim to inspire public-sector professionals by serving as the knowledge network for government. GovLoop connects more than 250,000 members, fostering crossgovernment collaboration, solving common problems and advancing government careers. GovLoop is headquartered in Washington, D.C., with a team of dedicated professionals who share a commitment to connect and improve government.

For more information about this report, please reach out to info@govloop.com. govloop.com | @govloop

Thank You Thank you to Arrow, Carahsoft, DLT Solutions, Dynatrace, HPE, NetApp, RedHat and Unisys for their support of this valuable resource for public sector professionals

Authors Hannah Moss, Senior Editor & Project Manager Francesca El-Attrash, Staff Writer

Designers Kaitlyn Baker, Lead Graphic Designer Tommy Bowen, Lead Interactive Designer

Make DevOps a Reality at Your Agency

31

1152 15th St. NW, Suite 800 Washington, DC 20005 (202) 407-7421 | F: (202) 407-7501 www.govloop.com @govloop

A GovLoop Guide

32