The Gene Kim book, The Phoenix Project, popularized DevOps with an implied need for cultural change. Unfortunately, tools and processes dominate most related conferences and local user group meetings. During the hour, David Moskowitz will discuss the need to take a whole systems view of DevOps that combines strategy and risk into a single entity — Strategy-Risk, which serves as the basis to create and deliver digital business value. This idea represents a potentially different mindset with a corresponding cultural shift.
Join your peers to gain new perspectives, share experiences, and collaborate on real-life solutions to your most pressing problems. Come away with actionable insights and build a strong professional network as you engage with old friends and make new connections at our In Person meeting on April 14th at The Madison Hotel. Networking starts at 5:30pm. The presentation will also be hosted on Zoom starting at 6:30pm
About the Speaker
David Moskowitz started his formal career as an operating systems programmer and systems architect, which required that he look at the code he had written and how the resulting operating system might impact the business/research applications on the computer. Later, while serving in the US Army, he was tasked to apply that approach to looking at different forms of systems and complexity regarding where and how US Forces were engaged. This required working within the integration of the staff functions (personnel, intelligence, operations, logistics, and later civilian-military operations & planning).
After his military service, he continued to apply a systems approach to his job. In 1979, he worked on an anti-submarine warfare program for a DoD prime contractor, where he assumed responsibility for an aspect of the effort that was more than 18-months behind schedule and still slipping. Applying a whole systems approach, he addressed the organizational and inter-personal cultural issues to create a high-performing team that completed the effort in 9-months. That required developing a more formalized approach to managing changes, development, testing, release & deployment combined with short iterations and constant feedback that would be recognizable today as aspects of ITIL. Working with small increments of functionality and in short intervals, the team used a wall full of corkboards, 4×6 cards, and thumbtacks so that, at a glance, everyone could review and understand the status of every aspect of the team’s efforts (similar to Kanban, today).
Later as a consultant, he worked to assist organizations in adopting what they considered to be technical disruptions (including object-oriented programming, grid, agile, mobile, cloud, and DevOps). He applied a critical lesson learned from experience: “Every problem he’d help resolve was, at its core, a people problem, not a technology problem.” Technology was either an enabler or an inhibitor. The recurring mantra of these efforts was, “Solve the problem; don’t treat the symptom.”