DevOps Federal Government: Busting Silos Red Tape
•Download as PPTX, PDF•
1 like•1,061 views
Aaron Volkmann, Senior Software/Research Engineer, Software Engineering Institute All organizations face challenges in changing their culture and adopting DevOps philosophies. This is especially true in many federal government agencies. Through well-intentioned policies and procedures many agencies have created extremely silo’d environments where change is slow and difficult. Finishing the last leg of large scale software development project acquisitions can be particularly challenging and expensive. Barriers often impede getting hardware and software systems system fully tested, transitioned, and up and running in production on schedule. Through our experience as a passionately DevOps focused software development group within Carnegie University’s Software Engineering Institute, a federally funded research and development center, creating, delivering and transitioning cutting edge software solutions to government organizations, we have struggled with and overcame challenges in helping government to adopt DevOps principles. Learn how we have conquered these challenges in shifting our government stakeholders’ thinking by coaching and initiating DevOps in their operational and development environments.
Recommended
More Related Content
Viewers also liked
Viewers also liked (10)
Similar to DevOps Federal Government: Busting Silos Red Tape
Similar to DevOps Federal Government: Busting Silos Red Tape (12)
More from Gene Kim
More from Gene Kim (20)
Recently uploaded
Recently uploaded (20)
DevOps Federal Government: Busting Silos Red Tape
- 1. DevOps in Federal Government © 2015 Carnegie Mellon University Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Busting Silos & Red Tape: DevOps in Federal Government Aaron Volkmann 10/21/2015
- 2. 2 DevOps in Federal Government © 2015 Carnegie Mellon University Copyright 2015 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu. DM-0002918
- 3. 3 DevOps in Federal Government © 2015 Carnegie Mellon University In the beginning…
- 4. 4 DevOps in Federal Government © 2015 Carnegie Mellon University Who Are We?
- 5. 5 DevOps in Federal Government © 2015 Carnegie Mellon University Ready to go!
- 6. 6 DevOps in Federal Government © 2015 Carnegie Mellon University We got stuck
- 7. 7 DevOps in Federal Government © 2015 Carnegie Mellon University Conflict
- 8. 8 DevOps in Federal Government © 2015 Carnegie Mellon University We Took A Step Back to Regroup
- 9. 9 DevOps in Federal Government © 2015 Carnegie Mellon University We worked on workflow
- 10. 10 DevOps in Federal Government © 2015 Carnegie Mellon University Security Bottleneck
- 11. 11 DevOps in Federal Government © 2015 Carnegie Mellon University
- 12. 12 DevOps in Federal Government © 2015 Carnegie Mellon University
- 13. 13 DevOps in Federal Government © 2015 Carnegie Mellon University
- 14. 14 DevOps in Federal Government © 2015 Carnegie Mellon University
- 15. 15 DevOps in Federal Government © 2015 Carnegie Mellon University
- 16. 16 DevOps in Federal Government © 2015 Carnegie Mellon University Experimentation and Learning
- 17. 17 DevOps in Federal Government © 2015 Carnegie Mellon University PCSAM Problem Cause Solution Action Measure
- 18. 18 DevOps in Federal Government © 2015 Carnegie Mellon University “I fear not the man who has practiced ten thousand kicks once, but I fear the man who has practiced one kick ten thousand times.” – Bruce Lee
- 19. 19 DevOps in Federal Government © 2015 Carnegie Mellon University Improved Feedback
- 20. 20 DevOps in Federal Government © 2015 Carnegie Mellon University An actor operating as a singleton is sabotaging the system.
- 21. 21 DevOps in Federal Government © 2015 Carnegie Mellon University Empathy
- 22. 22 DevOps in Federal Government © 2015 Carnegie Mellon University Strangers == Stress == Lower Empathy
- 23. 23 DevOps in Federal Government © 2015 Carnegie Mellon University Results
- 24. 24 DevOps in Federal Government © 2015 Carnegie Mellon University SEI DevOps Blog https://insights.sei.cmu.edu/devops Secure DevOps Symposium (November 5th) http://www.cert.org/go/dev-ops-symposium
- 25. 25 DevOps in Federal Government © 2015 Carnegie Mellon University 1. Culture is #1 barrier to change 2. Shift left your understanding of key stakeholders 3. Continual process improvement can expose useful metrics 4. AppSec can’t be fully automated (yet), but we can do better 5. Empathy is huge and fixable through shared experiences Top Five Takeaways
- 26. 26 DevOps in Federal Government © 2015 Carnegie Mellon University Automate all the security things! Here’s what I’m looking for help with…
- 27. 27 DevOps in Federal Government © 2015 Carnegie Mellon University Aaron Volkmann @aaronvolk amvolkmann@cert.org Thanks!
Editor's Notes
- 11/18/2015
- FFRDC CERT CC – 1988 Morris Worm - We regularly partner with government, industry, law enforcement, and academia to develop advanced methods and technologies to counter large-scale, sophisticated cyber threats.
- Develop and deliver prototype software solutions Prototypes become production Liason – Business Person – Users No ops contact
- Agile shop CI / CD No access to test systems on customer’s side Environment was communicated to us through email 1 year of development
- Testing in pseudo production Production problems found late in the game before funding dried up Right stakeholders not brought in at the right time (ops, security)
- CYA Blame Friction with other projects
- Gained access to proper test environments - Environment parity is key Learned who the key people were who needed to be engaged
- Customer used to monolithic releases Get customer used to taking releases more often Continuous Delivery into a staging environment on their side Made documentation available via doc server
- Approval process was big, did that once, then re-used authorization for iterative releases
- Early Failures are good No blame, encourage risk taking Pilot release of new versions of software PCSAM – Problem Cause Solution Action Measure
- Cause – Why Why Why Why Measure – Tie back to a business outcome to find a useful metric Index cards Went into backlog Fix in order of how much pain they caused Keeps mistakes from being repeated Not having any problems in a certain amount of time should be considered a problem
- Amplified feedback loops Communication from users to developers direct Specialized knowledge not in people’s heads, it’s documented
- Brent effect
- McGill University Empathy Study
- A stronger partnership Increased visibility of progress Fewer defects Faster lead time More transparency
- 11/18/2015