[{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/ai-augmented-enterprise/","section":"Tags","summary":"","title":"AI-Augmented Enterprise","type":"tags"},{"content":"Artificial Intelligence has moved from research labs into boardrooms, but too often it is surrounded by hype, inflated promises, and misguided investments. Many organizations rush to \u0026ldquo;do something with AI\u0026rdquo; without considering trust, data confidentiality, or the actual problems they are trying to solve.\nWhat This Talk Covers # This talk cuts through the noise and explores practical, grounded ways to leverage AI for innovation. We trace AI\u0026rsquo;s evolution, demystify how modern models work, and address key concerns such as reliability, risks, and data security.\nKey Messages # 1. From Hype to Understanding AI\u0026rsquo;s evolution demystified: how modern models actually work, what they can and cannot do, and why trust, reliability, and data security matter. The technology is only as good as the system around it.\n2. Practical Use Cases and Patterns Three realistic usage patterns (Automate, Augment, Co-Create) show how AI can reduce costs, increase efficiency, and free up team capacity. The key is choosing the right pattern for the right context.\n3. The AI-Augmented Enterprise The future is not about AI replacing people, but about combining human ingenuity with AI\u0026rsquo;s scalability. By weaving together organization, processes, technology, governance, and AI, companies can transform into AI-augmented enterprises that are resilient, adaptive, and built to thrive in change.\n","date":"17 June 2026","externalUrl":null,"permalink":"/en/speaking/beyond-the-hype-understanding-and-applying-ai-in-innovation/","section":"Speaking","summary":"Artificial Intelligence has moved from research labs into boardrooms, but too often it is surrounded by hype, inflated promises, and misguided investments. Many organizations rush to “do something with AI” without considering trust, data confidentiality, or the actual problems they are trying to solve.\n","title":"Beyond the Hype: Understanding and Applying AI in Innovation","type":"speaking"},{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/digital-transformation/","section":"Tags","summary":"","title":"Digital Transformation","type":"tags"},{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/innovation/","section":"Tags","summary":"","title":"Innovation","type":"tags"},{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/platform-thinking/","section":"Tags","summary":"","title":"Platform Thinking","type":"tags"},{"content":"Turning AI ambition into an operating model\n","date":"17 June 2026","externalUrl":null,"permalink":"/en/","section":"Romano Roth","summary":"Turning AI ambition into an operating model\n","title":"Romano Roth","type":"page"},{"content":" Topics I Speak About # AI-Augmented Delivery \u0026amp; Platform: Operating models for AI-powered organizations Platform Engineering: Developer experience and self-service at scale AI-Augmented DevOps: From experimentation to real business impact Enterprise Architecture: Bridging strategy and execution DevSecOps: Security built into the delivery system ","date":"17 June 2026","externalUrl":null,"permalink":"/en/speaking/","section":"Speaking","summary":"Topics I Speak About # AI-Augmented Delivery \u0026 Platform: Operating models for AI-powered organizations Platform Engineering: Developer experience and self-service at scale AI-Augmented DevOps: From experimentation to real business impact Enterprise Architecture: Bridging strategy and execution DevSecOps: Security built into the delivery system ","title":"Speaking","type":"speaking"},{"content":"","date":"17 June 2026","externalUrl":null,"permalink":"/en/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"Imagine it is 2046. And your most important conversation is not with a human. What remains of autonomy, responsibility, and purpose? A look into the AI future, in three scenarios.\nThree Scenarios for 2046 # What does our world look like in 20 years? Nobody knows. But we can explore scenarios based on today\u0026rsquo;s developments and recognize which decisions are being made right now.\nScenario 1: Humans at the Wheel AI is a powerful tool, but humans make the decisions. Transparency, regulation, and digital education have ensured that technology serves people. What needs to happen today for this scenario to become reality?\nScenario 2: The Gradual Handover AI systems make more and more decisions because they are faster and cheaper. Not through one big disruption, but through a thousand small conveniences. Humans are still there, but they just nod along. Can we recognize the warning signs?\nScenario 3: The Machine Takes Over Algorithms optimize society, economy, and daily life. Efficiency is the highest good. What falls by the wayside: creativity, chance, human imperfection, the very things that make us who we are.\nWhy Now? # The decisions we make in 2026, whether as developers, executives, or citizens, determine which scenario we wake up in by 2046. This talk does not just show possible futures. It asks the question: What are you doing today so that we still have a choice tomorrow?\nNot Science Fiction # All three scenarios are based on technologies and trends that already exist today. From autonomous agents to AI-powered decision systems to digital identity. The difference lies not in the technology, but in the decisions we make as a society.\n","date":"18 May 2026","externalUrl":null,"permalink":"/en/speaking/2046-steuern-wir-maschinen-oder-steuern-sie-uns/","section":"Speaking","summary":"Imagine it is 2046. And your most important conversation is not with a human. What remains of autonomy, responsibility, and purpose? A look into the AI future, in three scenarios.\n","title":"2046: Do We Control Machines or Do They Control Us?","type":"speaking"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/ai-augmented-thinking/","section":"Tags","summary":"","title":"AI-Augmented Thinking","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/digital-sovereignty/","section":"Tags","summary":"","title":"Digital Sovereignty","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/ethics/","section":"Tags","summary":"","title":"Ethics","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/europe/","section":"Tags","summary":"","title":"Europe","type":"tags"},{"content":"Artificial Intelligence does not decide Europe\u0026rsquo;s future. Human decisions do. In this talk, I show what you can do differently starting tomorrow: which skills to build, how to choose AI tools, and how to reduce dependencies. No moral finger-wagging, just straight talk.\nWhat This Is About # Europe is at a turning point. While US and Chinese tech giants dominate the AI infrastructure, we are debating regulation. That matters, but it is not enough. The decisive question is not whether AI is coming, but who shapes it and who becomes dependent on it.\nWhat You Take Away # This talk delivers no dystopian warnings and no utopian promises. Instead, there are three concrete areas for action:\n1. Build Skills Which capabilities are truly needed in an AI-permeated working world? Not \u0026ldquo;prompt engineering\u0026rdquo; as a buzzword, but the ability to use AI critically, evaluate results, and remain human where machines fail.\n2. Choose AI Tools Deliberately Not every tool that is free and convenient is also smart. I show how to evaluate AI tools based on criteria like data sovereignty, transparency, and dependency, rather than simply using whatever everyone else uses.\n3. Reduce Dependencies From your own organization to the European level: which concrete steps reduce dependency on single vendors and ecosystems? With real-world examples from companies that are already doing exactly this.\nFor Whom # For everyone who wants to shape AI, not just consume it. Whether you are an executive, developer, founder, or simply someone who wants to understand what is happening and what they can do about it.\n","date":"18 May 2026","externalUrl":null,"permalink":"/en/speaking/europa-ueberlebt-ki-nur-wenn-wir-handeln/","section":"Speaking","summary":"Artificial Intelligence does not decide Europe’s future. Human decisions do. In this talk, I show what you can do differently starting tomorrow: which skills to build, how to choose AI tools, and how to reduce dependencies. No moral finger-wagging, just straight talk.\n","title":"Europe Only Survives AI If We Act, You Too","type":"speaking"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/future/","section":"Tags","summary":"","title":"Future","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/hype/","section":"Tags","summary":"","title":"Hype","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/society/","section":"Tags","summary":"","title":"Society","type":"tags"},{"content":"","date":"18 May 2026","externalUrl":null,"permalink":"/en/tags/transformation/","section":"Tags","summary":"","title":"Transformation","type":"tags"},{"content":"Where ChatGPT cowboys ride the hype, we need a clear look at AI:\nIt is a pattern recognition machine. It has no brain. We still need to use our own. It does not replace humans, it complements them. Why we should start thinking in feedback loops.\nThe Problem with the Hype # Every meeting starts with \u0026ldquo;Can\u0026rsquo;t we just do this with AI?\u0026rdquo; Every LinkedIn post promises a revolution. And every other \u0026ldquo;AI expert\u0026rdquo; was doing something completely different six months ago. Welcome to the age of AI idiots.\nThe problem is not AI itself. The problem is how we deal with it. We treat AI like magic instead of a tool. We overestimate what it can do and underestimate what we can do.\nWhat AI Really Is # AI recognizes patterns in data. That is impressive, but it is not thinking. It has no understanding, no intention, no judgment. Those who forget this make bad decisions, not because the AI is bad, but because humans stopped thinking for themselves.\nAI-Augmented Thinking # The solution is not \u0026ldquo;less AI\u0026rdquo; or \u0026ldquo;more AI.\u0026rdquo; It is: better collaboration. AI-Augmented Thinking is a mental model that understands humans and machines as a feedback loop. Humans set goals, evaluate results, and make decisions. Machines deliver data, recognize patterns, and scale execution.\nNo either-or. No hype. No panic. Just a clear framework for collaborating with AI that actually works.\nFor Whom # For everyone who has had enough of empty promises and AI buzzword bingo. Who wants to know what AI can really do, what it cannot, and how to use it meaningfully. With straight talk, real-world examples, and no moral finger-wagging.\n","date":"18 May 2026","externalUrl":null,"permalink":"/en/speaking/willkommen-im-zeitalter-der-ki-idioten/","section":"Speaking","summary":"Where ChatGPT cowboys ride the hype, we need a clear look at AI:\nIt is a pattern recognition machine. It has no brain. We still need to use our own. It does not replace humans, it complements them. Why we should start thinking in feedback loops.\n","title":"Welcome to the Age of AI Idiots!","type":"speaking"},{"content":"AI is everywhere, between hype, hope, and knee-jerk reactions. But engineering is more than output: responsibility, systems thinking, and decision quality matter.\nWhat This Talk Covers # In this talk, Romano Roth, Chief AI Officer at Zühlke, shows where AI already delivers reliable value in engineering today, where it fails, and what new skills and ways of working are emerging. With concrete examples from everyday practice.\nKey Messages # 1. AI Already Delivers Real Value in Engineering In certain areas, AI produces reliable results today. The art lies in recognizing these areas and leveraging them effectively.\n2. AI Has Limits, and They Matter Where responsibility, systems thinking, and decision quality are required, AI reaches its limits. Engineers bring exactly what AI lacks.\n3. New Skills and Ways of Working Are Emerging AI changes not just tools, but also how engineers work. Those who understand these changes and actively shape them stay relevant.\n","date":"22 April 2026","externalUrl":null,"permalink":"/en/speaking/ki-hat-kein-gehirn-ingenieurinnen-schon/","section":"Speaking","summary":"AI is everywhere, between hype, hope, and knee-jerk reactions. But engineering is more than output: responsibility, systems thinking, and decision quality matter.\nWhat This Talk Covers # In this talk, Romano Roth, Chief AI Officer at Zühlke, shows where AI already delivers reliable value in engineering today, where it fails, and what new skills and ways of working are emerging. With concrete examples from everyday practice.\n","title":"AI Has No Brain. Engineers Do.","type":"speaking"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/en/tags/engineering/","section":"Tags","summary":"","title":"Engineering","type":"tags"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/en/tags/responsibility/","section":"Tags","summary":"","title":"Responsibility","type":"tags"},{"content":"","date":"22 April 2026","externalUrl":null,"permalink":"/en/tags/systems-thinking/","section":"Tags","summary":"","title":"Systems Thinking","type":"tags"},{"content":"","date":"1 April 2026","externalUrl":null,"permalink":"/en/tags/agentic-ai/","section":"Tags","summary":"","title":"Agentic AI","type":"tags"},{"content":"","date":"1 April 2026","externalUrl":null,"permalink":"/en/tags/banking/","section":"Tags","summary":"","title":"Banking","type":"tags"},{"content":"Articles and insights on DevOps, Platform Engineering, AI, Enterprise Architecture, and digital transformation.\n","date":"1 April 2026","externalUrl":null,"permalink":"/en/blogs/","section":"Blogs","summary":"Articles and insights on DevOps, Platform Engineering, AI, Enterprise Architecture, and digital transformation.\n","title":"Blogs","type":"blogs"},{"content":"","date":"1 April 2026","externalUrl":null,"permalink":"/en/tags/cybernetic-enterprise/","section":"Tags","summary":"","title":"Cybernetic Enterprise","type":"tags"},{"content":"Banks spend 93% of their AI budget on technology. Only 7% goes to people. And then they wonder why 95% see no impact on their P\u0026amp;L.\nOn March 31, 2026, I gave a keynote at the Zühlke Banking Talk in Schlieren on why the future of AI is \u0026ldquo;cybernetic\u0026rdquo; and what it takes to become an AI-native bank. The evening brought together perspectives from academia, a major German bank, and practitioners from Swiss financial institutions.\nThe Event # The Zühlke Banking Talk was hosted by Fabian Braunwalder (MD Banking CH, Zühlke) and Björn Lehnhardt (MD FSI Germany, Zühlke). The program featured three keynotes and a panel discussion:\nProf. Dr. Andreas Dietrich (HSLU): \u0026ldquo;Auf dem Weg zur AI-native Bank\u0026rdquo; on how Swiss banks position themselves in a fast-moving market Stephan A. Paxmann (CIO, LBBW): \u0026ldquo;Agentic AI in Financial Services\u0026rdquo; on how agentic AI will reshape banking Romano Roth (Zühlke): \u0026ldquo;Warum die Zukunft von AI \u0026lsquo;cybernetic\u0026rsquo; ist\u0026rdquo; on building adaptive, AI-native organizations Panel discussion moderated by Andrea Perl (Partner Data \u0026amp; AI, Zühlke) with Lisa Zimmermann (PostFinance), Christophe Makni (Migros Bank), and Stephan A. Paxmann (LBBW) The Problem Is Not the Next Tool # $30 to 40 billion invested in generative AI globally. Most companies bought tools, ran trainings, and hoped for the best. That is not a strategy. That is a shopping list.\nWhat is missing is not the next tool. What is missing is the ability to steer and adapt.\nA Cybernetic Enterprise works differently. Humans and AI work in continuous feedback loops, creating value together. Three dimensions, one system: organization, technology, and processes.\nThree Theses for the AI-Native Bank # 1. E-banking dies. Agents work directly on the data. No app, no interface. APIs and structured data are the new infrastructure.\n2. Who does not own the agent becomes a supplier. Context beats control. Think of the hotel behind Booking.com.\n3. Your data is more valuable than your products. Mortgages, accounts, credit cards are all interchangeable. Your 156 customer touchpoints per year are not.\nRegulation Is Not a Brake # Regulation is banks\u0026rsquo; only moat against Big Tech. Big Tech has unlimited compute and generic algorithms. Banks have decades of trust, regulated access to financial data, and governance. That is the real competitive advantage.\nHuman-AI Work Distribution # The question is not whether AI replaces humans. The question is how work gets distributed between humans and AI. I presented a framework with four quadrants and real examples from the banking industry:\nHSBC: AML monitoring with 60% fewer false positives Lloyds/Experian: Perpetual KYC, no more periodic reviews Julius Bär/Unique.ai: AI investment copilot, FINMA-compliant Kyriba: AI liquidity manager, from \u0026ldquo;managing cash\u0026rdquo; to \u0026ldquo;steering scenarios\u0026rdquo; The Future Organization # The future organization has teams of 3 +/- 2 people, each orchestrating 4+ AI agents. No business/IT split. Full ownership over the value stream. A platform team serves as the AI enablement layer: agent registry, guardrails, observability, A2A.\nStephan A. Paxmann from LBBW put it perfectly: \u0026ldquo;We don\u0026rsquo;t govern code. We govern agents. We assign them IDs, budgets, wallets, just as we would with an employee.\u0026rdquo;\nInsights from the Panel # Prof. Dr. Andreas Dietrich from HSLU raised the real question: What happens to banks\u0026rsquo; advisory services when customers trust their personal AI bot more than their banker?\nThe panel brought together three very different banks (PostFinance, Migros Bank, LBBW) with diverse perspectives but a shared conviction: this is not about technology alone. The discussion on governance and where to draw the line between human and AI decisions was one of the most honest I have seen.\nThree Things You Can Do Tomorrow # Shift your budget. Cancel the next tool license. Invest the money in AI enablement for your team. Redesign a value stream. Business and IT together. Small. Measurable. With a feedback loop. Map your human-AI work distribution. Where do you delegate work? Where do you collaborate? The answer determines your roadmap. The bank of tomorrow is not a tech company with a banking license. It is a cybernetic bank that understands its customers better than any Silicon Valley algorithm.\nAI will not be the last technology wave. After AI comes the next one. And the one after that. But if your organization has the ability to continuously adapt, it does not matter what comes next. You will be ready.\n","date":"1 April 2026","externalUrl":null,"permalink":"/en/blogs/zuehlke-banking-talk-ai-native-bank/","section":"Blogs","summary":"Banks spend 93% of their AI budget on technology. Only 7% goes to people. And then they wonder why 95% see no impact on their P\u0026L.\nOn March 31, 2026, I gave a keynote at the Zühlke Banking Talk in Schlieren on why the future of AI is “cybernetic” and what it takes to become an AI-native bank. The evening brought together perspectives from academia, a major German bank, and practitioners from Swiss financial institutions.\n","title":"Zühlke Banking Talk: The Road to the AI-Native Bank","type":"blogs"},{"content":"","date":"31 March 2026","externalUrl":null,"permalink":"/en/tags/ai-native/","section":"Tags","summary":"","title":"AI-Native","type":"tags"},{"content":"Wie sich adaptive, AI-native Organisationen aufbauen lassen, in denen Menschen, Technologie, Daten und AI-Modelle effizient zusammenwirken.\n30 bis 40 Milliarden Dollar wurden weltweit in generative KI investiert. 95 % der Unternehmen sehen keinen Einfluss auf ihre Gewinn- und Verlustrechnung. Nur 5 % erzielen echten Mehrwert. Unternehmen geben 93 % für Technologie und nur 7 % für Personal aus. Was fehlt, ist nicht das nächste Tool. Was fehlt, ist die Steuer- und Anpassungsfähigkeit.\nDas AI-Augmented Enterprise # Ein AI-augmented Unternehmen ist eine kontinuierlich adaptive Organisation mit geschlossenen Feedback-Loops, KI-gestützter Intelligenz und autonomen, crossfunktionalen Teams. Drei Dimensionen bilden ein System:\nOrganisation: Keine Trennung Business/IT mehr. Produkt- und Serviceteams, schlanker, befähigt, unterstützt von Agenten. Technologie: Plattform-Denken. KI als Nervensystem. APIs als strategisches Asset. Prozesse: Von Projekten zu Produkten. Kurze Zyklen, Feedback-gesteuert. Drei Thesen für die AI-native Bank # Das E-Banking stirbt. Agenten arbeiten direkt auf den Daten. Keine App, keine Oberfläche. APIs und strukturierte Daten sind die neue Infrastruktur. Wer den Agenten nicht besitzt, wird zum Zulieferer. Kontext schlägt Kontrolle. Wie das Hotel hinter Booking.com. Eure Daten sind wertvoller als eure Produkte. Hypotheken, Konten, Kreditkarten: alles austauschbar. 156 Kunden-Touchpoints pro Jahr nicht. Regulatorik als Burggraben # Regulatorik ist kein Bremsklotz. Sie ist der einzige Burggraben der Banken gegen Big Tech. Banken haben Jahrzehnte gewachsenes Vertrauen, regulierten Zugang zu Finanzdaten, Governance, Compliance und Auditierbarkeit.\nDie Organisation der Zukunft # Teams von 3 +/- 2 Personen. Jeder Mensch orchestriert 4+ AI-Agenten. Volle Ownership über den gesamten Wertstrom. Ein Platform Team als AI Enablement Layer.\nDie Bank von morgen ist kein Tech-Unternehmen mit Banklizenz. Sie ist eine AI-native Bank, die ihre Kunden besser versteht als jeder Silicon-Valley-Algorithmus.\n","date":"31. March 2026","externalUrl":null,"permalink":"/de/speaking/die-ai-native-bank/","section":"Vorträge","summary":"Wie sich adaptive, AI-native Organisationen aufbauen lassen, in denen Menschen, Technologie, Daten und AI-Modelle effizient zusammenwirken.\n30 bis 40 Milliarden Dollar wurden weltweit in generative KI investiert. 95 % der Unternehmen sehen keinen Einfluss auf ihre Gewinn- und Verlustrechnung. Nur 5 % erzielen echten Mehrwert. Unternehmen geben 93 % für Technologie und nur 7 % für Personal aus. Was fehlt, ist nicht das nächste Tool. Was fehlt, ist die Steuer- und Anpassungsfähigkeit.\n","title":"Die AI-native Bank: Warum die Zukunft von AI organisatorisch ist","type":"speaking"},{"content":"How to build adaptive, AI-native organizations where people, technology, data, and AI models work together efficiently.\n$30 to 40 billion invested in generative AI globally. 95% of companies see no impact on their P\u0026amp;L. Only 5% create real value. Companies spend 93% on technology and only 7% on people. What is missing is not the next tool. What is missing is the ability to steer and adapt.\nThe AI-Augmented Enterprise # An AI-augmented enterprise is a continuously adaptive organisation built on closed feedback loops, AI-powered intelligence, and autonomous cross-functional teams. Three dimensions form one system:\nOrganization: No more business/IT split. Product and service teams, leaner, empowered, supported by agents. Technology: Platform thinking. AI as the nervous system. APIs as a strategic asset. Processes: From projects to products. Short cycles, feedback-driven. Three Theses for the AI-Native Bank # E-banking dies. Agents work directly on the data. No app, no interface. APIs and structured data are the new infrastructure. Who does not own the agent becomes a supplier. Context beats control. Like the hotel behind Booking.com. Your data is more valuable than your products. Mortgages, accounts, credit cards are all interchangeable. Your 156 customer touchpoints per year are not. Regulation as a Moat # Regulation is not a brake. It is banks\u0026rsquo; only moat against Big Tech. Banks have decades of trust, regulated access to financial data, governance, compliance, and auditability.\nThe Future Organization # Teams of 3 +/- 2 people, each orchestrating 4+ AI agents. Full ownership over the value stream. A platform team as the AI enablement layer.\nThe bank of tomorrow is not a tech company with a banking license. It is an AI-native bank that understands its customers better than any Silicon Valley algorithm.\n","date":"31 March 2026","externalUrl":null,"permalink":"/en/speaking/the-ai-native-bank/","section":"Speaking","summary":"How to build adaptive, AI-native organizations where people, technology, data, and AI models work together efficiently.\n$30 to 40 billion invested in generative AI globally. 95% of companies see no impact on their P\u0026L. Only 5% create real value. Companies spend 93% on technology and only 7% on people. What is missing is not the next tool. What is missing is the ability to steer and adapt.\n","title":"The AI-Native Bank: Why AI's Future Is Organisational","type":"speaking"},{"content":"","date":"25 March 2026","externalUrl":null,"permalink":"/en/tags/awards/","section":"Tags","summary":"","title":"Awards","type":"tags"},{"content":"","date":"25 March 2026","externalUrl":null,"permalink":"/en/tags/community/","section":"Tags","summary":"","title":"Community","type":"tags"},{"content":"","date":"25 March 2026","externalUrl":null,"permalink":"/en/tags/devops/","section":"Tags","summary":"","title":"DevOps","type":"tags"},{"content":"","date":"25 March 2026","externalUrl":null,"permalink":"/en/tags/digital-shapers/","section":"Tags","summary":"","title":"Digital Shapers","type":"tags"},{"content":"I am honored to share that I have been named a Digital Shaper 2026 in the Mentors category. The Digital Shapers initiative, organized by BILANZ, Handelszeitung, and digitalswitzerland with the support of Huawei, recognizes 100 of Switzerland\u0026rsquo;s most influential digital minds each year across ten categories.\nWhat Are the Digital Shapers? # The Digital Shapers is one of Switzerland\u0026rsquo;s most prestigious recognitions in the technology and digital transformation space. Every year, a jury selects 100 personalities who are shaping the country\u0026rsquo;s digital future. The ten categories for 2026 are: AI Acrobats, Androids, Cloudriders, Defenders, Energizer, Fintechies, Frameworkers, Health Techies, Quantum Leapers, and The Mentors.\nThe award ceremony, the Digital Shapers Gala, took place on March 24, 2026, at the Folium in Zurich.\nThe Mentors Category # The Mentors category honors those who share their knowledge and experience to empower the next generation of digital leaders. Mentors are the advisors, trainers, coaches, and community builders who ensure that digital transformation is not just about technology but about people.\nThis resonates deeply with my belief that sustainable progress requires humans remaining integral to technological systems. Technology alone does not create transformation. It is the combination of people, platforms, and purpose that drives real change.\nA Journey of Over 20 Years # This recognition reflects a journey that has spanned more than two decades at Zuhlke Group, where I currently serve as Global Chief of Cybernetic Transformation and Partner. Looking back, several milestones stand out:\nCommunity building: As President of DevOpsDays Zurich and co-organizer of the Zurich DevOps Meetup (3,000+ members), I have always believed that shared learning accelerates transformation. Teaching: As an instructor at HSLU (Hochschule Luzern), I work with the next generation of technology leaders to give them the skills they need. Knowledge sharing: With over 400 YouTube videos, numerous publications, and talks at conferences worldwide, making complex topics accessible has always been a core part of my work. Writing: My books on the Cybernetic Enterprise provide a practical framework for organizations seeking to become future-ready through continuous learning, AI-augmented intelligence, and fast feedback loops. What Drives Me # My work centers on the idea that the future belongs to organizations that can learn, adapt, and evolve. The Cybernetic Enterprise is more than a concept. It is an operating model where technology, people, and processes form a continuously learning system. AI is not a replacement for human judgment but a partner that amplifies it.\nThis award is not just a personal milestone. It is a validation that the topics I care about, Agile,DevOps, Platform Engineering, AI, Cybernetic Transformation, and community-driven knowledge sharing, are making an impact.\nThank You # I want to thank everyone who has been part of this journey: my colleagues at Zuhlke, the DevOps community in Switzerland and beyond, my students at HSLU, and all the conference organizers and co-speakers who create spaces for knowledge exchange. This award belongs to all of us.\nLinks # BILANZ: Digital Shapers 2026 BILANZ: The Mentors Category Ringier: Digital Shapers 2026 ","date":"25 March 2026","externalUrl":null,"permalink":"/en/blogs/digital-shapers-2026-the-mentors/","section":"Blogs","summary":"I am honored to share that I have been named a Digital Shaper 2026 in the Mentors category. The Digital Shapers initiative, organized by BILANZ, Handelszeitung, and digitalswitzerland with the support of Huawei, recognizes 100 of Switzerland’s most influential digital minds each year across ten categories.\n","title":"Digital Shapers 2026: Honored in the Mentors Category","type":"blogs"},{"content":"It is not the technology that is under pressure, but its integration into everyday business operations. Budgets are tightening, regulation is taking hold, and boards are demanding robust results rather than more roadmaps. The era of non-committal pilot projects is ending.\nAI is evolving from an innovation promise to an operational discipline, and with it, a leadership responsibility.\nThe Valuation Reset: When the CFO Asks About ROI # In 2026, AI initiatives will increasingly be evaluated by value path and capital discipline. A potential valuation reset in the market is driven less by technology than by macroeconomics: the changed interest rate environment and the high market concentration of major tech companies add further risk.\nFor enterprises, this means AI portfolios must remain viable even under budget stress. Every initiative needs defined measurement points, contractual exit options, and a robust cash flow path. AI investments without clear proof of value will no longer be considered visionary in 2026, but reckless.\nHybrid Architectures: No More One Model for Everything # The era of the universal cloud model is ending. Companies are building hybrid architectures: locally hosted, sovereign, externally combined. The drivers are not ideological but operational: data residency, compliance requirements, geopolitical risks, export controls, and demanding requirements for latency and predictable inference costs.\nThe target is a platform-capable model portfolio with an LLM gateway, model registry, and intelligent routing by risk, cost, and latency. Without this infrastructure layer, shadow AI, vendor lock-in, and uncontrolled costs emerge. Those without an AI platform in 2026 do not have an AI program, they have a collection of disconnected experiments.\nOrganizational Design: Better Tools Cannot Fix the Wrong Operating Model # Many AI programs fail not because of the model, but because of the operating logic: AI is layered onto existing silos without adapting the organizational structure. This multiplies complexity rather than impact. The critical distinction lies between AI output and AI impact: impact only occurs when feedback loops actually trigger decisions, not just populate dashboards.\nThree prerequisites are essential: First, end-to-end feedback loops on customer value, costs, and risk that reach into operational teams. Second, autonomous product teams with genuine decision-making authority and end-to-end responsibility. Third, a platform with self-service, observability, and policy-as-code that enables teams to deliver quickly and safely. Governance based primarily on manual gate processes does not just slow things down, it encourages circumvention strategies instead of compliance.\nAI-Native Engineering: Speed Without Control Is Not a Strength # Generative AI significantly accelerates software development. Without engineering discipline, however, it equally scales errors, security vulnerabilities, and IP issues. The path from prompt to production without quality assurance will not be viable in 2026, neither from an audit nor a security perspective.\nThe new standard is: quality before speed. Every AI-assisted work step, whether refactoring, testing, or bug fixes, needs defined review criteria and curated reference tasks with known solutions. Additionally required are end-to-end transparency on costs, error rates, and latencies, as well as binding security requirements along known LLM risks. Those who do not systematically review AI-generated code are not automating productivity, they are automating their attack surface.\nPhysical AI: Where Physics Does Not Forgive Hallucinations # AI is moving into physical environments: manufacturing, logistics, healthcare, energy grids. In these contexts, errors are not just costly but potentially dangerous. European industry is under pressure, as regulatory and competitive frameworks increasingly compel the step into physical AI applications.\nThe bottleneck lies not in demonstration but in operations: real-time capability, safety-by-design, human-in-the-loop, and an integrated security architecture that treats cybersecurity and functional safety as a shared design target. Companies should prioritize two to three physical use cases with clear business cases and defined safety profiles. Digital twins, simulations, and controlled rollouts determine whether the transition from simulation to reality succeeds or fails expensively.\nWorkforce: The Talent Shortage Companies Create Themselves # The justification \u0026ldquo;AI replaces jobs\u0026rdquo; currently drives hiring freezes and layoffs in many organizations. Operationally, however, this creates a structural risk by design: if fewer junior talent is hired in 2025 and 2026, the talent pipeline will be missing in 2027 and 2028. Simultaneously, demand for AI-skilled engineers, platform, and security talent is rising significantly.\nWorkforce management should be understood at C-level like a supply chain, with clear pipeline quotas, measurable time-to-productivity, and targeted retention of high learners. An AI-native apprenticeship model creates the structural foundation: juniors work on real backlog responsibilities, seniors act as coaches, supported by golden tasks and mandatory review gates. The focus is not on banning AI-generated code, but on mastering it as a competency and quality discipline.\nAI Agents: After the Hype Comes the Engineering Work # 2025 was declared the year of AI agents. The results are sobering: field studies show that many deployments fell short of expectations. The successful implementations share one trait that sounds anything but glamorous: methodical production discipline.\nProductive agents are bounded, verifiable, observable, and can be shut down at any time. Autonomy is budgeted by steps, tool calls, costs, and time. Critical decisions remain with humans. Scaling requires a structured agent production pipeline: defined test cases, end-to-end telemetry, rollback mechanisms, incident processes, and clear ownership across product, engineering, and risk. Agents with write access to core systems should not be permitted without robust guardrails.\nCompanion AI: When Machines Build Trust and Can Abuse It # AI systems are evolving toward relational functions: coaching, learning, care, onboarding. They provide encouragement, personalized feedback, and simulated social interaction. This can improve outcomes. But it can also create dependencies, deliberately influence, and normalize disinformation. Regulation has recognized this: the EU AI Act addresses key aspects of this risk category.\nCompanies deploying companion AI need emotional safety standards before go-live, not after: transparency about functionality and limitations, anti-dependency mechanisms, escalation paths to human contacts, logging for safety incidents, and clear boundaries against therapy, legal, or medical services.\nConclusion: Three Guidelines and an Uncomfortable Truth # The eight trends converge into one clear message: AI is becoming an operational discipline. For the C-level, three central guidelines follow.\nProduction readiness before piloting. AI initiatives need binding evals, standardized telemetry, rollback mechanisms, and clear ownership. Pilots without operational readiness create visibility, but not value.\nRisk and cost management as a design principle. Sovereignty, portability, FinOps, and auditability must not be downstream control functions but must be integrated into architecture and governance from the start.\nOperating model before tooling. End-to-end feedback loops, autonomous teams, and a platform understood as a product form the structural foundation. Organization, governance, and platform architecture must be thought of in sync, otherwise new tools merely digitize existing silos.\nThe uncomfortable truth behind it: none of these trends can be solved with technology alone. In 2026, the successful company will not be the one that uses the most AI, but the one that operates AI most reliably: measurable, controllable, and resilient.\nThis article was originally published on ComputerWeekly.de.\n","date":"24 March 2026","externalUrl":null,"permalink":"/en/publications/computerweekly-ki-2026-trends/","section":"Publications","summary":"It is not the technology that is under pressure, but its integration into everyday business operations. Budgets are tightening, regulation is taking hold, and boards are demanding robust results rather than more roadmaps. The era of non-committal pilot projects is ending.\n","title":"AI 2026: Trends and Guidelines for Deployment","type":"publications"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/ai-agents/","section":"Tags","summary":"","title":"AI Agents","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/ai-trends/","section":"Tags","summary":"","title":"AI Trends","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/governance/","section":"Tags","summary":"","title":"Governance","type":"tags"},{"content":"","date":"24. March 2026","externalUrl":null,"permalink":"/de/tags/ki/","section":"Tags","summary":"","title":"KI","type":"tags"},{"content":"","date":"24. March 2026","externalUrl":null,"permalink":"/de/tags/ki-agenten/","section":"Tags","summary":"","title":"KI-Agenten","type":"tags"},{"content":"","date":"24. March 2026","externalUrl":null,"permalink":"/de/tags/ki-trends/","section":"Tags","summary":"","title":"KI-Trends","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/physical-ai/","section":"Tags","summary":"","title":"Physical AI","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/platform-engineering/","section":"Tags","summary":"","title":"Platform Engineering","type":"tags"},{"content":"Books, magazine articles, whitepapers, and other written contributions.\n","date":"24 March 2026","externalUrl":null,"permalink":"/en/publications/","section":"Publications","summary":"Books, magazine articles, whitepapers, and other written contributions.\n","title":"Publications","type":"publications"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/en/tags/software-development/","section":"Tags","summary":"","title":"Software Development","type":"tags"},{"content":"","date":"24. March 2026","externalUrl":null,"permalink":"/de/tags/softwareentwicklung/","section":"Tags","summary":"","title":"Softwareentwicklung","type":"tags"},{"content":"","date":"14 March 2026","externalUrl":null,"permalink":"/en/tags/big-tech/","section":"Tags","summary":"","title":"Big Tech","type":"tags"},{"content":"","date":"14. March 2026","externalUrl":null,"permalink":"/de/tags/investitionen/","section":"Tags","summary":"","title":"Investitionen","type":"tags"},{"content":"","date":"14 March 2026","externalUrl":null,"permalink":"/en/tags/investment/","section":"Tags","summary":"","title":"Investment","type":"tags"},{"content":" Summary # The NZZ article examines how tech giants like Meta, OpenAI, and Nvidia are now pouring billions into AI agents after already spending massive amounts on large language models. Meta acquired Moltbook (a \u0026ldquo;social network for AI bots\u0026rdquo;) and spent $2 billion on Manus. OpenAI acquired Openclaw for its autonomous AI agents. Critics see this as a \u0026ldquo;flight forward,\u0026rdquo; with companies investing even more money to solve the problem of poor returns on their LLM investments.\nThe article explores whether AI agents can deliver on their promise to automate knowledge work, or whether this is another investment wave that will never pay off.\nMy Quotes # On Meta\u0026rsquo;s acquisition of Moltbook:\n\u0026ldquo;On Moltbook, there are hundreds of thousands of fake profiles. Behind the supposed 1.5 million AI agents, there are only around 17,000 human owners. It is primarily a social experiment.\u0026rdquo;\nOn why Meta still sees value in Moltbook:\n\u0026ldquo;Moltbook is simultaneously a registration platform for AI agents. When these agents act on behalf of a human, they also need a unique identity.\u0026rdquo;\nOn the emerging \u0026ldquo;Know Your Agent\u0026rdquo; requirement, similar to Know Your Customer in banking, and the race to build agent identity infrastructure.\nOn AI agent payments:\n\u0026ldquo;This will be the next big topic.\u0026rdquo;\nCompanies from Mastercard to Visa, PayPal, and Coinbase are developing payment solutions for AI agents, including micropayments via stablecoins.\nOn why tech companies keep investing despite poor returns:\n\u0026ldquo;The technology companies are in a kind of hamster wheel that they don\u0026rsquo;t dare to step out of. They don\u0026rsquo;t want to risk becoming the next Nokia.\u0026rdquo;\nRead the full article on NZZ\n","date":"14 March 2026","externalUrl":null,"permalink":"/en/publications/nzz-ai-agents-investment-race/","section":"Publications","summary":"Summary # The NZZ article examines how tech giants like Meta, OpenAI, and Nvidia are now pouring billions into AI agents after already spending massive amounts on large language models. Meta acquired Moltbook (a “social network for AI bots”) and spent $2 billion on Manus. OpenAI acquired Openclaw for its autonomous AI agents. Critics see this as a “flight forward,” with companies investing even more money to solve the problem of poor returns on their LLM investments.\n","title":"NZZ: The Great Flight Forward into AI Agents","type":"publications"},{"content":"","date":"14 March 2026","externalUrl":null,"permalink":"/en/tags/platform-economy/","section":"Tags","summary":"","title":"Platform Economy","type":"tags"},{"content":"","date":"14. March 2026","externalUrl":null,"permalink":"/de/tags/plattform%C3%B6konomie/","section":"Tags","summary":"","title":"Plattformökonomie","type":"tags"},{"content":"","date":"25 February 2026","externalUrl":null,"permalink":"/en/tags/agentic-enterprise/","section":"Tags","summary":"","title":"Agentic Enterprise","type":"tags"},{"content":"","date":"25 February 2026","externalUrl":null,"permalink":"/en/tags/ai-transformation/","section":"Tags","summary":"","title":"AI Transformation","type":"tags"},{"content":"","date":"25 February 2026","externalUrl":null,"permalink":"/en/tags/business-value/","section":"Tags","summary":"","title":"Business Value","type":"tags"},{"content":"Obwohl sich KI schnell weiterentwickelt hat, sind viele Organisationen nicht im gleichen Tempo nachgezogen. Den meisten Führungskräften, mit denen wir sprechen, mangelt es nicht an Ideen, Proof-of-Concepts oder Anbieter-Demos. Die Herausforderung besteht darin, KI in etwas Reproduzierbares zu überführen: in eine Fähigkeit, der man vertrauen kann, die sich skalieren und steuern lässt, ohne neue Risiken oder Engpässe zu schaffen.\nDiese Lücke bildet den Ausgangspunkt für dieses Gespräch zwischen Romano Roth, Prof. Dr. Oliver Gassmann und der Moderatorin Prof. Dr. Naomi Haefner. Sie beleuchten, was agentische KI für Unternehmen tatsächlich bedeutet, wo sie heute bereits funktioniert und was Organisationen verändern müssen, bevor sie sie skalieren können.\nDie Diskussion macht eine produktive Spannung sichtbar: Oliver, der sich auf seinen Forschungsartikel \u0026ldquo;The Non-Human Enterprise\u0026rdquo; stützt, treibt die Idee vollständig autonomer, agentengetriebener Organisationen als radikales Gedankenexperiment voran. Romano hingegen argumentiert, dass reale Unternehmen sozio-technische Systeme sind, die menschliche Steuerung, Feedback-Schleifen und kontinuierliche Anpassung benötigen. Wo sie übereinstimmen, ist ebenso aufschlussreich wie die Punkte, in denen sie unterschiedlicher Meinung sind.\nLernen Sie die Referenten kennen # Romano Roth ist Global Chief of Cybernetic Transformation und Partner bei Zühlke. Er gestaltet die globale Strategie von Zühlke für cybernetische Transformation, Platform Engineering und KI-Integration.\nProf. Dr. Oliver Gassmann ist Professor für Technologiemanagement an der Universität St. Gallen sowie Vice Chairman und Partner bei Zühlke. Er bringt umfassende Expertise im Innovationsmanagement und in der Führung mit, die erforderlich ist, um Transformation nachhaltig zu verankern.\nProf. Dr. Naomi Haefner ist Assistenzprofessorin für Technologiemanagement an der Universität St. Gallen. Sie erforscht, wie aufkommende Technologien Organisationen, Entscheidungsfindung und Managementpraktiken verändern.\nDas agentische Unternehmen: ein radikales Gedankenexperiment # Oliver definiert das agentische Unternehmen als die ultimative Vision einer vollständig automatisierten Organisation: KI-Agenten mit klar beschriebenen Zielen und Werkzeugen, die planen, ausführen und zusammenarbeiten, ähnlich wie die „Dark Factories\u0026quot;, die wir bereits in der Fertigung sehen. Er treibt diese Idee bewusst auf die Spitze: „Wenn wir eine globale Versicherungsgesellschaft auf der grünen Wiese mit nur fünf Menschen entwerfen würden, wie würde sie aussehen?\u0026quot;\nRomano setzt den Gegenpunkt. Während man ein agentisches Unternehmen vielleicht für einen Online-Shop aufbauen könnte, der schwarze Socken verkauft, ist ein globaler Versicherungsanbieter eine ganz andere Größenordnung. Reale Unternehmen sind komplexe sozio-technische Systeme mit Feedback-Schleifen, regulatorischen Vorgaben und menschlichem Urteilsvermögen im Kern. Die heutigen KI-Agenten bewältigen zuverlässig fünf bis sieben Schritte autonom, danach muss ein Mensch eingreifen.\nDiese Spannung zwischen radikaler Automatisierung als Gedankenexperiment und einer pragmatischen, menschlich geführten Transformation zieht sich durch die gesamte Diskussion, und macht ihren besonderen Wert aus.\nWo KI-Agenten heute Mehrwert schaffen # Oliver teilt ein überzeugendes Beispiel aus der Telekommunikationsbranche. Autonome Netzwerkagenten überwachen Funkzugangsnetze und reagieren in Echtzeit auf ungeplante Ereignisse, ein Festival, einen Stau, eine Demonstration.\nDieser innovative Ansatz führt dazu, dass das, wofür zuvor ein Team von Ingenieuren eine Stunde benötigte, nun autonom in acht Minuten und mit besserer Performance geschieht.\nBeide Sprecher bezeichnen solche Anwendungsfälle als „agentische Inseln\u0026quot;: klar abgegrenzte, gut verstandene Domänen, in denen Automatisierung eindeutige und messbare Vorteile liefert. Die Herausforderung besteht darin, diese Inseln zu durchgängigen End-to-End-Wertströmen zu verbinden.\nWarum die meisten KI-Initiativen enttäuschen # Beide Sprecher sind sehr direkt, warum so viele Organisationen scheitern: Sie setzen KI einfach auf bestehende Prozesse drauf und erwarten dann magische Ergebnisse.\nRomanos Diagnose ist treffend: Der aktuelle Fokus auf generative KI-Tools (welcher Anbieter, welches LLM) lenkt von der eigentlichen Arbeit ab. „Geht weg vom Tool selbst. Denkt daran, Prozesse und Engpässe zu identifizieren.\u0026quot; Seine empfohlene Methode ist Value Stream Mapping, eine Technik aus dem Toyota-Produktionssystem. Das bedeutet: jeden Schritt abbilden, Prozesszeit, Durchlaufzeit und Fertigstellungsgrad analysieren, und erst dann den Soll-Zustand entwerfen. Manchmal beinhaltet dieser Soll-Zustand nicht einmal KI.\nOliver ergänzt eine strukturelle Beobachtung: Die meisten europäischen Unternehmen denken noch immer in Strategiezyklen aus der Hardware-Ära. In der Automobilindustrie plant man rund um „SOP minus drei\u0026quot;, also drei Jahre vor Produktionsstart. Doch KI-Frameworks verändern sich alle drei bis vier Monate, und die Inferenzkosten sinken pro Jahr um das 900-Fache. Strategie als starrer Plan muss durch den Aufbau strategischer Flexibilität ersetzt werden.\nEin Framework zur Entscheidung, was transformiert werden soll # Romano nutzt bei der Beratung von Unternehmen ein praxisnahes Zwei-Achsen-Framework:\nDaraus entstehen vier Quadranten, die Teams dabei helfen, ihre aktuelle Arbeit einzuordnen und zu entscheiden, wohin sie sich entwickeln wollen. Das eigentliche Denken dahinter, jeden Prozessschritt zu prüfen und zu entscheiden, ob man ihn verändert, automatisiert oder beibehält, haben die meisten Organisationen bislang noch nicht geleistet. Ohne diese Vorarbeit ist KI nur eine teure Ergänzung zu einem kaputten Prozess.\nZentrale Erkenntnisse aus dem Gespräch # Ein durchgängiges Thema ist, dass KI Urteilsvermögen und Ausführung verbessern kann, fehlende Klarheit jedoch nicht ersetzt. Wenn Ziele nicht klar definiert sind, Verantwortlichkeiten unklar bleiben oder Teams nicht den nötigen Handlungsspielraum haben, kann KI allein das nicht beheben.\nRomano verdeutlicht das mit einer warnenden Geschichte: Ein Bachelorstudent lieferte ausgefeilte, KI-generierte Folien zum Kubernetes-Zertifikatsmanagement, konnte jedoch keine der Lösungen erklären, und auch nicht, warum eine auf der anderen aufbaute. „Nutzt KI, absolut, aber ihr müsst die Arbeit selbst verantworten. Ihr müsst sie verstehen\u0026quot;, sagt Romano. Das ist eine Führungsaufgabe: sicherzustellen, dass Menschen Verantwortung für KI-generierte Ergebnisse übernehmen.\nOliver bringt es klar auf den Punkt: „Beginnt mit der Strategie, die Technologie kommt an zweiter Stelle.\u0026quot; Bevor man in die Technologie einsteigt, müssen mehrere Fragen geklärt werden, zum Beispiel: Wo differenzieren wir uns? Wie ist unsere Positionierung aus Kundensicht?\nKI ist der zweite oder dritte Schritt, aber niemals der erste. Oliver ergänzt zwei weitere Voraussetzungen: Silos aufbrechen und funktionsübergreifende Teams bilden (weil End-to-End-Lösungen das erfordern) sowie echte KI-Kompetenz aufbauen (nicht nur Copilot ausrollen und Logins zählen).\nDer Punkt der KI-Kompetenz ist sehr praxisnah: Oliver beobachtet, dass Führungskräfte sich über hohe Nutzungszahlen freuen, die tatsächliche Anwendung jedoch oft oberflächlich bleibt. Echte Produktivitätsgewinne erfordern ein Verständnis dafür, was KI kann und was nicht, und die Messung von Ergebnissen statt nur von Aktivität.\nWenn Systeme vom Unterstützen zum Handeln übergehen, darf Vertrauen kein nachträglicher Gedanke sein. Es braucht klare Grenzen: Was die KI entscheiden darf, was eskaliert werden muss, was protokolliert wird und wie man Drift erkennt.\nStatt mehrjähriger Programme setzen beide Referenten auf kurze, gut instrumentierte Feedback-Schleifen. Das ist der Kern des Cybernetic-Enterprise-Ansatzes.\n„Ihr müsst zu einem Unternehmen werden, das wahrnimmt, lernt und sich kontinuierlich anpasst. Ein-, Zwei- oder Fünfjahrespläne funktionieren nicht mehr.\u0026quot; - Romano Roth\nOliver stimmt zu und formuliert es neu: Das Ziel ist ein datengetriebenes Unternehmen. Gleichzeitig bleibt er realistisch: Viele „AI-first\u0026quot;-Initiativen werden schnell zu Datenintegrationsprojekten, weil die Daten schlicht nicht in der richtigen Qualität vorhanden sind.\nVon Menschen geführt, KI-gestützt # Oliver beziffert das Tempo des Wandels: Selbst wenn man nur von einer moderaten Verzehnfachung der KI-Fähigkeiten pro Jahr ausgeht, entspricht das einer 10.000-fachen Verbesserung in vier Jahren. Für jedes Unternehmen, das in einem Fünfjahreshorizont denkt, sind die Auswirkungen enorm. „Wir werden radikal neue Lösungen sehen, sogar solche, die wir uns heute noch nicht vorstellen können\u0026quot;, sagt er.\nRomanos Vision für die nahe Zukunft ist ebenso kühn: KI wird direkt auf Daten arbeiten und Middleware, APIs sowie klassische Benutzeroberflächen überflüssig machen. Die Interaktion wird konversationell erfolgen (durch Tippen oder Sprechen), und die KI wird unmittelbar auf den Daten operieren. „Das ganze Thema Benutzeroberflächen, Apps, Middleware, all das wird verschwinden.\u0026quot;\nBeide Referenten vergleichen diesen Moment mit den 1990er-Jahren, als niemand die spätere App-Ökonomie vorhergesehen hat. Der Möglichkeitsraum ist real, aber ebenso die Disruption, insbesondere für Berufseinsteigerinnen und -einsteiger, die neu in den Arbeitsmarkt kommen.\nWas als Nächstes zu tun ist # Den Wertstrom abbilden. Wählen Sie einen durchgängigen End-to-End-Prozess. Nutzen Sie Value Stream Mapping, um Engpässe zu identifizieren: Prozesszeit, Durchlaufzeit, Fertigstellungsgrad und Korrekturschleifen. Entwerfen Sie den zukünftigen Soll-Zustand. KI kann Teil der Lösung sein, muss es aber nicht. Beginnen Sie mit Effizienzgewinnen und gehen Sie erst dann zur Customer Journey über, wenn sich der Ansatz bewährt hat.\nVertrauensgrenzen setzen. Definieren Sie klare Entscheidungsgrenzen, Eskalationswege, Monitoring und Rollback-Mechanismen. Das Telekom-Beispiel zeigt, dass ein Guardian-Agent essenzielle Infrastruktur ist, kein optionales Zusatzmodul.\nDie Plattform aufbauen. Standardisieren Sie Muster für sicheren Datenzugriff, Modellintegration, Deployment und Observability. Bauen Sie Governance direkt in die KI-Plattform ein, damit Teams schnell vorankommen können, ohne Vertrauen zu gefährden. Genau das unterscheidet Unternehmen, die skalieren, von denen, die nur Demos anhäufen.\nKI-Mehrwert entsteht nicht durch das Ausrollen von Modellen. Er entsteht durch die Gestaltung einer Organisation, die in Echtzeit lernen und liefern kann, mit den richtigen Feedback-Schleifen, Fundamenten und Governance-Strukturen.\nDieser Artikel wurde ursprünglich auf Zühlke Insights veröffentlicht.\n","date":"25. February 2026","externalUrl":null,"permalink":"/de/blogs/der-aufstieg-des-agentic-enterprise-die-rolle-der-ki-bei-der-unternehmenstransformation/","section":"Blogs","summary":"Obwohl sich KI schnell weiterentwickelt hat, sind viele Organisationen nicht im gleichen Tempo nachgezogen. Den meisten Führungskräften, mit denen wir sprechen, mangelt es nicht an Ideen, Proof-of-Concepts oder Anbieter-Demos. Die Herausforderung besteht darin, KI in etwas Reproduzierbares zu überführen: in eine Fähigkeit, der man vertrauen kann, die sich skalieren und steuern lässt, ohne neue Risiken oder Engpässe zu schaffen.\n","title":"Der Aufstieg des Agentic Enterprise: Die Rolle der KI bei der Unternehmenstransformation","type":"blogs"},{"content":"","date":"25. February 2026","externalUrl":null,"permalink":"/de/tags/digitale-transformation/","section":"Tags","summary":"","title":"Digitale Transformation","type":"tags"},{"content":"","date":"25. February 2026","externalUrl":null,"permalink":"/de/tags/f%C3%BChrung/","section":"Tags","summary":"","title":"Führung","type":"tags"},{"content":"","date":"25. February 2026","externalUrl":null,"permalink":"/de/tags/ki-transformation/","section":"Tags","summary":"","title":"KI-Transformation","type":"tags"},{"content":"","date":"25 February 2026","externalUrl":null,"permalink":"/en/tags/leadership/","section":"Tags","summary":"","title":"Leadership","type":"tags"},{"content":"Although AI has moved fast, many organisations haven\u0026rsquo;t. Most leaders we speak to aren\u0026rsquo;t short on ideas, proofs of concept, or vendor demos. The challenge is turning AI into something repeatable, a capability you can trust, scale, and steer without creating new risks or bottlenecks.\nThat gap is the starting point for this conversation between Romano Roth, Prof. Dr. Oliver Gassmann, and moderator Prof. Dr. Naomi Haefner. They explore what agentic AI actually means for the enterprise, where it works today, and what organisations need to change before they can scale it.\nThe discussion surfaces a productive tension. Oliver, drawing on his research article \u0026ldquo;The Non-Human Enterprise\u0026rdquo;, pushes the idea of fully autonomous, agent-driven organisations as a radical thought experiment. Romano argues that real enterprises are socio-technical systems that need human-led steering, feedback loops and continuous adaptation. Where they converge is just as revealing as where they disagree.\nMeet the speakers # Romano Roth is the Global Chief of Cybernetic Transformation and a Partner at Zühlke. Romano shapes Zühlke\u0026rsquo;s global strategy for cybernetic transformation, platform engineering and AI integration.\nProf. Dr. Oliver Gassmann is a Professor of Technology Management at University of St. Gallen and Vice Chairman and Partner at Zühlke. He brings deep expertise in innovation management and the leadership required to make transformation stick.\nProf. Dr. Naomi Haefner is an Assistant Professor of Technology Management at University of St. Gallen. Naomi researches how emerging technologies reshape organisations, decision-making and management practices.\nThe agentic enterprise: a radical thought experiment # Oliver defines the agentic enterprise as the ultimate vision of a fully automated organisation: AI agents with described goals and tools that plan, execute, and collaborate, similar to the \u0026ldquo;dark factories\u0026rdquo; we already see in manufacturing. He pushes the idea to its extreme: \u0026ldquo;If we were to design a global insurance company on a green field with just five people, what would it look like?\u0026rdquo;\nRomano brings the counterpoint. While you could build an agentic enterprise for an online shop that sells black socks, a global insurance provider is a different matter entirely. Real enterprises are complex socio-technical systems with feedback loops, regulatory constraints and human judgement at their core. Today\u0026rsquo;s AI agents reliably handle five to seven steps autonomously, but then a human needs to step in.\nThis tension between radical automation as a thought experiment and pragmatic, human-led transformation runs through the entire discussion and is what makes it valuable.\nWhere AI agents deliver value today # Oliver shares a compelling example from the telecom industry. Autonomous network agents monitor radio access networks and respond to unplanned events, a festival, a traffic jam, a demonstration, in real time.\nThis innovative approach means that what previously took a team of engineers one hour now happens autonomously in eight minutes and with better performance.\nThese are what both speakers call \u0026ldquo;agentic islands\u0026rdquo;: bounded, well-understood domains where automation delivers clear, measurable gains. The challenge is connecting these islands into end-to-end value streams.\nWhy most AI initiatives disappoint # Both speakers are blunt about why so many organisations struggle: they add AI onto existing processes and expect magical results.\nAccording to Romano, the current focus on generative AI tools (which vendor, which LLM) distracts from the real work. \u0026ldquo;Go away from the tool itself. Think about identifying processes and bottlenecks.\u0026rdquo; His recommended method is value stream mapping, a technique from the Toyota Production System. This means mapping every step, and analysing process time, lead time, percentage complete and correcting it; and only then designing the future state. Sometimes that future doesn\u0026rsquo;t even involve AI.\nAs Oliver points out, most European companies still think of hardware-era strategy cycles. The automotive industry plans around SOP minus three, three years before starting production. But AI frameworks change every three to four months and inference costs drop by 900x per year. Strategy as a plan has to be replaced with creating strategic flexibility.\nA framework for deciding what to transform # Romano uses a practical two-axis framework when advising companies:\nThis produces four quadrants that help teams map their current work and decide where to move. The thinking itself, examining every process step and deciding whether to change it, automate it, or leave it, is what most organisations haven\u0026rsquo;t done yet. Without it, AI is just an expensive addition to a broken process.\nHighlights from the conversation # A consistent theme is that AI can enhance judgement and execution, but it can\u0026rsquo;t compensate for missing clarity. If the goals aren\u0026rsquo;t defined, accountability is unclear, or teams don\u0026rsquo;t have the encouragement to act, AI alone won\u0026rsquo;t be able to fix it.\nRomano illustrates this with a cautionary story. A bachelor thesis student delivered polished, AI-generated slides on Kubernetes certificate management, but couldn\u0026rsquo;t explain any of the solutions or why one built on another. \u0026ldquo;Use AI, absolutely, but you need to own the work. You need to understand it,\u0026rdquo; says Romano. This is a leadership responsibility: ensuring that people take ownership of AI-generated results.\n\u0026ldquo;Start with strategy, tech comes second,\u0026rdquo; insists Oliver. There are several questions that must be asked before going into the tech, such as: Where do we differentiate? What\u0026rsquo;s our positioning from a customer perspective?\nAI is the second or third step, but it should never be the first. Oliver adds two more preconditions: break down silos into cross-functional teams (because end-to-end solutions require it) and build genuine AI literacy (not just rolling out Copilot and counting logins).\nThe AI literacy point is practical. Oliver sees executives excited about high adoption numbers, but the actual usage is basic. Real productivity gains require understanding what AI can and can\u0026rsquo;t do and measuring outcomes instead of only activity.\nWhen systems move from assisting to acting, trust can\u0026rsquo;t be an afterthought. You need explicit boundaries: what the AI can decide, what must be escalated, what gets logged, and how you detect drift.\nRather than multi-year programmes, both speakers lean into short, instrumented loops. This is the core of the Cybernetic Enterprise approach.\n\u0026ldquo;You need to become a company which senses and learns and continuously adapts. You can\u0026rsquo;t do any more one-year or two-year or five-year plans.\u0026rdquo; - Romano Roth\nOliver agrees and reframes it. The ultimate goal is becoming a truly data-driven company. But he\u0026rsquo;s also realistic. He believes many \u0026ldquo;AI-first\u0026rdquo; initiatives quickly turn into data integration projects, because the data simply isn\u0026rsquo;t there in the right quality.\nHuman-led, AI-enabled # Oliver puts a number on the pace of change: even assuming a modest 10x improvement per year in AI capabilities, that\u0026rsquo;s 10,000x in four years. For any company thinking on a five-year horizon, the implications are enormous. \u0026ldquo;We will see radically new solutions, things we couldn\u0026rsquo;t have thought of,\u0026rdquo; he says.\nRomano\u0026rsquo;s vision for the near future is equally bold: AI will work directly on data, making middleware, APIs, and traditional user interfaces unnecessary. Interaction will be conversational (by either typing or speaking), and the AI will operate on the data directly. \u0026ldquo;The whole thing about user interfaces, apps, middleware; all this will be gone.\u0026rdquo;\nBoth speakers compare this moment to the 1990s, when no one predicted the app economy that would follow. The opportunity space is real, but so is the disruption, particularly for inexperienced workers entering the job market.\nWhat to do next # Map the value stream. Pick one end-to-end flow. Use value stream mapping to identify bottlenecks: process time, lead time, percentage complete and correct. Design the future state. AI may or may not be part of the solution. Start with efficiency gains; move to the customer journey once you\u0026rsquo;ve proven the approach.\nSet trust boundaries. Be explicit about decision boundaries, escalation paths, monitoring and rollback. The telecom example shows that a guardian agent is essential infrastructure, not an optional add-on.\nBuild the platform. Standardise patterns for secure data access, model integration, deployment and observability. Build governance into the AI platform so teams can move fast without breaking trust. This is what separates companies that scale from companies that accumulate demos.\nAI value doesn\u0026rsquo;t come from deploying models. It comes from designing an organisation that can learn and deliver in real time, with the right feedback loops, foundations, and governance in place.\nThis article was originally published on Zühlke Insights.\n","date":"25 February 2026","externalUrl":null,"permalink":"/en/blogs/the-rise-of-the-agentic-enterprise-ais-role-in-business-transformation/","section":"Blogs","summary":"Although AI has moved fast, many organisations haven’t. Most leaders we speak to aren’t short on ideas, proofs of concept, or vendor demos. The challenge is turning AI into something repeatable, a capability you can trust, scale, and steer without creating new risks or bottlenecks.\n","title":"The Rise of the Agentic Enterprise: AI's Role in Business Transformation","type":"blogs"},{"content":"","date":"18 February 2026","externalUrl":null,"permalink":"/en/tags/feedback-loops/","section":"Tags","summary":"","title":"Feedback Loops","type":"tags"},{"content":" To stay competitive, companies need a radical upgrade. The Cybernetic Enterprise transforms organizations into learning systems that adapt faster than their market changes.\nDigital transformation and agility were long considered promises of the future. Today, the reality is clear: they are no longer enough. Many companies believe they can secure their competitiveness with a bit of agility and a few quick AI pilot projects. But anyone who merely grafts artificial intelligence onto outdated structures will fail. What is needed is a radical upgrade of the operating model.\nScrum meetings, colorful Kanban boards, and flashy innovation labs create the feeling of agility. At the same time, companies are investing heavily in AI, hoping for quick efficiency gains. Disillusionment often follows promptly: the expected ROI fails to materialize. AI does not heal dysfunctional organizations, fix broken processes, or replace clear strategic direction. Anyone who believes a language model can reinvent a business model without fundamental change underestimates the challenge.\nThe real problem runs deeper: the organizational \u0026ldquo;operating system\u0026rdquo; of many companies is outdated. Instead of building a new one, they keep optimizing the old. After two decades of digitalization, many are more efficient, but only in isolated pockets, within silos and disconnected processes. This \u0026ldquo;more of the same\u0026rdquo; acts like a painkiller: symptoms are relieved, but root causes persist. In the era of AI, this is fatal. Agility limited to individual teams or innovation projects falls short when systemic adaptability is required.\nCybernetic Enterprise: the Operating Model of Tomorrow # What is needed is a fundamental rethink: the Cybernetic Enterprise is both an operating model and a mindset. The term derives from the Greek \u0026ldquo;kybernetes\u0026rdquo; (helmsman) and describes organizations as dynamic systems capable of learning and self-regulation through feedback loops. Organization, processes, and technology work as an intelligent whole, comparable to a nervous system that continuously processes information and translates it into action.\nA Cybernetic Enterprise is not optimized for short-term efficiency but for long-term adaptability, resilience, and sustainable value creation. Decisions are systematically based on data, teams act decentrally along shared principles, and the technology platform enables continuous evolution. AI is no longer an isolated tool but an integral part of the organizational DNA.\nWhat matters most is the vertical alignment of all layers: from purpose and strategy through values and processes to tools and technologies. This layered mental model creates coherence, a fundamental prerequisite for achieving real impact with AI. Without clarity in data, decisions, and collaboration, every AI initiative remains patchwork.\nThe goal is clear: an organization that learns faster than its market changes and thereby remains viable in the long term.\nThree Core Principles # 1. Organization Along the Value Stream # Instead of functional silos, the end-to-end value stream takes center stage. Value stream mapping reveals bottlenecks and enables seamless automation. AI can handle routine decisions while humans focus on complex cases. Customer centricity and continuous user feedback shorten learning cycles and reduce risk.\n2. Empowered Teams Instead of Hierarchy # Decisions are made where the knowledge resides. Teams carry end-to-end responsibility and operate within clear guardrails. Leadership provides context instead of control. This requires new competencies, from systems thinking and data literacy to ethical responsibility in dealing with AI.\n3. Data-Driven Decisions and Continuous Learning # Data and feedback replace gut feeling and rigid annual plans. \u0026ldquo;Telemetry everywhere\u0026rdquo; makes organizations capable of acting early. Success is no longer measured by output but by flow and outcome metrics. Continuous experiments, short feedback loops, and \u0026ldquo;safe to fail\u0026rdquo; approaches turn the company into a learning system.\nFrom Theory to Practice # An internal platform as the technical backbone provides infrastructure, data, automation, and AI services in a standardized way, including integrated governance. Continuous improvement becomes the new normal. And above all: transformation is a leadership mandate. The CEO acts as Chief Evangelist, communicating purpose and urgency, removing obstacles, and visibly embodying the change.\nConclusion # The path to a Cybernetic Enterprise is not an overnight revolution but a consistent evolution. Yet it must begin now. \u0026ldquo;Business as usual, just with AI\u0026rdquo; is not enough. Digitalization was yesterday. Today, it is about cybernetic transformation: the company as a living, learning system in which humans and machines work together intelligently. Those who holistically orchestrate organization, technology, and processes will not just survive the AI wave, they will shape it.\nRead the full article on it-daily.net\n","date":"18 February 2026","externalUrl":null,"permalink":"/en/publications/it-daily-cybernetic-enterprise/","section":"Publications","summary":" To stay competitive, companies need a radical upgrade. The Cybernetic Enterprise transforms organizations into learning systems that adapt faster than their market changes.\n","title":"How Companies Become a Cybernetic Enterprise","type":"publications"},{"content":"","date":"18 February 2026","externalUrl":null,"permalink":"/en/tags/operating-model/","section":"Tags","summary":"","title":"Operating Model","type":"tags"},{"content":"2026 will be the year when the wheat is separated from the chaff in AI: it\u0026rsquo;s not the better model that makes the difference, but the ability to deliver impact under real-world conditions. What decision-makers need to know and do now so that AI evolves from experiment to true partner.\nIs Artificial Intelligence (AI) at a turning point? A clear yes, because several forces are acting simultaneously and creating momentum. Capital and budgets are coming into sharper focus, governance and liability are moving from theory to implementation, and expectations of what AI should deliver are shifting from assistance to execution. In parallel, new use cases are emerging that have zero tolerance for \u0026ldquo;roughly right.\u0026rdquo; They range from core processes to security to physical environments where errors can be expensive and dangerous.\nA look at the most important AI trends of the year reveals which strategic decisions are critical for enterprises now.\n1. The AI Bubble Bursts (Very Likely) # Will the AI hype continue unchecked? There are growing signs of a possible correction, not because AI \u0026ldquo;fails,\u0026rdquo; but because the global economy could falter. In such an environment, capital markets reassess AI investments: a stressed yield curve has historically often signaled recession. And the high market concentration of the \u0026ldquo;Magnificent 7\u0026rdquo; increases index risk. The technology will continue to evolve, but companies should prepare for a possible valuation reset that is primarily macroeconomically driven.\n2. Local Models Become Standard # Many companies are currently reorganizing their AI architectures: away from pure cloud dependency, toward hybrid setups combining local, sovereignly hosted, and external models. This is not a matter of ideology but necessary risk management. Data residency, compliance requirements, geopolitical tensions, export controls, and demanding requirements for latency, availability, and predictable inference costs are changing the standard. The goal is a platform that operates a portfolio of models, not a single universal model.\n3. The Future Is the \u0026ldquo;Cybernetic Enterprise\u0026rdquo;, Including the \u0026ldquo;Cybernetic Platform\u0026rdquo; # Layering AI as a tool on top of existing silos primarily scales complexity and disappointment. The central strategic lever going forward is different: a new \u0026ldquo;operating system\u0026rdquo; for the entire organization. The \u0026ldquo;Cybernetic Enterprise\u0026rdquo; describes a continuously adaptive organization steered through closed feedback loops, AI-augmented intelligence, and autonomous, cross-functional teams. It connects strategy with operational execution through real-time data, transparency, and rapid iteration.\nThe core is simple but uncomfortable: feedback must be designed to change behavior. This means continuous signals from customers, operations, risk, and value contribution. For this to work, organizations need a \u0026ldquo;Cybernetic Platform\u0026rdquo; as a non-negotiable foundation: self-service, policy-as-code, observability, embedded AI services, and platform product thinking, so teams can deliver quickly, safely, and autonomously.\n4. AI-Native Software Development Becomes the Benchmark # The bottleneck is no longer code. It\u0026rsquo;s about controllability. Generative AI drastically lowers the entry barrier, but it doesn\u0026rsquo;t replace responsibility. What matters is a new role profile: the AI-native engineer. They don\u0026rsquo;t just use AI as a copilot. They build a controllable engineering system: with clear guardrails, measurable quality, and automated feedback loops.\n5. \u0026ldquo;Physical AI\u0026rdquo; Steps Into Reality # 2026 marks the point where AI no longer just optimizes text, images, and processes but acts: in factories, logistics centers, hospitals, and energy and infrastructure networks. \u0026ldquo;Physical AI\u0026rdquo; refers to learning, adaptive AI systems that perceive, understand, decide, and interact in real-time in physical space. This is no longer a distant prospect. Market conditions are forcing European companies to catch up soon.\n6. The Next (Self-Made) Skill Shortage Is Coming # Many layoffs in 2025 were prematurely labeled as \u0026ldquo;AI replacing jobs.\u0026rdquo; A convenient efficiency narrative, but often not the actual cause: after post-pandemic over-hiring, higher cost pressure, a cooling labor market, and additional macroeconomic factors are increasingly taking effect. At the same time, AI competency is gaining relevance in the skill mix. The consequence for decision-makers: if fewer capable junior talent is hired in 2025/2026, the talent pipeline will be missing in 2027/2028.\n7. AI Agents Become Productive # Remember: 2025 was declared the \u0026ldquo;Year of AI Agents.\u0026rdquo; The reality was sobering. A field study by Cornell University found that roughly 95 percent of agent deployments failed. What matters in 2026, therefore, is not more autonomy but more engineering. Winners build agents into products and processes, treating them like production software: with clear ownership, measurable, observable, secured, and killable. Demos are dead. Proof of value wins.\n8. AI Evolves Into Companion and Mentor # In 2026, AI shifts from a pure productivity function to a relationship function. In education, care, nursing, and workforce development, systems are emerging that provide encouragement, personalized feedback, and simulated social interaction. The catch: companion AI can reinforce psychological dependencies, manipulate deliberately, or normalize disinformation. The EU AI Act targets exactly this direction. The imperative for decision-makers: anyone seriously deploying AI mentors (including for CIOs) needs digital emotional safety standards, before rollout, not after.\nConclusion # The trends are clear: AI is becoming an operational discipline. First, AI needs a real production system (no more pilots). Second, risk and cost management become a design task. Third, the organization\u0026rsquo;s operating model determines scalability. Feedback must trigger behavior change, teams must be able to deliver autonomously, and skills must grow along new roles and guardrails.\n2026 won\u0026rsquo;t be won by those with the most AI, but by those who operate AI most reliably.\nOriginally published on it-daily.net (German)\n","date":"3 February 2026","externalUrl":null,"permalink":"/en/publications/it-daily-ki-orakel-2026-trends/","section":"Publications","summary":"2026 will be the year when the wheat is separated from the chaff in AI: it’s not the better model that makes the difference, but the ability to deliver impact under real-world conditions. What decision-makers need to know and do now so that AI evolves from experiment to true partner.\n","title":"AI Oracle 2026: The Most Important Trends for Decision-Makers","type":"publications"},{"content":"","date":"18 January 2026","externalUrl":null,"permalink":"/en/tags/aleph-alpha/","section":"Tags","summary":"","title":"Aleph Alpha","type":"tags"},{"content":"","date":"18 January 2026","externalUrl":null,"permalink":"/en/tags/cloud/","section":"Tags","summary":"","title":"Cloud","type":"tags"},{"content":"","date":"18 January 2026","externalUrl":null,"permalink":"/en/tags/digital-infrastructure/","section":"Tags","summary":"","title":"Digital Infrastructure","type":"tags"},{"content":"","date":"18. January 2026","externalUrl":null,"permalink":"/de/tags/digitale-infrastruktur/","section":"Tags","summary":"","title":"Digitale Infrastruktur","type":"tags"},{"content":"","date":"18. January 2026","externalUrl":null,"permalink":"/de/tags/europ%C3%A4ische-souver%C3%A4nit%C3%A4t/","section":"Tags","summary":"","title":"Europäische Souveränität","type":"tags"},{"content":"","date":"18 January 2026","externalUrl":null,"permalink":"/en/tags/european-sovereignty/","section":"Tags","summary":"","title":"European Sovereignty","type":"tags"},{"content":" Summary # The NZZ article examines how Aleph Alpha, once celebrated as \u0026ldquo;Europe\u0026rsquo;s OpenAI,\u0026rdquo; is pivoting from developing its own large language model to becoming a service provider for the Schwarz Group (owner of Lidl). While some see this as a setback, experts view it as a strategic opportunity: building sovereign European cloud infrastructure may have far more potential than competing in the AI model race dominated by US and Chinese companies.\nThe Schwarz Group\u0026rsquo;s Stackit cloud positions itself as a \u0026ldquo;sovereign cloud for Europe,\u0026rdquo; capitalizing on growing European distrust of US cloud providers and concerns about data sovereignty.\nMy Quotes # \u0026ldquo;I find it completely understandable that the main investor pushed Aleph Alpha to shift focus away from its own language model. Building a sovereign European cloud has far more potential.\u0026rdquo;\nOn the shift in European trust towards US providers:\n\u0026ldquo;The world has completely changed in this regard within just a few years. European companies no longer have any trust in US rule of law, and thus no trust in American cloud providers.\u0026rdquo;\nOn what US cloud providers would need to do:\n\u0026ldquo;They will only be able to win new customers if they legally completely separate their European subsidiaries from the parent company in the USA.\u0026rdquo;\nOn what matters most for enterprise AI:\n\u0026ldquo;For companies, it\u0026rsquo;s much more important that they can use AI in a way that keeps their data and trade secrets secure, and that they can understand the results.\u0026rdquo;\nOn the future of Aleph Alpha:\n\u0026ldquo;I could well imagine that there will ultimately be a merger between the Schwarz Group and Aleph Alpha. Because in a few years, AI will no longer be anything extraordinary, but simply part of normal IT infrastructure.\u0026rdquo;\nRead the full article on NZZ\n","date":"18 January 2026","externalUrl":null,"permalink":"/en/publications/nzz-aleph-alpha-european-cloud/","section":"Publications","summary":"Summary # The NZZ article examines how Aleph Alpha, once celebrated as “Europe’s OpenAI,” is pivoting from developing its own large language model to becoming a service provider for the Schwarz Group (owner of Lidl). While some see this as a setback, experts view it as a strategic opportunity: building sovereign European cloud infrastructure may have far more potential than competing in the AI model race dominated by US and Chinese companies.\n","title":"NZZ: Aleph Alpha and the European Cloud Opportunity","type":"publications"},{"content":"Artificial intelligence (AI) is everywhere. Yet lasting business value often remains elusive. Too many companies still see AI as a tool or quick fix, rather than what it can be: a strategic partner for continuous learning and adaptation. To achieve competitive advantages in a dynamic, data-driven world, organizations must fundamentally restructure themselves as a Cybernetic Enterprise, where AI is firmly anchored as a feedback and learning amplifier. Instead of viewing AI in isolation or as an add-on, it should become an integral part of the organizational operating system. Only when AI transforms data, processes, and customer interactions into actionable learning does a useful tool become a true gamechanger, one that makes companies more agile, capable of learning, and future-oriented.\nAI as a Strategic Learning and Feedback Amplifier: Far More Than Automation # For a long time, the focus was on AI\u0026rsquo;s automation potential: accelerating processes, reducing costs, avoiding errors. But this operational view falls short. When properly embedded, AI becomes a strategic partner for data-driven decisions and continuous learning. Companies that view AI not as an isolated IT tool but as part of their business and operating model create a hard-to-replicate advantage. They use AI as a learning amplifier, a system that gains new insights from every interaction and continuously improves as a result.\nCurrent McKinsey data (State of AI March 2025) shows: 78% of companies already use AI in at least one business function, 71% regularly use Generative AI in their operations. However, those who fundamentally rethink their workflows achieve the greatest EBIT leverage, and 21% have begun doing so. Key to success is clear AI governance under CEO oversight and defined KPI roadmaps for AI solutions.\nIn the Cybernetic Enterprise, such feedback cycles form the backbone of the organizational operating system. Data from processes, customer interactions, and systems continuously flows back, is analyzed, and translated into learning. This creates a self-learning system that dynamically adapts to market conditions, the company essentially steers itself through feedback loops. AI acts as sensor and nervous system: it recognizes patterns, trends, and anomalies in real-time, while humans contribute context, creativity, and final decisions, human-led, AI-enabled. Thus AI amplifies human judgment rather than replacing it. With each closed feedback loop, the advantage grows: proprietary data, specialized models, and optimized processes cannot simply be copied. In short: AI is not an automation tool, but a learning partner and accelerator of organizational intelligence. Those who anchor it this way create the foundation for a resilient, adaptive, and future-ready company, a true Cybernetic Enterprise.\nCompetitive Advantage Through Connected Feedback Loops # Adaptability is the key to market success. A static organization that clings to old plans will always lose against a learning organization. True competitive advantages only emerge when data, technology, and organization are connected through continuous feedback loops.\nA Cybernetic Enterprise views the company as a dynamic system in which people, processes, and technologies constantly interact through feedback. Information from the market, such as changed customer behavior or production disruptions, flows almost in real-time from the operational to the strategic level. Decisions can thus be made data-based and quickly, rather than relying on assumptions. Companies that align their strategy, processes, and IT architecture to such fast feedback cycles recognize opportunities and risks earlier and respond immediately. A traditional top-down model with long coordination paths is too slow here. Those who break down data silos and tune their organization for continuous adaptation create the conditions for AI to unfold its full potential and trigger improvements that would otherwise remain undiscovered.\nTransformation of Organization and Culture # Anchoring AI as a strategic partner requires more than technology. It demands a profound transformation of structures, capabilities, and culture. Classical hierarchies with departmental silos lack the agility that a learning organization needs. Leaders must rethink: away from micromanagement, toward an enabling approach. They define frameworks and goals but leave it to teams how to achieve them. Employees need new competencies: systems thinking beyond task focus, data analysis, critical judgment, and agile collaboration. Continuous training becomes mandatory. Companies must ensure their talent is trained in working with AI and learn to critically question results and use them meaningfully.\nCultural change is equally crucial. In a learning organization, mistakes are seen as learning opportunities, continuous experimentation replaces rigid plans. This attitude must be modeled from the top, trust instead of control. At the same time, ethical guardrails are needed: fairness, transparency, data protection. Only then does trust emerge, internally and externally. Autonomous, interdisciplinary teams should make decisions where knowledge resides: in the team. New ideas can be validated through quick tests, such as A/B experiments. This creates a culture of learning and continuous improvement.\nPlatform Engineering as the Foundation for AI Integration # A robust technology platform is the foundation for embedding AI in a scalable, secure, and efficient manner. Platform Engineering unites data, AI tools, and infrastructure in a shared environment where teams can access all needed resources via self-service.\nAt the same time, automated controls ensure security and compliance from the start. In practice, such a platform measurably increases development speed, often by 30% or more. It creates transparency about data flows, ensures governance, and enables scaling of AI initiatives across departments. In short: Platform Engineering is the backbone of a sustainable AI strategy and the technological prerequisite for the Cybernetic Enterprise.\nKey Challenges # The transformation toward an AI-integrated organization brings significant hurdles:\nTalent shortage: AI expertise is scarce, making upskilling programs essential. Governance: Clear rules, responsibilities, and ethical guidelines are needed for responsible AI use. Cultural change: Employees must understand the benefits and lose their fears, through transparent communication, role models in management, and shared learning. Only when these three dimensions, technology, organization, culture, work together does AI become a true success factor.\nApplication Areas with Gamechanger Potential # AI is particularly effective where it learns and improves decisions. Three fields exemplify how strong the effect can be:\nPersonalization: AI enables individual customer engagement. Companies using personalized offerings significantly increase customer satisfaction and revenue. Forecasting: AI-based predictions make risks and opportunities visible early. For example, failures can be significantly reduced through predictive maintenance. Risk minimization: In finance or IT security, AI detects anomalies in real-time, such as fraud patterns or cyberattacks, and can prevent losses before they occur. Measuring Success in AI-Driven Companies # Success cannot be measured by efficiency alone. What matters are outcome-oriented metrics that reflect actual value. These include:\nthe speed of learning cycles (time from idea to customer feedback), customer benefit (satisfaction, reduced downtime), and organizational learning capability (frequency of closed feedback loops). This makes visible how strongly AI actually contributes to the organization\u0026rsquo;s performance and adaptability.\nAI as a Strategic Partner # On the path from digital to cybernetic enterprise, AI transforms from tool to co-creator. It becomes a \u0026ldquo;colleague of a different kind\u0026rdquo;, a partner that tirelessly analyzes data, recognizes patterns, and helps keep the company on course.\nThe prerequisite is that organizations rethink their operating system: away from silos and rigid plans, toward feedback loops, adaptive structures, and a culture of experimentation.\nThe concepts of the Cybernetic Enterprise show: it is possible to seamlessly embed AI and create a learning, adaptive corporate DNA. Used correctly, AI becomes the gamechanger that makes companies not only more efficient, but more agile, resilient, and future-ready.\nAI is no longer just a tool, it is the compass to steer the enterprise of the future.\nOriginally published on DIGITALE WELT Magazin (German)\n","date":"14 January 2026","externalUrl":null,"permalink":"/en/publications/digitale-welt-cybernetic-enterprise/","section":"Publications","summary":"Artificial intelligence (AI) is everywhere. Yet lasting business value often remains elusive. Too many companies still see AI as a tool or quick fix, rather than what it can be: a strategic partner for continuous learning and adaptation. To achieve competitive advantages in a dynamic, data-driven world, organizations must fundamentally restructure themselves as a Cybernetic Enterprise, where AI is firmly anchored as a feedback and learning amplifier. Instead of viewing AI in isolation or as an add-on, it should become an integral part of the organizational operating system. Only when AI transforms data, processes, and customer interactions into actionable learning does a useful tool become a true gamechanger, one that makes companies more agile, capable of learning, and future-oriented.\n","title":"Between Tool and Gamechanger: How AI Drives the Cybernetic Enterprise","type":"publications"},{"content":"Verstehen Sie, warum die meisten digitalen Transformationen scheitern und was führende Unternehmen von morgen gemeinsam haben. So löst Kybernetik die Herausforderungen von KI im großen Maßstab.\nWas bedeutet KI für Ihr Unternehmen? Ist sie ein Enabler? Ein weiteres Werkzeug im Kasten? Oder das A und O Ihres Geschäftsmodells? Für viele Organisationen fühlt sich die Einführung von KI kaum mehr an als eine Standardlösung, die auf den Status quo aufgesetzt wird, eine Haltung, die drei eng miteinander verknüpfte und potenziell gravierende Folgen haben kann:\nVerpasste Chancen und der Verlust von Wettbewerbsvorteilen Digitale Transformationen, die auf der Ebene von Pilotprojekten stecken bleiben Erhöhte Sicherheits-, Regulierungs- und Compliance-Risiken Die Alternative? Eine Reihe transformativer Prinzipien tief in der DNA des Unternehmens zu verankern, sodass jedes neue Projekt und jede Einführung zu einem sich verstärkenden ROI und zu sicher skalierbarer KI beitragen.\nDas ist die Cybernetic Enterprise, das Betriebsmodell, um sicher durch Disruptionen zu navigieren und einen Zustand wirklich widerstandsfähiger, sicherer und kontinuierlicher Innovation zu erreichen. Hier ist alles, was Sie wissen müssen.\nWarum die meisten KI-Transformationen bei Pilotprojekten stecken bleiben # Stellen Sie sich ein Team von Holzfällern vor, das ausschließlich mit Äxten arbeitet. Für sie würde die Erfindung der Kettensäge einen enormen Produktivitätsschub bedeuten, vermutlich aber auch einige Verletzungen. Mit KI verhält es sich ähnlich: Sie kann ein außergewöhnlich leistungsfähiges Werkzeug sein, aber nur dann, wenn sie mit der nötigen Sorgfalt in bestehende Prozesse integriert wird.\nHeute ist KI bereits weit verbreitet, doch ihre Nutzung reicht von aufgesetzten Tools über Pilotprojekte bis hin zu Mitarbeitenden, die sensible Unternehmensdaten in unsichere Modelle eingeben. Und selbst wenn Projekte vielversprechend sind, führt der Druck, schnelle Erfolge zu präsentieren, oft dazu, dass es keinen nachhaltigen Plan oder eine Roadmap für eine sichere und effiziente Skalierung gibt.\n„Trotz der Einführung von Agile und DevOps fehlt den meisten Organisationen nach wie vor die notwendige Reaktionsfähigkeit\u0026quot;, sagt Romano Roth, Global Chief of Cybernetic Transformation bei Zühlke. „Silos, fehlgeleitete Anreizsysteme, starre Hierarchien und unterbrochene Feedback-Schleifen sind weiterhin die größten Hürden für echte Anpassungsfähigkeit.\u0026quot;\nDas ist der Grund, warum die meisten digitalen Transformationen scheitern, und warum der Großteil der KI-Einsätze als Sackgassen-Pilotprojekte endet.\nDie vier Probleme, die KI daran hindern, ihr volles Geschäftspotenzial auszuschöpfen # In seinem Buch The Cybernetic Enterprise beschreibt Romano vier konkrete Probleme, die KI daran hindern, ihr volles geschäftliches Potenzial zu entfalten:\nFragmentierte Silos # Daten und Prioritäten sind häufig zwischen Geschäftsbereichen und Abteilungen voneinander entkoppelt. Feedback von Kunden und Mitarbeitenden geht verloren, wodurch es für KI schwierig wird, wirklich nützliche Erkenntnisse oder Fähigkeiten zu liefern.\nGovernance-Überlastung # „Agile at scale\u0026quot; schafft oft mehr Engpässe und Entscheidungsmüdigkeit, als es abbaut: mehr Freigaben, mehr Meetings und mehr Genehmigungsstufen für neue Produkte.\nStrategische Planung # Feste Budgets und Roadmaps brechen in dynamischen Märkten zusammen und sind oft veraltet, bevor sie vollständig umgesetzt wurden.\nUnerfüllte KI-Versprechen # KI-Pilotprojekte, und künftige Investitionen, geraten ohne integrierte Prozesse und qualitativ hochwertige Daten ins Stocken, sodass potenzielle Fähigkeiten brachliegen.\nZusammen ergeben diese Punkte eine zentrale Frage: Wie lassen sich echte KI-Innovationen (und ein messbarer ROI) inmitten starrer Geschäftsstrukturen und strenger Compliance-Anforderungen realisieren?\nDie Antwort liegt darin, erstere grundlegend neu zu denken, um letztere zu transformieren.\nDer Weg zur Risikominimierung: Die vier Grundsätze einer sicheren, skalierbaren KI-Transformation # „Kybernetik\u0026quot; beschreibt Prozesse, die in Feedback-Schleifen und Iterationen funktionieren, bei denen jede neue Innovation auf einem bewährten Vorgänger aufbaut. Ein Cybernetic Enterprise ist dementsprechend eine zukunftsfähige Organisation, die auf kontinuierliches Lernen, KI-augmentierte Intelligenz und schnelle Feedback-Schleifen über Strategie, Produkt, Technologie und Betrieb hinweg ausgelegt ist.\nDas ist nicht einfach Agile mit neuem Anstrich. Es ist ein Betriebsmodell, das Unternehmen in Zentren kontinuierlichen Lernens verwandelt. Lernen, das sich zu echtem Wettbewerbsvorteil verdichtet.\nUnd vor allem: Die Grundsätze des Cybernetic Enterprise lösen die zuvor beschriebenen Herausforderungen der sicheren KI-Skalierung ganz intrinsisch. Denn dieses Modell fördert:\n1. Geschlossene Feedback-Schleifen # Auf bewährten, kleinen Zyklen aufzubauen bedeutet, Strategie-, Technologie- und Kundensignale in Echtzeit zu verknüpfen. So können Teams auf gemeinsamen Erkenntnissen statt auf Annahmen handeln.\n2. KI-Governance by Design # Cybernetische Workflows integrieren Compliance und Transparenz von Anfang an direkt in die Abläufe und ermöglichen sichere Autonomie mit prüfbaren Prozessen.\n3. Kontinuierliche Anpassung # Dynamische Ressourcenallokation, kürzere Zyklen und schnelleres Lernen erlauben es Organisationen, ihren Fokus innerhalb von Wochen statt Jahren zu verlagern, und sich so schnell anzupassen, wie Markt- und Geschäftsbedingungen es erfordern.\n4. KI-augmentiertes Unternehmen # KI wird dort eingebettet, wo sie echten Mehrwert schafft, im Kern der Prozesse, mit menschlicher Aufsicht zur Qualitätssicherung.\nIm Kern geht es darum, Wahrnehmen, Entscheiden und Anpassen miteinander zu verbinden. Für KI heißt das: Prozesse gezielt dort zu augmentieren, wo Innovation entsteht, und nicht vorgefertigte Tools auf ohnehin ausgelastete Teams abzuladen.\nDer wichtigste Punkt jedoch ist: Wer wie ein Cybernetic Enterprise arbeitet, etabliert Workflows, die Sicherheit gewährleisten, und Governance-Prozesse sogar beschleunigen können, statt sie auszubremsen.\nDenn die beschriebenen Prinzipien verlangen, dass Compliance und Leitplanken direkt in jeden Workflow eingebaut sind. So können Unternehmen KI mit Vertrauen und Sicherheit skalieren.\n„Ein Cybernetic Enterprise verhält sich wie ein lebendiges, lernendes System, das seine Umwelt kontinuierlich wahrnimmt, Erkenntnisse zurückspielt und seinen Kurs in Echtzeit anpasst.\u0026quot;\nEin Praxisbeispiel # Bei Zühlke haben wir kürzlich cybernetische Workflows eingesetzt, um einen globalen MedTech-Marktführer dabei zu unterstützen, konforme und zugleich innovative Software im großen Maßstab zu entwickeln und bereitzustellen. Gemeinsam haben wir eine Entwicklungsplattform aufgebaut, auf der KI die Architektur, Verifikation und Entscheidungsfindung beschleunigt, ohne Kompromisse bei der Sicherheit. Das Ergebnis:\nBessere Abstimmung zwischen Architektur, Anforderungen und Verifikation KI-gestützte Prüfungen von Anforderungen, Backlog-Generierung und Testskripterstellung Stärkere Compliance und Qualität ohne zusätzlichen Lieferaufwand Wie Andrija Ljubojevic, Principal Software Engineering Consultant, es formuliert: „Viele glauben, dass strenge Regularien für Medizinprodukte Geschwindigkeit und Innovation bremsen. In unserem Fall war es genau umgekehrt: Die Disziplin und Struktur, die Standards wie IEC 62304, ISO 13485 und die Anforderungen der FDA verlangen, waren erst der Enabler für einen sinnvollen KI-Einsatz.\u0026quot;\nDas ist die Kraft eines Cybernetic Enterprise: Compliance- und Sicherheitsgrundlagen fördern Innovation, statt sie zu behindern.\nJetzt ist der richtige Zeitpunkt # Technologische Entwicklung wird sich nicht verlangsamen. Deshalb liegt es an den Führungskräften von morgen, neu zu definieren, wie ihre Unternehmen Schritt halten.\nSchätzungen zufolge werden rund 40 % der heutigen S\u0026amp;P-500-Unternehmen in zehn Jahren nicht mehr existieren, vor allem deshalb, weil sie nicht schnell genug lernen und umsetzen können, ohne sich dabei unnötigen Risiken auszusetzen.\nDas wird den Wettbewerbsvorteil der kommenden Jahre definieren.\n„Eine cybernetische Organisation ist nicht nur effizient\u0026quot;, sagt Romano, „sondern widerstandsfähig und selbstkorrigierend. Sie ersetzt statische Planung durch kontinuierliches Lernen, sodass sie sich so schnell anpassen kann wie die Welt um sie herum.\u0026quot;\nDie Ära von „move fast and break things\u0026quot; ist vorbei. Gleichzeitig gibt es keinen Platz mehr für Unternehmen, die sich so langsam drehen, dass sie jedem Eisberg ausweichen wollen. Stattdessen erleben wir eine Zeit, in der ein grundlegendes, systemisches Umdenken darüber, wie Organisationen denken und handeln, der notwendige nächste Schritt ist, um sowohl operativen Erfolg als auch sichere, skalierbare und datengetriebene Transformation zu gewährleisten.\nDenn letztlich ist es ein und dasselbe.\nUrsprünglich veröffentlicht auf Zühlke Insights\n","date":"2. January 2026","externalUrl":null,"permalink":"/de/blogs/vier-grundsaetze-sichere-skalierbare-ki-transformation/","section":"Blogs","summary":"Verstehen Sie, warum die meisten digitalen Transformationen scheitern und was führende Unternehmen von morgen gemeinsam haben. So löst Kybernetik die Herausforderungen von KI im großen Maßstab.\n","title":"Die vier Grundsätze einer sicheren, skalierbaren KI-Transformation im Unternehmen","type":"blogs"},{"content":"Discover the people, processes and technology you\u0026rsquo;ll need to mitigate setbacks on your transformation journey, and unlock AI-augmented ROI that compounds as it scales.\nQuick question: would you rather buy a brand new SUV, or a horse with an engine strapped to its back? For too many businesses, the approach to AI-driven transformation looks a lot like the latter, next-generation technology retrofitted into legacy systems, and everyone left hoping for the best.\nA recipe for disaster? Certainly. But this also amounts to a missed opportunity: AI enablement only offers a competitive advantage if it\u0026rsquo;s integrated alongside human judgement, strategy, and closed feedback loops.\nHere\u0026rsquo;s why becoming \u0026lsquo;Cybernetic\u0026rsquo; can address AI safety concerns, foster business wide confidence, and unlock hidden value.\nClosing the loop # Digital transformation is an interesting kind of race. Time is of the essence if you want to remain competitive, but moving too quickly, without due care, won\u0026rsquo;t land you at the front of the pack. In fact, it might be what keeps you in last place.\nSo there\u0026rsquo;s a conundrum here: how can businesses move fast enough to overcome the cost of inaction, without heading down technological dead ends?\nTo land on a solution, we need to understand the problems, all of which go back to our horse/engine analogy. Or, in other words, the inability or unwillingness to transform things at the systems level.\nLet\u0026rsquo;s start with the outcome and work backwards. An organisation that gets all this exactly right, and that knows how to build change into its core systems, is one that understands the science of cybernetics.\nWe call these businesses Cybernetic Enterprises, continuously adaptive organisations that operate through closed feedback loops, AI-augmented intelligence, and autonomous, cross-functional teams.\nWhat is a Cybernetic Enterprise? # Cybernetics is the study of how systems regulate and improve themselves through feedback.\nIn business terms, a cybernetic organisation is one that replaces periodic \u0026ldquo;transformation waves\u0026rdquo; with continuous, measurable adaptation:\nIt detects signals early (customer, operational, financial, risk). It turns signals into decisions quickly (with clear decision rights). It acts in small, reversible increments (so change stays safe). A useful shorthand is: Humans and AI work together in continuous feedback loops to create value.\nThat framing matters because it shifts the executive question from \u0026ldquo;Where can we use AI?\u0026rdquo; to \u0026ldquo;Where are our feedback loops missing, slow, or distorted and what must we change to close them?\u0026rdquo;\nThe three requirements: people, processes, technology # \u0026ldquo;A Cybernetic Enterprise builds on the idea that you can only scale what you can learn from,\u0026rdquo; says Romano Roth, Zühlke\u0026rsquo;s Global Chief of Cybernetic Transformation. \u0026ldquo;By architecting the company around fast feedback and continuous improvement, you turn every cycle into a source of intelligence.\u0026rdquo;\nAnd we can break the thinking here down into three key requirements:\n1. People # Cybernetic teams need the ability to navigate complexity, think in feedback loops, and connect the dots across disciplines. That means working iteratively and making decisions where the knowledge is, not at a remote management level. This is a shift from functional specialists to systems-aware, problem-solving collaborators.\n2. Processes # Cybernetic Enterprises build processes that evolve through feedback, where agile principles and self-learning systems create autonomous teams that stay responsive. In real-world projects, AI-enhanced development productivity has increased by 30%.\n3. Technology # Businesses moving down this path require modular tools and components that embed intelligence into every facet of software development and operations. This positions tech as an enabler for change, not its core focus.\nBring these pillars together and you\u0026rsquo;ll have built an ongoing practice of improvement, built on gathering feedback on what works and closing the loop wherever experience gaps and pain points present themselves.\nAlign every layer, strategy, operations, governance, and technology, through real-time sensing and feedback, and you\u0026rsquo;ll reap the rewards.\nThe benefits of becoming a Cybernetic Enterprise: Confidence, control and ROI in one # As a Cybernetic Enterprise, you\u0026rsquo;ll lock in a few important things:\nDigital transformation that scales and adapts Future-proof teams with ever-evolving skills A competitive advantage that\u0026rsquo;s more than a flash in the pan That\u0026rsquo;s a return on investment that equates to much more than the sum of its parts. It\u0026rsquo;s faster time-to-value, compliance built into processes, and confidence through control that you don\u0026rsquo;t get if you simply slap an off-the-shelf solution on top of existing systems.\nImportantly, cybernetics ensures safety because its principles are fundamentally baked into governance and compliant best-practices. That means laying transparent, auditable architecture from day one, rather than bolting regulatory checks and balances on at the end.\nThe 10 rules of a Cybernetic Enterprise # Ten rules translate the model into executive action:\n1. CEO as Chief Evangelist Make the shift non-negotiable. Remove obstacles. Set the tone.\n2. Organise across value streams, not silos Align teams end-to-end around customer value so feedback can flow.\n3. Outcome over output Measure what matters: impact, not activity. Fund outcomes, not projects.\n4. Architect for simplicity and modularity Reduce coupling so teams can change safely without breaking the whole.\n5. Platform enablement Build and run the Cybernetic Platform as the backbone for speed and consistency.\n6. Feedback everywhere Instrument the organisation so decisions are grounded in real-time signals.\n7. Empower autonomous teams Push authority to small, cross-functional teams within clear constraints.\n8. Augment with AI Use AI as a co-pilot to enhance insight and automation. Humans stay accountable.\n9. Transparency by default Share metrics and decision reasoning widely to build trust and alignment.\n10. Adaptation as the norm Replace static plans with iterative steering. Adjust continuously based on evidence.\nWhat this all means is that you can unpick and counteract a very common, typically mutually exclusive dichotomy: being innovative and being risk-proof.\nAs Romano puts it:\n\u0026ldquo;A Cybernetic Enterprise doesn\u0026rsquo;t choose between speed and safety. It achieves both by making change incremental, reversible, and continuously informed by real-world feedback.\u0026rdquo;\nHow to get started: three executive moves # You don\u0026rsquo;t need a multi-year \u0026ldquo;transformation programme\u0026rdquo; to start. You need focus and a system.\nStart with one high-impact value stream # Pick the end-to-end flow where speed and risk matter most, typically customer-facing delivery, revenue-critical changes, or a compliance-sensitive service. Make it small enough to govern tightly, but meaningful enough that improvements will be noticed.\nDefine the feedback loops you need # Decide which signals you\u0026rsquo;ll continuously sense, who has authority to act on them, and the time horizons that matter. Define escalation paths and thresholds so \u0026ldquo;drift\u0026rdquo; triggers action rather than debate.\nFund it as a product # Build and maintain \u0026ldquo;paved paths\u0026rdquo; for secure delivery, policy-as-code for consistent controls, strong observability for rapid diagnosis, and self-service capabilities that reduce handoffs. Measure success by outcomes (lead time, reliability, change failure rate, and leading risk indicators) rather than activity or tool adoption.\nOutrunning the digital transformation timebomb # Failure to adapt means failure to compete, and it\u0026rsquo;s estimated that up to 40% of today\u0026rsquo;s Fortune 500 could disappear within the next decade if they don\u0026rsquo;t implement true transformation.\n\u0026ldquo;Enterprises that cannot reinvent themselves, not just once, but continuously, are being overtaken by those that can.\u0026rdquo;\nMost at risk are those that think they\u0026rsquo;ve adapted and optimised by deploying AI, but haven\u0026rsquo;t truly evolved in step with technology. Deemed \u0026lsquo;AI idiots\u0026rsquo; by Romano, these are the businesses that will encounter compounding costs, technical debt, regulatory risk, and lost market relevance.\n\u0026ldquo;Most organisations believe they\u0026rsquo;re transforming,\u0026rdquo; Romano explains, \u0026ldquo;but in reality they\u0026rsquo;re only modernising the edges. Without repairing the system itself, its feedback loops, governance, and architecture, the transformation cannot compound.\u0026rdquo;\nUltimately, this is about AI, and it\u0026rsquo;s not about AI. It\u0026rsquo;s about securing sustainable growth, reducing risk, and delivering measurable outcomes from any digital initiative. Becoming a Cybernetic Enterprise means leaning into an operating model that embeds AI, feedback loops and platform thinking into the core DNA of your organisation.\nThat results in faster innovation, bolstered security, empowered teams, and compounding returns, where each iteration strengthens the system.\nOriginally published on Zühlke Insights\n","date":"2 January 2026","externalUrl":null,"permalink":"/en/blogs/benefits-of-becoming-a-cybernetic-enterprise/","section":"Blogs","summary":"Discover the people, processes and technology you’ll need to mitigate setbacks on your transformation journey, and unlock AI-augmented ROI that compounds as it scales.\n","title":"Structured disruption: The benefits of becoming a Cybernetic Enterprise","type":"blogs"},{"content":"Entdecken Sie die Menschen, Prozesse und Technologien, die Sie benötigen, um Rückschläge auf Ihrer Transformationsreise zu vermeiden, und einen KI-gestützten ROI zu erschließen, der sich mit zunehmender Skalierung weiter verstärkt.\nEine kurze Frage: Würden Sie lieber einen brandneuen SUV kaufen oder ein Pferd, dem ein Motor auf den Rücken geschnallt wurde? Für zu viele Unternehmen sieht der Ansatz zur KI-getriebenen Transformation eher nach Letzterem aus: Next-Generation-Technologie, nachträglich in Altsysteme eingebaut, während alle hoffen, dass es irgendwie gut geht.\nEin Rezept für das Desaster? Ganz sicher. Aber es ist auch eine verpasste Chance: KI-Enablement verschafft nur dann einen echten Wettbewerbsvorteil, wenn es gemeinsam mit menschlichem Urteilsvermögen, Strategie und geschlossenen Feedback-Schleifen integriert wird.\nHier erfahren Sie, warum der Weg zum „Cybernetic Enterprise\u0026quot; dabei helfen kann, KI-Sicherheitsbedenken auszuräumen, unternehmensweites Vertrauen zu stärken und verborgene Werte freizusetzen.\nDen Kreis schließen # Digitale Transformation ist eine besondere Art von Wettlauf. Zeit ist entscheidend, um wettbewerbsfähig zu bleiben, doch wer sich zu schnell bewegt, ohne die nötige Sorgfalt walten zu lassen, landet nicht an der Spitze. Im Gegenteil: Genau das kann dazu führen, dass man auf dem letzten Platz bleibt.\nEs ergibt sich also ein Dilemma: Wie können Unternehmen schnell genug handeln, um die Kosten des Nichtstuns zu vermeiden, ohne sich in technologische Sackgassen zu manövrieren?\nUm eine Lösung zu finden, müssen wir die zugrunde liegenden Probleme verstehen, und die führen uns zurück zu unserer Pferd-und-Motor-Analogie. Oder anders gesagt: zur Unfähigkeit oder Unwilligkeit, Transformation auf Systemebene anzugehen.\nBeginnen wir mit dem Ergebnis und arbeiten uns rückwärts vor. Eine Organisation, die all dies richtig macht und weiß, wie Veränderung in ihre Kernsysteme eingebaut wird, versteht die Wissenschaft der Kybernetik.\nWir nennen solche Unternehmen Cybernetic Enterprises: kontinuierlich adaptive Organisationen, die über geschlossene Feedback-Schleifen, KI-augmentierte Intelligenz sowie autonome, funktionsübergreifende Teams operieren.\nWas ist eine Cybernetic Enterprise? # Kybernetik ist die Lehre davon, wie sich Systeme durch Feedback selbst regulieren und verbessern.\nIn unternehmerischen Begriffen ist eine cybernetische Organisation eine, die periodische „Transformationswellen\u0026quot; durch kontinuierliche, messbare Anpassung ersetzt:\nSie erkennt Signale frühzeitig (Kunden-, operative, finanzielle und Risikosignale). Sie übersetzt Signale schnell in Entscheidungen (mit klaren Entscheidungsrechten). Sie handelt in kleinen, reversiblen Schritten (damit Veränderungen sicher bleiben). Eine hilfreiche Kurzformel lautet: Menschen und KI arbeiten gemeinsam in kontinuierlichen Feedback-Schleifen, um Wert zu schaffen.\nDiese Perspektive ist wichtig, weil sie die zentrale Managementfrage verschiebt, von „Wo können wir KI einsetzen?\u0026quot; hin zu „Wo fehlen unsere Feedback-Schleifen, wo sind sie zu langsam oder verzerrt, und was müssen wir ändern, um sie zu schließen?\u0026quot;\nDie drei Voraussetzungen: Menschen, Prozesse, Technologie # „Eine Cybernetic Enterprise basiert auf der Idee, dass man nur das skalieren kann, aus dem man lernt\u0026quot;, sagt Romano Roth, Global Chief of Cybernetic Transformation bei Zühlke. „Indem man das Unternehmen um schnelle Feedback-Zyklen und kontinuierliche Verbesserung herum aufbaut, wird jeder Zyklus zu einer Quelle von Intelligenz.\u0026quot;\nDieses Denken lässt sich in drei zentrale Anforderungen gliedern:\n1. Menschen # Cybernetische Teams müssen in der Lage sein, Komplexität zu navigieren, in Feedback-Schleifen zu denken und Zusammenhänge über Disziplinen hinweg herzustellen. Das bedeutet iteratives Arbeiten und Entscheidungen dort zu treffen, wo das Wissen liegt, nicht auf einer entfernten Managementebene. Es ist ein Wandel von funktionalen Spezialisten hin zu systembewussten, problemlösungsorientierten Kollaborateuren.\n2. Prozesse # Cybernetic Enterprises gestalten Prozesse, die sich durch Feedback weiterentwickeln. Agile Prinzipien und selbstlernende Systeme schaffen autonome Teams, die reaktionsfähig bleiben. In realen Projekten ist die durch KI gesteigerte Entwicklungseffizienz um bis zu 30 % gestiegen.\n3. Technologie # Unternehmen auf diesem Weg benötigen modulare Werkzeuge und Komponenten, die Intelligenz in jeden Aspekt der Softwareentwicklung und des Betriebs einbetten. So wird Technologie zum Enabler für Veränderung, nicht zu deren eigentlichem Selbstzweck.\nWer diese Säulen zusammenführt, etabliert eine dauerhafte Praxis der Verbesserung, basierend auf dem Sammeln von Feedback darüber, was funktioniert. Sie schließt dort den Kreis, wo Erfahrungslücken und Schmerzpunkte auftreten.\nWenn alle Ebenen, Strategie, Betrieb, Governance und Technologie, durch Echtzeit-Sensorik und Feedback ausgerichtet sind, stellen sich die Erträge ein.\nDie Vorteile einer Cybernetic Enterprise: Vertrauen, Kontrolle und ROI in einem # Als Cybernetic Enterprise sichern Sie sich mehrere entscheidende Vorteile:\nDigitale Transformation, die skaliert und sich anpasst Zukunftssichere Teams mit kontinuierlich wachsenden Fähigkeiten Einen nachhaltigen Wettbewerbsvorteil, der kein Strohfeuer ist Das ist ein Return on Investment, der weit über die Summe seiner Einzelteile hinausgeht: schnellere Time-to-Value, Compliance als integraler Bestandteil der Prozesse sowie Vertrauen durch Kontrolle, etwas, das nicht entsteht, wenn man lediglich eine Standardlösung auf bestehende Systeme aufsetzt.\nEntscheidend ist: Kybernetik gewährleistet Sicherheit, weil ihre Prinzipien von Anfang an in Governance und Compliance-Best-Practices eingebettet sind. Das bedeutet transparente, prüfbare Architekturen von Tag eins an, statt regulatorische Kontrollen erst nachträglich anzubauen.\nDie 10 Regeln des Cybernetic Enterprise # Zehn Regeln setzen das Modell in die Praxis um:\n1. CEO als Chief Evangelist Machen Sie den Wandel nicht verhandelbar. Beseitigen Sie Hindernisse. Geben Sie den Ton vor.\n2. Organisation entlang von Wertströmen statt Silos Richten Sie Teams End-to-End am Kundennutzen aus, damit Feedback fließen kann.\n3. Ergebnisse vor Output Messen Sie, was zählt: Wirkung statt Aktivität. Finanzieren Sie Ergebnisse, nicht Projekte.\n4. Architektur für Einfachheit und Modularität Reduzieren Sie Kopplungen, damit Teams sicher verändern können, ohne das Ganze zu gefährden.\n5. Plattform-Enablement Entwickeln und betreiben Sie die Cybernetic Plattform als Rückgrat für Geschwindigkeit und Konsistenz.\n6. Feedback überall Instrumentieren Sie die Organisation so, dass Entscheidungen auf Echtzeit-Signalen beruhen.\n7. Autonome Teams befähigen Verlagern Sie Entscheidungsbefugnisse auf kleine, funktionsübergreifende Teams innerhalb klarer Leitplanken.\n8. Mit KI augmentieren Nutzen Sie KI als Co-Pilot zur Unterstützung von Erkenntnissen und Automatisierung. Menschen bleiben verantwortlich.\n9. Transparenz als Standard Teilen Sie Kennzahlen und Entscheidungslogiken breit, um Vertrauen und Alignment zu schaffen.\n10. Anpassung als Normalzustand Ersetzen Sie statische Pläne durch iteratives Steuern. Passen Sie sich kontinuierlich auf Basis von Evidenz an.\nWas das alles bedeutet: Sie können einen weit verbreiteten, und meist als unvereinbar betrachteten, Gegensatz auflösen, nämlich innovativ zu sein und gleichzeitig Risiken zu minimieren.\nWie Romano es ausdrückt:\n„Eine Cybernetic Enterprise entscheidet sich nicht zwischen Geschwindigkeit und Sicherheit. Sie erreicht beides, indem sie Veränderungen inkrementell, reversibel und kontinuierlich durch reale Feedbacks informiert gestaltet.\u0026quot;\nSo starten Sie: drei Executive Moves # Sie brauchen kein mehrjähriges Transformationsprogramm, um loszulegen. Entscheidend sind Fokus, klare Entscheidungskompetenzen, und ein wiederholbares System, mit dem Sie schnell lernen und messbar Wirkung erzielen.\nWählen Sie einen Wertstrom # Wählen Sie den End-to-End-Flow, in dem Geschwindigkeit und Risiko am stärksten ins Gewicht fallen, typischerweise in der kundennahen Auslieferung, bei umsatzkritischen Changes oder in einem compliance-sensitiven Service. Halten Sie den Scope so klein, dass er klar steuerbar bleibt, aber so relevant, dass Verbesserungen im Geschäft spürbar werden.\nDefinieren Sie die benötigten Rückkopplungsschleifen # Legen Sie fest, welche Signale Sie kontinuierlich erfassen, wer die Entscheidungskompetenz hat, und in welchen Zeitfenstern Sie handeln müssen. Definieren Sie Eskalationspfade und Schwellenwerte so, dass Abweichungen konsequent eine Reaktion auslösen, statt Diskussionen.\nFinanzieren Sie es wie ein Produkt # Bauen und betreiben Sie „Paved Paths\u0026quot; für sichere Delivery, Policy-as-Code für konsistente Controls, starke Observability für schnelle Diagnose sowie Self-Service-Fähigkeiten, die Übergaben und Wartezeiten reduzieren. Messen Sie Erfolg über Outcomes (z. B. Durchlaufzeit/Lead Time, Zuverlässigkeit, Change Failure Rate und frühzeitige Risikoindikatoren) - nicht über Aktivität oder Tool-Adoption.\nDer digitalen Transformations-Zeitbombe davonlaufen # Wer sich nicht anpasst, verliert seine Wettbewerbsfähigkeit. Schätzungen zufolge könnten bis zu 40 % der heutigen Fortune-500-Unternehmen innerhalb des nächsten Jahrzehnts verschwinden, wenn sie keine echte Transformation umsetzen.\n„Unternehmen, die sich nicht kontinuierlich neu erfinden können, und nicht nur einmal, werden von denen überholt, die es können.\u0026quot;\nBesonders gefährdet sind jene, die glauben, sich durch den Einsatz von KI bereits angepasst und optimiert zu haben, ohne sich tatsächlich im Gleichschritt mit der Technologie weiterzuentwickeln. Romano bezeichnet sie als „AI Idioten\u0026quot; - Unternehmen, denen steigende Kosten, technischer Schuldenaufbau, regulatorische Risiken und der Verlust von Marktrelevanz drohen.\n„Die meisten Organisationen glauben, sie transformieren sich\u0026quot;, erklärt Romano, „doch in Wirklichkeit modernisieren sie nur die Ränder. Ohne das System selbst zu reparieren, seine Feedback-Schleifen, Governance und Architektur, kann sich Transformation nicht vervielfachen.\u0026quot;\nAm Ende geht es um KI, und zugleich nicht nur um KI. Es geht darum, nachhaltiges Wachstum zu sichern, Risiken zu reduzieren und messbare Ergebnisse aus jeder digitalen Initiative zu erzielen. Eine Cybernetic Enterprise zu werden bedeutet, ein Betriebsmodell zu etablieren, das KI, Feedback-Schleifen und Plattformdenken in der DNA der Organisation verankert.\nDas Ergebnis: schnellere Innovation, höhere Sicherheit, gestärkte Teams und sich verstärkende Erträge, bei denen jede Iteration das System weiter verbessert.\nUrsprünglich veröffentlicht auf Zühlke Insights\n","date":"2. January 2026","externalUrl":null,"permalink":"/de/blogs/vorteile-einer-cybernetic-enterprise/","section":"Blogs","summary":"Entdecken Sie die Menschen, Prozesse und Technologien, die Sie benötigen, um Rückschläge auf Ihrer Transformationsreise zu vermeiden, und einen KI-gestützten ROI zu erschließen, der sich mit zunehmender Skalierung weiter verstärkt.\n","title":"Strukturierte Disruption: Die Vorteile des Cybernetic Enterprise","type":"blogs"},{"content":"Understand why most digital transformations fail, and you\u0026rsquo;ll figure out what tomorrow\u0026rsquo;s leading businesses will all have in common. Here\u0026rsquo;s how Cybernetics solves AI challenges at scale.\nWhat is AI to your business? An enabler? Another tool in the shed? Or the be all, end all of your business model? For many organisations, AI implementation feels like little more than an off-the-shelf addition to the status quo, but this is an attitude that can have three pretty disastrous, interlinked ramifications:\nMissed opportunities and the loss of competitive edge Digital transformations that stagnate at the pilot-project level Exposure to security, regulatory and compliance risks The alternative? Folding a series of transformative principles into your business\u0026rsquo; DNA that turn every new project and deployment into compounding ROI and secure AI scalability.\nThis is the Cybernetic Enterprise, the operating model for sailing through disruption and into a state of truly resilient, safe and ongoing innovation. Here\u0026rsquo;s everything you need to know.\nWhy most AI transformations stall at pilots # Imagine a team of lumberjacks using nothing but axes. To them, the invention of the chainsaw would bring with it a huge uptick in productivity, but probably more than a few injuries, too. AI is the same; it can be an incredible business tool, but only when it\u0026rsquo;s implemented into existing processes with due care and attention.\nToday, AI adoption is already widespread, but its implementation varies wildly from tacked-on tools, to pilot projects, to workers feeding business secrets to insecure models. And when projects do show promise, the pressure to present fast wins means there\u0026rsquo;s rarely an ongoing scope or roadmap for how those successes can scale safely and efficiently.\n\u0026ldquo;Despite embracing Agile and DevOps, most organisations still lack the responsiveness they need,\u0026rdquo; says Zühlke\u0026rsquo;s Global Chief of Cybernetic Transformation, Romano Roth. \u0026ldquo;Silos, misaligned incentives, rigid hierarchies, and broken feedback loops remain the barriers to true adaptiveness.\u0026rdquo;\nThis is why most digital transformations fail, and it\u0026rsquo;s why the majority of AI deployments languish as dead-end pilots.\nThe four specific problems keeping AI from its full business potential # In his The Cybernetic Enterprise book, Romano outlines four specific problems keeping AI from its full business potential:\nFragmented silos # Data and priorities are often disconnected between the business and departments. Feedback from both customers and team members gets lost, and this makes it hard for AI to uncover and enable truly useful insights or capabilities.\nGovernance overload # \u0026ldquo;Agile at scale\u0026rdquo; often creates more bottlenecks and decision fatigue than it alleviates. That\u0026rsquo;s more permissions, more meetings, and more approval constraints on emergent products.\nStatic planning # Fixed budgets and roadmaps collapse in dynamic markets, becoming outdated and irrelevant before they\u0026rsquo;ve been seen through to completion.\nUnfulfilled AI promises # AI pilots, and future investments, stall without integrated processes and good data, leaving potential capabilities locked in stasis.\nTogether, these issues present a single challenge: How can we deliver genuine AI innovation (and ROI) amid typically rigid business practices and tight compliance constraints?\nThe answer lies in rethinking the former to transform the latter.\nThe route to risk mitigation: The four tenets of secure, scalable AI transformation # \u0026lsquo;Cybernetics\u0026rsquo; describes processes that work in feedback loops and iteration, where any new innovation is built on top of a proven precursor. A Cybernetic Enterprise, then, is a future-ready organisation designed for continuous learning, AI-augmented intelligence and fast feedback loops across strategy, product, technology and operations.\nThis isn\u0026rsquo;t Agile with a new lick of paint. It\u0026rsquo;s an operating model that reshapes businesses into centres for ongoing learning that compounds into real competitive advantage.\nAnd, importantly, the tenets of a Cybernetic Enterprise innately solve all the issues we\u0026rsquo;ve outlined in deploying AI safely at scale. That\u0026rsquo;s because this model promotes:\n1. Closed feedback loops # Building on what works in small, proven cycles means connecting strategy, tech and customer signals in real time. This allows teams to act on shared insight instead of assumptions.\n2. AI Governance by design # Cybernetic workflows bake compliance and transparency directly into workflows from the outset, enabling safe autonomy with auditable processes.\n3. Continuous adaptation # Dynamic resource allocation, shorter cycles, and faster learning let organisations shift focus in weeks, not years, adjusting as fast as market and business conditions shift.\n4. AI-augmented enterprise # AI is embedded where it adds actual value, and at the heart of processes, with human oversight for quality assurance.\nThis is all about connecting the abilities to sense, to make decisions, and to adapt. For AI, that means augmenting processes that need augmenting, and only for projects that fuel innovation. It doesn\u0026rsquo;t mean taking prepackaged tools and dumping them on already-busy teams.\nBut here\u0026rsquo;s the most important thing: when you operate like a Cybernetic Enterprise, you have workflows that ensure safety, and governance processes can actually accelerate delivery instead of slowing things down.\nThis is because the principles we\u0026rsquo;re describing require that compliance and guardrails are built directly into every workflow, meaning organisations can scale AI confidently.\n\u0026ldquo;A Cybernetic Enterprise behaves like a living, learning system, constantly sensing its environment, feeding back insights, and adapting its course in real time.\u0026rdquo;\nA real-world example # At Zühlke, we\u0026rsquo;ve recently used cybernetic workflows to support a global MedTech leader in its goal to design and deploy compliant, innovative software at scale. Together, we built a development platform where AI accelerates architecture, verification and decision-making, all without compromising safety. That means:\nBoosted alignment across architecture, requirements and verification Enabled AI-supported requirement checks, backlog generation and test scripting Strengthened compliance and quality without adding delivery overhead As Andrija Ljubojevic, Principal Software Engineering Consultant, puts it: \u0026ldquo;Most people think that strict medical device regulation slows down velocity and innovation. In our case,\u0026rdquo; he explains, \u0026ldquo;it was quite the opposite: the discipline and structure required by standards like IEC 62304, ISO 13485, and FDA requirements became the very thing that enabled us to apply AI meaningfully.\u0026rdquo;\nThis is the power of becoming a Cybernetic Enterprise: compliance and security fundamentals actually fostering, rather than hindering, innovation.\nThe time is now # Here\u0026rsquo;s the thing: technological evolution isn\u0026rsquo;t going to slow down. So the onus is on tomorrow\u0026rsquo;s enterprise leaders to reinvent how they keep up.\nIt\u0026rsquo;s estimated that some 40% of the S\u0026amp;P 500 won\u0026rsquo;t exist in ten years\u0026rsquo; time, and that\u0026rsquo;s all because they lack the ability to learn and implement faster than the environment around them changes, and without exposing themselves to undue risk.\nThis is what will define competitive advantage over the coming years.\n\u0026ldquo;A cybernetic enterprise is not only efficient,\u0026rdquo; says Romano, \u0026ldquo;but resilient and self-correcting. It replaces static planning with continuous learning so the organisation can adapt as fast as the world around it changes.\u0026rdquo;\nWe\u0026rsquo;ve come to the end of the era of \u0026lsquo;move fast and break things\u0026rsquo;. But, at the same time, there\u0026rsquo;s no more room for businesses that turn too slowly to avoid any icebergs in their path. Instead, we\u0026rsquo;ve entered a time in which a full, systemic rethink of how organisations think and act is the necessary next step to ensuring both operational success and secure, scalable, data-driven transformation.\nBecause, really, they\u0026rsquo;re one and the same.\nOriginally published on Zühlke Insights\n","date":"2 January 2026","externalUrl":null,"permalink":"/en/blogs/four-tenets-of-secure-scalable-enterprise-ai-transformation/","section":"Blogs","summary":"Understand why most digital transformations fail, and you’ll figure out what tomorrow’s leading businesses will all have in common. Here’s how Cybernetics solves AI challenges at scale.\n","title":"The four tenets of secure, scalable enterprise AI transformation","type":"blogs"},{"content":"","date":"24 December 2025","externalUrl":null,"permalink":"/en/tags/continuous-improvement/","section":"Tags","summary":"","title":"Continuous Improvement","type":"tags"},{"content":"Die meisten Unternehmen, die heute agil arbeiten und gleichzeitig versuchen, AI zu implementieren, werden meiner Meinung nach die nächste Dekade nicht überleben. Der Grund: Ihr Betriebssystem ist zu alt. Die Zukunft ist nicht agil. Die Zukunft ist auch nicht AI. Die Zukunft ist kybernetisch.\nIn meinem Vortrag bei den Zukunftsmenschen erkläre ich, was das Cybernetic Enterprise ist, warum Organisationen ein neues Betriebssystem brauchen und wie man eine solche Transformation konkret angeht.\nWarum das klassische Modell an seine Grenzen kommt # Wir implementieren Agile, wir implementieren DevOps, manche machen SAFe, und natürlich machen wir jetzt alle auch noch AI. Eigentlich wollen wir schneller werden, aber irgendwie werden wir immer langsamer. Der Grund liegt darin, dass das klassische Modell in unseren Unternehmen komplett an seine Grenzen kommt.\nWir haben Silos: Business-Silos, IT-Silos, Security-Silos. Wir haben Governance und Prozesse, denen wir ein agiles Gewand überziehen. Wir führen agile Rollen ein, aber eigentlich ist alles immer noch Wasserfall. Dann starten wir eine digitale Transformation, die nichts anderes macht, als die alten Strukturen zu digitalisieren.\nMeine Beobachtung: Wir optimieren aktuell auf Geschwindigkeit. Aber bei Agilität geht es eigentlich um die Steuerfähigkeit und um die Resilienz, also darum, schnell auf Veränderungen reagieren zu können. Die meisten fokussieren auf AI-Tools, aber das Betriebssystem der Organisation ist alt und wird nicht wirklich aktualisiert.\nWas Cybernetic eigentlich bedeutet # Der Begriff \u0026ldquo;Cybernetic\u0026rdquo; ist älter als der Begriff AI. Er wurde Anfang der 1940er Jahre geprägt und sagt im Kern etwas ganz Einfaches: Menschen und Maschinen (somit auch KI) arbeiten zusammen in kontinuierlichen Feedback Loops, um kontinuierlich Wert zu schaffen.\nDieser Begriff fasziniert mich, weil er genau das beschreibt, was unsere heutigen Unternehmen brauchen. Dabei geht es nicht darum, Menschen durch AI zu ersetzen. Wir müssen die Menschen besser machen mit KI. Das ist ein fundamentaler Unterschied.\nDie fünf Schritte vor der Automatisierung # Allzu oft fokussieren wir uns darauf, welche Prozesse wir automatisieren können. Ich habe schon vor Jahren postuliert, dass man fünf Schritte einhalten muss:\nAnforderungen hinterfragen. Hinter jede Anforderung einen Namen schreiben: Wer ist der Owner? Unerbittlich streichen. Was braucht es wirklich nicht in dieser Anforderung? Vereinfachen. Die verbleibenden Anforderungen so einfach wie möglich gestalten. Optimieren. Erst wenn vereinfacht wurde, wird optimiert. Automatisieren. Erst ganz am Schluss kommt die Automatisierung. Das Problem: Wir fokussieren uns die ganze Zeit auf Schritt 5. Bei allem, was aktuell mit AI passiert, geht es den meisten Unternehmen immer nur um den letzten Schritt. Aber die Prozesse und Anforderungen dahinter werden nicht hinterfragt.\nDas mentale Modell des Cybernetic Enterprise # Im Cybernetic Enterprise Buch habe ich ein mentales Modell entwickelt, das vom Sinn bis zu den Tools reicht. Es bildet das Layering einer Organisation ab:\nSinn definiert die Vision (eine 1:1-Beziehung) Vision leitet die Mission Mission gestaltet die Werte Aus den Werten leiten wir Prinzipien ab (16 Prinzipien habe ich identifiziert) Prinzipien definieren Capabilities (Business und IT) Capabilities münden in Practices (55 an der Zahl) Aus Practices leiten wir Prozesse ab Und erst dann kommen die Tools Zu viele Diskussionen beginnen bei den Tools. Das ist, als würde man ein Haus beim Dach anfangen zu bauen. Dieses mentale Modell zeigt, dass Tools das letzte Element sind, nicht das erste.\nDrei Kernprinzipien # Aus den 16 Prinzipien des Cybernetic Enterprise sind drei besonders hervorzuheben:\nOrganisation entlang des Wertstroms. Das ist der grösste Hebel, den man hat, und gleichzeitig der Hebel, den die wenigsten Organisationen wirklich nutzen. Viele haben Angst vor diesem Wandel, aber er löst ganz viele Probleme.\nErmächtigte Teams. Autonome Teams, die selbstständig einen Teil eines Produkts oder ein gesamtes Produkt verantworten und komplett unabhängig produzieren können.\nDatengetriebene Entscheidungen. Das ist die Grundlage für die Feedback Loops: basierend auf Daten und Fakten Entscheidungen treffen. Das ermöglicht es dann auch, AI zu nutzen, um gewisse Entscheidungen automatisiert treffen zu lassen.\nDrei Kernpraktiken # Der CEO als Chief Evangelist. Das ist nichts, was man delegieren kann. Der CEO muss der Influencer für die Cybernetic Transformation sein. Ohne das funktioniert es nicht.\nKontinuierliche Verbesserung auf allen Ebenen. Nicht nur Retrospektiven in einzelnen Teams, sondern auf allen Ebenen der Organisation, in einem wöchentlichen oder zweiwöchentlichen Rhythmus.\nDie Cybernetic Plattform. Das Fundament, das Rückgrat des Cybernetic Enterprise. Ein Self-Service-Produkt im Unternehmen, dessen Kunden die Produktteams sind. Diese Plattform stellt die Capabilities, Tools und Prozesse bereit, die die Teams brauchen.\nWie man die Transformation startet # Meine klare Empfehlung: Klein starten. Ich würde nie eine volle Cybernetic Transformation über ein ganzes Unternehmen ausrollen. Der Weg sieht so aus:\nIn einem Bereich starten. Den Wertstrom sichtbar machen. Durch das Sichtbar machen wird klar, wo die Engpässe sind. Den aktuellen Wertstrom analysieren, die Engpässe identifizieren, daraus den zukünftigen Wertstrom ableiten.\nKritische Feedback Loops identifizieren und schliessen. Auf dem Weg zum zukünftigen Wertstrom die wichtigsten Feedback Loops etablieren.\nEine AI-augmentierte Entscheidung bewusst etablieren. Wenn die meisten Unternehmen etwas mit AI machen wollen, dann etwas Richtiges: eine konkrete, AI-gestützte Entscheidung einführen.\nVon dort aus geht man dann Wertstrom für Wertstrom weiter durch das Unternehmen.\nAI Washing und der Realitätscheck # In der Diskussion mit der Community habe ich auch über den aktuellen Hype gesprochen. Es gibt Unternehmen, die mit gewaltigen Einsparungen durch AI werben. Meine Einschätzung dazu ist differenziert: Eine MIT-Studie zeigt, dass nur etwa 5% der Unternehmen tatsächlich einen positiven Effekt auf ihre Gewinn- und Verlustrechnung durch AI sehen. 95% sehen das nicht.\nAusserdem wird sehr viel AI Washing betrieben. Man schreibt AI drauf, aber eigentlich ist es klassische Automatisierung oder Prozessoptimierung. Selbstverständlich gibt es grossartige Cases, auch bei Zühlke haben wir einige Top-Cases umgesetzt. Aber man muss vorsichtig sein mit grossen Zahlen über ein gesamtes Unternehmen.\nDie Kultur als grösste Hürde # Die schwierigste Dimension jeder Transformation ist die Kulturtransformation. Man hat potenziell ein ganzes Mittelmanagement, das es in der neuen Struktur nicht mehr braucht. Mit diesen Menschen muss man arbeiten: Wie transformiert sich ihre Rolle?\nDabei kommt es nicht auf das Alter an. Ich habe Verwaltungsräte im Rentenalter getroffen, die bezüglich AI voll dabei sind, und 40-Jährige, die völlig veränderungsresistent sind. Es hat eher etwas mit Haltung und Mindset zu tun als mit dem Alter.\nEntscheidend ist, was John Kotter in \u0026ldquo;Leading Change\u0026rdquo; beschrieben hat: Steht das Management auf einer Burning Platform? Gibt es einen wirklichen Need für den Change? Wenn das nicht gegeben ist, dann gibt es keinen Change. Und dann muss man das auch klar kommunizieren: Ohne Top-Management-Support wird der Impact gering bleiben.\n\u0026ldquo;Die Zukunft gehört jenen, die die Symphonie aus Organisation, Prozessen, Technologie und KI meistern.\u0026rdquo;\nKernaussagen # Das Betriebssystem muss sich ändern, nicht nur die Tools. AI auf alte Strukturen aufzusetzen, bringt wenig. Es braucht ein neues organisatorisches Betriebssystem. Zuerst hinterfragen, dann automatisieren. Die fünf Schritte (Hinterfragen, Streichen, Vereinfachen, Optimieren, Automatisieren) sind essentiell, bevor man AI einsetzt. Feedback Loops sind der Schlüssel. Das Cybernetic Enterprise ist ein lernendes System mit permanenten Feedback Loops auf allen Ebenen. Organisation entlang des Wertstroms. Der grösste Hebel, aber auch der grösste Kulturwandel. Der CEO muss Chief Evangelist sein. Diese Transformation kann nicht delegiert werden. Klein starten, Wertstrom für Wertstrom. Grosse Transformationen scheitern. Lieber einen Bereich transformieren und von dort aus ausbreiten. Cybernetic Plattform als Fundament. Ein Self-Service-Produkt für die Produktteams, das Capabilities, Tools und Prozesse bereitstellt. ","date":"24. December 2025","externalUrl":null,"permalink":"/de/blogs/cybernetic-enterprise-das-neue-betriebssystem-fuer-organisationen/","section":"Blogs","summary":"Die meisten Unternehmen, die heute agil arbeiten und gleichzeitig versuchen, AI zu implementieren, werden meiner Meinung nach die nächste Dekade nicht überleben. Der Grund: Ihr Betriebssystem ist zu alt. Die Zukunft ist nicht agil. Die Zukunft ist auch nicht AI. Die Zukunft ist kybernetisch.\n","title":"Cybernetic Enterprise: Das neue Betriebssystem für Organisationen","type":"blogs"},{"content":"Most companies that work in an agile way today while simultaneously trying to implement AI will not survive the next decade, in my opinion. The reason: their operating system is too old. The future is not agile. The future is not AI either. The future is cybernetic.\nIn my talk at the Zukunftsmenschen community, I explain what the Cybernetic Enterprise is, why organizations need a new operating system, and how to approach such a transformation in practice. The talk is in German.\nWhy the Traditional Model Is Reaching Its Limits # We implement Agile, we implement DevOps, some adopt SAFe, and of course now we are all doing AI as well. We want to move faster, but somehow we keep getting slower. The reason is that the traditional model in our companies has completely reached its limits.\nWe have silos: business silos, IT silos, security silos. We have governance and processes that we dress up in agile clothing. We introduce agile roles, but everything is still waterfall underneath. Then we launch a digital transformation that does nothing more than digitize the old structures.\nMy observation: we are currently optimizing for speed. But agility is really about steerability and resilience, the ability to react quickly to change. Most companies focus on AI tools, but the operating system of the organization is outdated and never truly gets updated.\nWhat Cybernetic Actually Means # The term \u0026ldquo;cybernetic\u0026rdquo; is older than the term AI. It was coined in the early 1940s, and at its core it says something quite simple: humans and machines (including AI) work together in continuous feedback loops to continuously create value.\nThis concept fascinates me because it describes exactly what today\u0026rsquo;s organizations need. It is not about replacing people with AI. We need to make people better with AI. That is a fundamental difference.\nThe Five Steps Before Automation # Too often we focus on which processes we can automate. Years ago I outlined five steps that must be followed:\nQuestion the requirements. Put a name behind every requirement: who is the owner? Ruthlessly eliminate. What is truly unnecessary in this requirement? Simplify. Make the remaining requirements as simple as possible. Optimize. Only after simplifying do you optimize. Automate. Automation comes last. The problem: we spend all our time on step 5. With everything happening around AI right now, most companies only care about the last step. But the processes and requirements behind it are never questioned.\nThe Mental Model of the Cybernetic Enterprise # In the Cybernetic Enterprise book, I developed a mental model that spans from purpose all the way down to tools. It represents the layering of an organization:\nPurpose defines the vision (a 1:1 relationship) Vision guides the mission Mission shapes the values From the values we derive principles (I have identified 16 principles) Principles define capabilities (business and IT) Capabilities lead to practices (55 in total) From practices we derive processes And only then come the tools Too many discussions start with the tools. That is like building a house starting from the roof. This mental model shows that tools are the last element, not the first.\nThree Core Principles # Among the 16 principles of the Cybernetic Enterprise, three stand out:\nOrganize along the value stream. This is the biggest lever you have, and at the same time the lever that the fewest organizations actually use. Many are afraid of this change, but it solves a great number of problems.\nEmpowered teams. Autonomous teams that independently own part of a product or an entire product and can deliver completely on their own.\nData-driven decisions. This is the foundation for feedback loops: making decisions based on data and facts. It also enables AI to automate certain decisions.\nThree Core Practices # The CEO as Chief Evangelist. This cannot be delegated. The CEO must be the influencer for the Cybernetic Transformation. Without that, it will not work.\nContinuous improvement at all levels. Not just retrospectives in individual teams, but at every level of the organization, on a weekly or biweekly cadence.\nThe Cybernetic Platform. The foundation, the backbone of the Cybernetic Enterprise. A self-service product within the company whose customers are the product teams. This platform provides the capabilities, tools, and processes the teams need.\nHow to Start the Transformation # My clear recommendation: start small. I would never roll out a full Cybernetic Transformation across an entire company. The path looks like this:\nStart in one area. Make the value stream visible. By making it visible, you see where the bottlenecks are. Analyze the current value stream, identify the bottlenecks, and derive the future value stream from there.\nIdentify and close critical feedback loops. On the way to the future value stream, establish the most important feedback loops.\nConsciously establish one AI-augmented decision. If most companies want to do something with AI, they should do something meaningful: introduce one concrete, AI-supported decision.\nFrom there, you move through the organization value stream by value stream.\nAI Washing and the Reality Check # In the discussion with the community, I also talked about the current hype. There are companies that advertise massive savings through AI. My assessment is nuanced: an MIT study shows that only about 5% of companies actually see a positive impact on their profit and loss statement from AI. 95% do not.\nThere is also a lot of AI washing going on. Companies label things as AI, but it is really just traditional automation or process optimization. Of course there are great cases, and at Zuhlke we have delivered some top cases as well. But you need to be careful with big numbers projected across an entire company.\nCulture as the Biggest Hurdle # The hardest dimension of any transformation is the cultural transformation. You potentially have an entire layer of middle management that the new structure no longer needs. You have to work with these people: how does their role transform?\nAge has nothing to do with it. I have met board members at retirement age who are fully engaged with AI, and 40-year-olds who are completely resistant to change. It has more to do with attitude and mindset than with age.\nWhat matters is what John Kotter described in \u0026ldquo;Leading Change\u0026rdquo;: is management standing on a burning platform? Is there a real need for change? If not, there will be no change. And then you need to communicate that clearly: without top management support, the impact will remain small.\n\u0026ldquo;The future belongs to those who master the symphony of organization, processes, technology, and AI.\u0026rdquo;\nKey Takeaways # The operating system must change, not just the tools. Putting AI on top of old structures yields little. You need a new organizational operating system. Question first, automate later. The five steps (question, eliminate, simplify, optimize, automate) are essential before deploying AI. Feedback loops are the key. The Cybernetic Enterprise is a learning system with permanent feedback loops at all levels. Organize along the value stream. The biggest lever, but also the biggest cultural shift. The CEO must be Chief Evangelist. This transformation cannot be delegated. Start small, value stream by value stream. Large transformations fail. Transform one area first and expand from there. The Cybernetic Platform as the foundation. A self-service product for the product teams that provides capabilities, tools, and processes. ","date":"24 December 2025","externalUrl":null,"permalink":"/en/blogs/cybernetic-enterprise-the-new-operating-system-for-organizations/","section":"Blogs","summary":"Most companies that work in an agile way today while simultaneously trying to implement AI will not survive the next decade, in my opinion. The reason: their operating system is too old. The future is not agile. The future is not AI either. The future is cybernetic.\n","title":"Cybernetic Enterprise: The New Operating System for Organizations","type":"blogs"},{"content":"","date":"24 December 2025","externalUrl":null,"permalink":"/en/tags/cybernetic-transformation/","section":"Tags","summary":"","title":"Cybernetic Transformation","type":"tags"},{"content":"","date":"24. December 2025","externalUrl":null,"permalink":"/de/tags/kontinuierliche-verbesserung/","section":"Tags","summary":"","title":"Kontinuierliche Verbesserung","type":"tags"},{"content":"","date":"24. December 2025","externalUrl":null,"permalink":"/de/tags/organisationsentwicklung/","section":"Tags","summary":"","title":"Organisationsentwicklung","type":"tags"},{"content":"","date":"24 December 2025","externalUrl":null,"permalink":"/en/tags/organizational-development/","section":"Tags","summary":"","title":"Organizational Development","type":"tags"},{"content":"","date":"24 December 2025","externalUrl":null,"permalink":"/en/tags/value-stream/","section":"Tags","summary":"","title":"Value Stream","type":"tags"},{"content":"","date":"24. December 2025","externalUrl":null,"permalink":"/de/tags/wertstrom/","section":"Tags","summary":"","title":"Wertstrom","type":"tags"},{"content":" Digital und agil war gestern # Viele Unternehmen glauben, dass sie mit einer Prise Agilität und schnellen KI-Pilotprojekten ihre Zukunft sichern können. Doch wer Künstliche Intelligenz nur auf veraltete Strukturen „aufpfropft\u0026quot;, wird scheitern. Es braucht ein radikales Upgrade des Betriebsmodells.\nScrum-Meetings, bunte Kanban-Boards und schicke Innovation-Labs: Viele Unternehmen halten sich für „agil\u0026quot;. Nun stürzen sie sich kopflos auf Künstliche Intelligenz (KI), in der Hoffnung auf schnellen Wettbewerbsvorteil. Doch die Realität sieht ernüchternd aus: Allzu oft bleibt der Return on Investment (ROI) aus. Wie die Erfahrungen aus Projekten zeigen, wird KI keine fehlerhaften Prozesse reparieren, keine dysfunktionalen Organisationen heilen und keine schlechte Unternehmenskultur umdrehen können. Wer meint, ein Sprachmodell könne ohne tiefgreifenden Wandel das Geschäftsmodell neu erfinden, verkennt die Lage.\nDie meisten dieser Unternehmen werden die kommenden Jahre kaum überleben, denn ihr „Betriebssystem\u0026quot; ist veraltet. Sie optimieren im Alten, statt das Neue zu bauen. Genau hierin liegt die Gefahr: Nach zwei Jahrzehnten digitaler Transformation sind viele Firmen zwar effizienter, aber oft nur in Silos oder einzelnen Prozessen. Dieser „More of the same\u0026quot;-Ansatz führt direkt ins Aus. Punktuelle Verbesserungen wirken wie Schmerzmittel: Sie lindern Symptome, während die Kernprobleme, starre Strukturen, isolierte Daten, zersplitterte Verantwortung, bestehen bleiben. Im Zeitalter von KI ist das fatal. Die Agilität der Vergangenheit, meist begrenzt auf IT-Teams oder einzelne Innovationsprojekte, greift zu kurz, wenn systemische Anpassungsfähigkeit gefordert ist.\n(Illustration 1)\nDigitale Transformation in Silos: Wenn Agilität zu kurz greift (aus dem Buch „The Cybernetic Enterprise\u0026quot; von Romano Roth).\nCybernetic Enterprise: das Betriebsmodell für morgen # Was Unternehmen jetzt brauchen, ist ein gedankliches und begriffliches Upgrade: Das „Cybernetic Enterprise\u0026quot; ist Betriebsmodell und Mindset zugleich. Inspiriert vom griechischen Wort „Kybernetes\u0026quot; (Steuermann) steht es für ein Unternehmen als dynamisches System, das auf Feedbackschleifen basiert und sich selbst steuern kann. In einer solchen lern- und anpassungsfähigen Organisation spielen Technologie, Prozesse und Struktur in einem intelligenten Dreiklang nahtlos zusammen. Dieses System ähnelt dem menschlichen Nervensystem. Es verarbeitet permanent Informationen und übersetzt sie in Handlungen.\nEin Cybernetic Enterprise ist nicht auf kurzfristige Effizienz ausgelegt, sondern auf langfristige Anpassungsfähigkeit, Resilienz und nachhaltige Wertschöpfung. Entscheidungen beruhen systematisch auf Daten, Teams agieren dezentral nach gemeinsamen Prinzipien und die technologische Infrastruktur, quasi das Rückgrat des Unternehmens, ermöglicht eine permanente Weiterentwicklung. KI ist dabei kein isoliertes Tool mehr, das man bei Bedarf „überstülpt\u0026quot;, sondern integraler Bestandteil der DNA der Organisation und ihrer Prozesse.\n(Illustration 2)\nCybernetic Enterprise: KI als integraler Bestandteil der Organisation (aus dem Buch „The Cybernetic Enterprise\u0026quot; von Romano Roth).\nEntscheidend ist, dass alle Ebenen der Firma auf das gleiche Ziel ausgerichtet sind. Vom Purpose über die Strategie und die Werte bis hin zu den Tools: Jede Schicht muss auf die übergeordnete Vision einzahlen. Dieses „Layered Mental Model\u0026quot; sorgt für ein vertikales Alignment. Das heißt: Jede Entscheidung und Aktion, ob auf Management- oder Teamebene, folgt den gemeinsamen Zielen und Prinzipien. In Strategie-Workshops lässt sich das überprüfen, indem man alle Artefakte den Schichten „Zweck-Werte-Prozesse-Tools\u0026quot; zuordnet und Lücken offenlegt. So wird das Unternehmen wirklich kohärent, eine Grundvoraussetzung, um mit KI wirklich Wirkung zu erzielen. Denn ohne Klarheit in Daten, Entscheidungen und Zusammenarbeit geht es nicht.\nDie Ziele dieses neuen Betriebsmodells lassen sich klar benennen: langfristige Anpassungsfähigkeit, kontinuierliches Lernen und nachhaltige Wertschöpfung. Anders gesagt: Ein Unternehmen soll schneller lernen als der Markt sich wandelt, und so auf Dauer überleben.\n(Illustration 3)\nVoraussetzung für wirkungsvolle KI: eine Zielrichtung, durch alle Ebenen des Unternehmens.\nDrei zentrale Prinzipien # Wie wird aus einem Unternehmen ein Cybernetic Enterprise? Insgesamt 16 Prinzipien, die aufeinander aufbauen und ineinandergreifen, lassen sich dabei identifizieren. Drei stehen besonders im Mittelpunkt.\n1. Organisation für den Wertfluss # Statt Abteilungen nach Funktionen oder Hierarchien zu organisieren, stellt das Cybernetic Enterprise den Wertstrom in den Mittelpunkt. Das bedeutet: weg von der lokalen Optimierung einzelner Prozessschritte, hin zur End-to-End-Automatisierung und -Optimierung entlang des gesamten Geschäftsprozesses. So fließt der Wert ohne Reibungsverluste zum Kunden.\nEin geeignetes Vorgehen dafür ist Value Stream Mapping, um aktuelle Abläufe transparent zu machen und Engpässe oder Schleifen aufzudecken. In der Praxis zeigt sich, dass intelligente Automatisierung entlang des Wertstroms enorme Effizienzgewinne bringt, verglichen mit punktueller Digitalisierung. Beispielsweise lassen sich Routineentscheidungen durch KI-Agenten treffen, während Menschen sich auf komplexe Fälle konzentrieren.\nWertstromorientierung geht zudem Hand in Hand mit Kundenzentrierung. Nur wer den gesamten Weg bis zum Kunden versteht, kann Innovation wirklich am Nutzerbedarf ausrichten. Methoden wie Rapid Prototyping und kontrollierte Experimente helfen, früh echtes Nutzerfeedback einzuholen und Entscheidungen zu validieren. Dadurch werden Lernzyklen beschleunigt und das Risiko teurer Fehlentwicklungen minimiert sich. Das Unternehmen lernt ständig dazu.\n2. Ermächtigte Teams statt Hierarchie # Empowerment ist ein zentrales Prinzip im Cybernetic Enterprise. Es bedeutet, Entscheidungen dort zu treffen, wo das Wissen ist, nicht in entfernten Chefetagen. Teams übernehmen End-to-End die Verantwortung für ihre Produkte und Services und arbeiten iterativ sowie nah am Nutzer. Diese Dezentralisierung steigert Tempo und Relevanz, weil unnötige Abstimmungsschleifen entfallen und Lösungen kundenorientierter werden.\nFührung durch Kontext statt durch Kontrolle ist hier gefragt: Leitplanken werden klar kommuniziert („Guardrails as Code\u0026quot;), aber innerhalb dieser Grenzen haben Teams Freiraum. So entsteht eine Kultur vertrauensbasierter Selbststeuerung statt bürokratischer Kontrolle.\nEmpowerment heißt aber nicht Chaos. Das Zusammenspiel von Organisation, Technologie und Prozessen muss abgestimmt bleiben. Wichtig ist dabei auch die Weiterbildung: Mitarbeiter aller Ebenen brauchen neue Kompetenzen, vom systemischen Denken bis zur Datenkompetenz und -ethik, um etwa KI-Modellentscheidungen nachvollziehen zu können und in KI-getriebenen Umgebungen Verantwortung zu übernehmen. Unternehmen müssen also massiv in neue Skills und Rollen investieren.\n3. Datengetriebene Entscheidungen und kontinuierliches Lernen # In traditionellen Unternehmen dominieren häufig Bauchgefühl oder starre Jahrespläne die Entscheidungen. Das Cybernetic Enterprise dreht dieses Paradigma um: Daten und Feedback werden zum Kompass jeder Entscheidung. „Telemetrie everywhere\u0026quot; lautet die Devise. Von der Maschine auf dem Shopfloor bis zum Management-Dashboard werden live Daten erhoben. Die Organisation wird „datenfühlig\u0026quot;: Sie erkennt Muster frühzeitig, reagiert situativ und optimiert kontinuierlich auf Basis objektiver Infos statt Meinungen.\nEin praktisches Beispiel ist die Closed-Loop-Feedback-Schleife: Kundenfeedback fließt in Echtzeit in die Produktentwicklung zurück, Nutzungsdaten steuern die Priorisierung im Portfolio und KI überwacht Prozesse ständig auf Anomalien, um sofort gegensteuern zu können. Dadurch entsteht ein selbstlernendes System. KI-Modelle unterliegen einem kontinuierlichen Lifecycle Management und passen sich so veränderten Bedingungen an, ein wesentlicher Unterschied zum klassisch-starren IT-System.\nDatengetrieben heißt auch, Erfolg anders zu messen. An die Stelle rein output-orientierter KPIs (wie Stückzahlen oder Stunden) treten Flow- und Outcome-Metriken (wie Durchlaufzeiten entlang des Wertstroms, Time-to-Learn oder tatsächlicher Wertbeitrag).\nZentral für datengetriebene Entscheidungen ist eine robuste Daten- und Feedbackarchitektur, die alle relevanten Quellen intelligent verbindet. Gleichzeitig gilt es, Datenqualität und Governance sicherzustellen („Policies as Code\u0026quot;) und Zugriffsschutz nach Zero-Trust-Prinzipien zu gewährleisten.\nSchließlich bedingt eine lernende Organisation auch eine Kultur des kontinuierlichen Experimentierens und Verbesserns. „Safe-to-fail\u0026quot; statt „Fehler vermeiden um jeden Preis\u0026quot;: Lieber neue Ideen in kleinem Umfang und mit schnellem Lerneffekt testen als große Projekte ohne Feedback umsetzen. Weniger ist mehr, Fokus schlägt Feature-Fülle. Die permanenten Feedback-Schleifen sind der Motor, der die Organisation am Laufen hält. Transformation als dauerhafter Lernprozess, und das Unternehmen als lebendes System, das sich immer wieder anpasst.\nIn der Praxis # Konkrete Praktiken untermauern die genannten Prinzipien. Drei exemplarische Ansätze zeigen, wie sich die Theorie in die Tat umsetzen lässt.\n1. Cybernetic Platform # Das technische Rückgrat der Cybernetic Enterprise ist eine interne Self-Service-Plattform. Sie bündelt alle Werkzeuge und Dienste, die Teams für eine schnelle und sichere Entwicklung brauchen. Heißt: Sie stellt Infrastruktur, Datenintegration, Automatisierung und KI-Komponenten „as a Service\u0026quot; bereit. Durch Standards und Automatisierung reduziert sie Reibungsverluste und schafft Freiräume für Innovation. Wichtig: Governance ist automatisiert in die Plattform eingebaut und bremst die Entwickler nicht aus. Eine solche Plattform ersetzt den früheren Tool-Zoo und wird so zum strategischen „Enabler\u0026quot;.\n2. Kontinuierliche Verbesserung # Kaizen im KI-Zeitalter: Was Toyota einst in der Produktion vormachte, gilt heute für das ganze Unternehmen. „Continuous Improvement\u0026quot; ist kein Schlagwort, sondern organisatorischer Pulsschlag. Prozesse optimieren sich durch eingebaute Feedbacks selbst. Fehler werden nicht vertuscht, sondern als Lernchancen gesehen. Führungskräfte etablieren einen Regelkreis des Lernens. Das Prinzip „Outcome vor Output\u0026quot; fördert, dass nicht Beschäftigtsein honoriert wird, sondern tatsächliche Wirkung. Unternehmen, die kontinuierlich iterieren und lernen, entwickeln eine evolutionäre Vorsprungskultur gegenüber trägen Wettbewerbern.\n3. CEO als Chief Evangelist # Chefsache Transformation: Das Top-Management, allen voran der CEO, muss unermüdlich das Warum und Wohin der Reise kommunizieren, die Dringlichkeit im ganzen Haus verankern, Hindernisse beseitigen, Schutzräume für Experimente schaffen, sichtbare Verbesserungen öffentlich belohnen und Erfolge erzählen. Wenn der CEO persönlich Vorbild ist, zum Beispiel eigene KI-Weiterbildungen absolviert oder jede Woche mit den Produktteams spricht, sendet das eine unmissverständliche Botschaft: Die Cybernetic Transformation hat höchste Priorität und ist kein „IT-Projektchen\u0026quot;. Der „Chief Evangelist\u0026quot; orchestriert so die vielen Initiativen zu einer gemeinsamen Zukunftsbewegung.\nFazit: Evolution statt Revolution, aber jetzt beginnen # Der Weg zum Cybernetic Enterprise ist keine brachiale Revolution über Nacht, sondern eine schrittweise Evolution. Doch er muss jetzt starten. Halbherzige „Weiter so, aber mit KI\u0026quot;-Initiativen greifen zu kurz. Digitalisierung war gestern; heute geht es um die Cybernetic Transformation. Das bedeutet, das Unternehmen als lebendes, lernfähiges System zu begreifen, in dem Mensch und Maschine eng verzahnt zusammenwirken. Wer Organisation, Technologie und Prozesse intelligent orchestriert, wird die KI-Welle nicht nur überstehen, sondern reiten.\nDie gute Nachricht: Jedes etablierte Unternehmen kann den Sprung schaffen, mit klarer Vision, mutiger Führung und dem festen Willen, heute die Lernkurve von morgen in Gang zu setzen. Denn die Transformation endet nie, sie lernt immer dazu.\nOriginal Artikel in Computerworld Nr. 4, 12. Dezember 2025: https://www.computerworld.ch/\n","date":"11. December 2025","externalUrl":null,"permalink":"/de/blogs/die-ki-zukunft-ist-kybernetisch/","section":"Blogs","summary":"Digital und agil war gestern # Viele Unternehmen glauben, dass sie mit einer Prise Agilität und schnellen KI-Pilotprojekten ihre Zukunft sichern können. Doch wer Künstliche Intelligenz nur auf veraltete Strukturen „aufpfropft\", wird scheitern. Es braucht ein radikales Upgrade des Betriebsmodells.\n","title":"Die KI-Zukunft ist «cybernetic»","type":"blogs"},{"content":"","date":"11 December 2025","externalUrl":null,"permalink":"/en/tags/publications/","section":"Tags","summary":"","title":"Publications","type":"tags"},{"content":"","date":"11. December 2025","externalUrl":null,"permalink":"/de/tags/publikationen/","section":"Tags","summary":"","title":"Publikationen","type":"tags"},{"content":" Digital and agile was yesterday # Many companies believe they can secure their future with a dash of agility and rapid AI pilot projects. But those who simply \u0026ldquo;graft\u0026rdquo; artificial intelligence onto outdated structures will fail. A radical upgrade of the operating model is needed.\nScrum meetings, colorful Kanban boards, and sleek innovation labs: Many companies consider themselves \u0026ldquo;agile.\u0026rdquo; Now they\u0026rsquo;re rushing headlong into artificial intelligence (AI) - hoping for a quick competitive advantage. But the reality is sobering: All too often, the return on investment (ROI) fails to materialize. As project experience shows, AI won\u0026rsquo;t fix flawed processes, heal dysfunctional organizations, or reverse a bad corporate culture. Anyone who thinks a language model can reinvent the business model without fundamental change is misjudging the situation.\nMost of these companies will hardly survive the coming years, because their \u0026ldquo;operating system\u0026rdquo; is outdated. They\u0026rsquo;re optimizing the old system instead of building the new one. This is precisely where the danger lies: After two decades of digital transformation, many companies are indeed more efficient, but often only in silos or isolated processes. This \u0026ldquo;more of the same\u0026rdquo; approach leads directly to failure. Isolated improvements act like painkillers: They alleviate symptoms while the core problems, rigid structures, isolated data, fragmented responsibilities, remain. In the age of AI, this is fatal. The agility of the past, usually limited to IT teams or individual innovation projects, falls short when systemic adaptability is required.\n(Illustration 1)\nDigital Transformation in Silos: When Agility Falls Short (from the book \u0026ldquo;The Cybernetic Enterprise\u0026rdquo; by Romano Roth).\nCybernetic Enterprise: the operating model for tomorrow # What companies need now is a conceptual and conceptual upgrade: The \u0026ldquo;Cybernetic Enterprise\u0026rdquo; is both an operating model and a mindset. Inspired by the Greek word \u0026ldquo;cybernetes\u0026rdquo; (helmsman), it represents a company as a dynamic system based on feedback loops and capable of self-regulation. In such a learning and adaptable organization, technology, processes, and structure work seamlessly together in an intelligent triad. This system resembles the human nervous system. It constantly processes information and translates it into actions.\nA cybernetic enterprise is not designed for short-term efficiency, but for long-term adaptability, resilience, and sustainable value creation. Decisions are systematically based on data, teams operate decentrally according to shared principles, and the technological infrastructure, essentially the backbone of the company, enables continuous development. AI is no longer an isolated tool that can be \u0026ldquo;imposed\u0026rdquo; as needed, but rather an integral part of the organization\u0026rsquo;s DNA and its processes.\n(Illustration 2)\nCybernetic Enterprise: AI as an integral part of the organization (from the book \u0026ldquo;The Cybernetic Enterprise\u0026rdquo; by Romano Roth).\nCrucially, all levels of the company must be aligned toward the same goal. From purpose and strategy to values and tools, every layer must contribute to the overarching vision. This \u0026ldquo;layered mental model\u0026rdquo; ensures vertical alignment. This means that every decision and action, whether at the management or team level, follows the shared goals and principles. Strategy workshops can verify this by assigning all artifacts to the layers of \u0026ldquo;purpose, values, processes, and tools\u0026rdquo; and identifying any gaps. This is how the company becomes truly coherent, a fundamental prerequisite for achieving real impact with AI. Because without clarity in data, decisions, and collaboration, it simply won\u0026rsquo;t work.\nThe goals of this new operating model can be clearly defined: long-term adaptability, continuous learning, and sustainable value creation. In other words: a company should learn faster than the market changes, and thus survive in the long run.\n(Illustration 3)\nA prerequisite for effective AI: a clear direction, across all levels of the company.\nThree central principles # How does a company become a cybernetic enterprise? A total of 16 principles, which build upon and interlock with one another, can be identified. Three are particularly central.\n1. Organization for the flow of value # Instead of organizing departments according to functions or hierarchies, the Cybernetic Enterprise focuses on the value stream. This means moving away from the local optimization of individual process steps and towards end-to-end automation and optimization along the entire business process. In this way, value flows to the customer without friction.\nA suitable approach for this is value stream mapping, which makes current processes transparent and uncovers bottlenecks or loops. In practice, intelligent automation along the value stream shows that it brings enormous efficiency gains, compared to isolated digitization efforts. For example, routine decisions can be made by AI agents, while humans can concentrate on complex cases.\nValue stream mapping goes hand in hand with customer centricity. Only those who understand the entire customer journey can truly align innovation with user needs. Methods like rapid prototyping and controlled experiments help gather genuine user feedback early on and validate decisions. This accelerates learning cycles and minimizes the risk of costly mistakes. The company is constantly learning.\n2. Empowered teams instead of hierarchy # Empowerment is a core principle of the Cybernetic Enterprise. It means making decisions where the knowledge resides, not in remote executive suites. Teams take end-to-end responsibility for their products and services, working iteratively and closely with the user. This decentralization increases speed and relevance because unnecessary approval processes are eliminated and solutions become more customer-centric.\nLeadership through context rather than control is key here: Guidelines are clearly communicated (\u0026ldquo;Guardrails as Code\u0026rdquo;), but within these boundaries, teams have freedom. This fosters a culture of trust-based self-management instead of bureaucratic control.\nEmpowerment doesn\u0026rsquo;t mean chaos. The interplay of organization, technology, and processes must remain coordinated. Continuing education is also crucial: employees at all levels need new skills, from systems thinking to data literacy and ethics, to understand AI model decisions and take responsibility in AI-driven environments. Companies must therefore invest heavily in new skills and roles.\n3. Data-driven decisions and continuous learning # In traditional companies, gut feeling or rigid annual plans often dominate decision-making. The Cybernetic Enterprise reverses this paradigm: data and feedback become the compass for every decision. \u0026ldquo;Telemetry everywhere\u0026rdquo; is the motto. Data is collected live from the machine on the shop floor to the management dashboard. The organization becomes \u0026ldquo;data-sensitive\u0026rdquo;: it recognizes patterns early, reacts situationally, and continuously optimizes based on objective information rather than opinions.\nA practical example is the closed-loop feedback loop: Customer feedback flows back into product development in real time, usage data controls portfolio prioritization, and AI constantly monitors processes for anomalies to enable immediate corrective action. This creates a self-learning system. AI models are subject to continuous lifecycle management and thus adapt to changing conditions, a key difference from a traditional, rigid IT system.\nBeing data-driven also means measuring success differently. Purely output-oriented KPIs (such as unit sales or hours) are replaced by flow and outcome metrics (such as lead times along the value stream, time-to-learn, or actual value contribution).\nCentral to data-driven decisions is a robust data and feedback architecture that intelligently connects all relevant sources. At the same time, it is essential to ensure data quality and governance (\u0026ldquo;policies as code\u0026rdquo;) and guarantee access protection according to zero-trust principles.\nUltimately, a learning organization also requires a culture of continuous experimentation and improvement. \u0026ldquo;Safe to fail\u0026rdquo; instead of \u0026ldquo;avoiding mistakes at all costs\u0026rdquo;: It\u0026rsquo;s better to test new ideas on a small scale with a rapid learning effect than to implement large projects without feedback. Less is more, focus trumps feature overload. The constant feedback loops are the engine that keeps the organization running. Transformation as an ongoing learning process, and the company as a living system that constantly adapts.\nIn practice # Concrete practices underpin these principles. Three exemplary approaches demonstrate how the theory can be put into practice.\n1. Cybernetic Platform # The technical backbone of Cybernetic Enterprise is an internal self-service platform. It consolidates all the tools and services teams need for rapid and secure development. This means it provides infrastructure, data integration, automation, and AI components \u0026ldquo;as a service.\u0026rdquo; Through standards and automation, it reduces friction and creates space for innovation. Importantly, governance is automatically integrated into the platform and doesn\u0026rsquo;t hinder developers. Such a platform replaces the previous collection of tools and thus becomes a strategic enabler.\n2. Continuous improvement # Kaizen in the AI age: What Toyota once pioneered in production now applies to the entire company. \u0026ldquo;Continuous Improvement\u0026rdquo; is not just a buzzword, but the organization\u0026rsquo;s lifeblood. Processes optimize themselves through built-in feedback. Mistakes are not covered up, but seen as learning opportunities. Leaders establish a learning cycle. The principle of \u0026ldquo;outcome before output\u0026rdquo; promotes rewarding actual impact, not mere busywork. Companies that continuously iterate and learn develop an evolutionary competitive advantage over sluggish competitors.\n3. CEO as Chief Evangelist # Transformation is a top priority: Top management, especially the CEO, must tirelessly communicate the why and where of the journey, instill urgency throughout the organization, remove obstacles, create safe spaces for experimentation, publicly reward visible improvements, and share successes. When the CEO personally leads by example, for instance, by completing their own AI training or speaking with product teams weekly, it sends an unmistakable message: Cybernetic transformation is a top priority and not just a minor IT project. In this way, the \u0026ldquo;Chief Evangelist\u0026rdquo; orchestrates the many initiatives into a unified movement toward the future.\nConclusion: Evolution rather than revolution, but start now! # The path to the Cybernetic Enterprise is not a sudden, overnight revolution, but a gradual evolution. However, it must begin now. Half-hearted \u0026ldquo;business as usual, but with AI\u0026rdquo; initiatives fall short. Digitization was yesterday; today it\u0026rsquo;s about Cybernetic Transformation. This means understanding the company as a living, learning system in which humans and machines work closely together. Those who intelligently orchestrate organization, technology, and processes will not only survive the AI wave, but ride it.\nThe good news: Every established company can make the leap, with a clear vision, courageous leadership, and the firm will to set tomorrow\u0026rsquo;s learning curve in motion today. Because transformation never ends. It\u0026rsquo;s a continuous learning process.\nOriginal Article in Computerworld Nr. 4 12. Dezember 2025 https://www.computerworld.ch/\n","date":"11 December 2025","externalUrl":null,"permalink":"/en/blogs/the-ai-future-is-cybernetic/","section":"Blogs","summary":"Digital and agile was yesterday # Many companies believe they can secure their future with a dash of agility and rapid AI pilot projects. But those who simply “graft” artificial intelligence onto outdated structures will fail. A radical upgrade of the operating model is needed.\n","title":"The AI future is \"cybernetic\"","type":"blogs"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/agile-transformation/","section":"Tags","summary":"","title":"Agile Transformation","type":"tags"},{"content":"","date":"7. December 2025","externalUrl":null,"permalink":"/de/tags/agilit%C3%A4t/","section":"Tags","summary":"","title":"Agilität","type":"tags"},{"content":"Wie viel Agilität verträgt Softwareentwicklung wirklich, und wo kippt Agilität in Chaos? In der Podcast-Folge \u0026ldquo;Modern Work 2 Go\u0026rdquo; spreche ich mit Florian Schneider über genau diese Fragen. Wir tauchen tief ein in ein konkretes Praxisbeispiel: eine agile Transformation bei einer Schweizer Bank, die ich über acht Jahre begleitet habe. Dabei geht es um die Umstellung von Wasserfall auf Agilität, die Skalierung mit SAFe, den Aufbau von Wertströmen und die Frage, warum Continuous Improvement der zentrale Pfeiler jeder Transformation ist.\nDer Ausgangspunkt: Wasserfall trifft auf Realität # 2016 kam ich zu einem Projekt bei einer Bank, das ein regulatorisches System MiFID-II-konform machen musste. Die Deadline war Ende 2017. Der ursprüngliche Plan sah klassisch aus: vier Teams, aufgeteilt nach technischen Schichten (UI, Backend, Datenbank, Services), mit je einem Projektleiter, zwei Business-Analysten, einem Entwickler und einem QA. Geplant waren sechs Monate Spezifikation, drei Monate Implementierung und drei Monate Testen.\nFür mich war sofort klar: Das wird so nicht funktionieren. Nach etwa zwei Wochen habe ich der Programmleitung vorgeschlagen, ein einfaches Experiment zu machen. Wir haben einen kleinen Durchstich versucht, ein kleines Feature mit den bestehenden Teams end-to-end implementiert und in eine Testumgebung gebracht. Das Ergebnis war eine Katastrophe. Es hat hinten und vorne nicht funktioniert. Aber genau dieses Experiment hat zum Umdenken geführt.\nDie agile Wende: Domain-Driven Design und ehrliche Vorhersagen # Wir haben die Teams nach Domain-Driven Design umgestaltet: Domänen identifiziert, die Teams wirklich end-to-end verantwortlich gemacht für ihren Bounded Context. Dann haben wir ein Backlog aufgebaut, Epics geschätzt, die Velocity gemessen und einen Burn-up Chart erstellt.\nDie ehrliche Prognose war ernüchternd: Bis November 2017 konnten wir genau ein Drittel des Backlogs liefern. Zwei Drittel waren nicht machbar. Das Management wollte natürlich Wochenendarbeit und Zwölf-Stunden-Tage anordnen. Meine Antwort: Wenn wir das machen, kriegen wir wahrscheinlich gar nichts hin. Stattdessen haben wir das Backlog konsequent priorisiert.\n\u0026ldquo;Ende des Jahres hatten wir das System MiFID-compliant in Betrieb. Genau die Vorhersage ist eingetroffen: Wir haben das nötige Drittel geliefert. Und die anderen zwei Drittel? Die sind im Januar einfach verschwunden, implodiert. Es war Wunschkonzert.\u0026rdquo;\nDas war eine prägende Erfahrung. Zwei Drittel des ursprünglichen Backlogs waren letztlich nicht nötig. Der priorisierte Drittel hat vollständig ausgereicht, um die regulatorischen Anforderungen zu erfüllen.\nSkalierung: Warum SAFe allein keine Lösung ist # Von vier Teams sind wir auf zehn Teams hochgefahren. Wir haben Scrum of Scrum eingeführt, ergänzt durch ausgewählte SAFe-Elemente wie Mini-PI-Plannings und Sync-Meetings. Scrum of Scrum hätte eigentlich gereicht. Aber die Bank hat als Ganzes auf SAFe umgestellt, und wir wurden zum Agile Release Train erklärt.\nWas wir gemacht haben: Die Rollen umbenannt, das PI-Planning vom vollen Zwei-Tage-Format auf einen halben Tag reduziert, und de facto weiterhin Scrum of Scrum praktiziert. Der entscheidende Unterschied zu anderen Teams in der Bank war, dass wir den Continuous Improvement Sprint beibehalten haben.\nViele SAFe-Implementierungen scheitern daran, dass genau dieser Innovation Sprint als Erstes abgeschafft wird, weil man Features liefern \u0026ldquo;muss\u0026rdquo;. Damit macht man SAFe by the Book, denn man verbessert sich nie. Unser Agile Release Train war einer der Vorzeige-ARTs, während andere Teams klagten, sie kämen vor lauter Synchronisationsmeetings nicht mehr zum Arbeiten.\nMeine klare Empfehlung: SAFe ergibt Sinn, wenn du mehr als 50 Personen hast, die an einem Produkt mit harten Abhängigkeiten zwischen Teams arbeiten. Wenn du aber die Abhängigkeiten organisatorisch, prozesstechnisch und architektonisch auflösen kannst, brauchst du das Framework gar nicht. Dann können Teams autonom arbeiten, und das ist das eigentliche Ziel.\nDie Silos aufbrechen: IT und Business verschmelzen # Eines der prägendsten Erlebnisse war der Konflikt zwischen IT und Business. Die Bank war klassisch aufgebaut: IT-Silo und Business-Silo. Unser Programmmanager sass im Business, das IT-Management bestand auf dem Wasserfallprozess. Es gab Wetten über mehrere tausend Schweizer Franken, dass unser Projekt scheitern würde.\nAls wir Ende 2017 erfolgreich lieferten, wollte die IT das Team zurückholen und zum Wasserfall zurückkehren. Stattdessen hat das Business das Entwicklungsteam komplett übernommen. Dadurch wurden die Entscheidungswege kürzer und die Effizienz stieg nochmals deutlich.\nDiese Erfahrung hat eine Überzeugung gefestigt, die ich seitdem in vielen Projekten bestätigt sehe: In fortschrittlichen Unternehmen wird die Trennung zwischen IT und Business verschwinden. Es wird nur noch crossfunktionale Teams geben, die an einem Produkt arbeiten und auf einer gemeinsamen Plattform aufsetzen.\nVon Wertströmen zur Organisationsveränderung # Über die Jahre hat die Bank Wertströme eingeführt. Die ersten Wertströme waren entlang politischer Linien geschnitten und führten zu massiven Friktionen. Doch schrittweise hat man gelernt. Der wirkliche Durchbruch kam, als Wertströme end-to-end Verantwortung bekamen, inklusive Budget und dem Prinzip \u0026ldquo;You build it, you run it\u0026rdquo;.\nPlötzlich wurde aufgeräumt: Applikationen, von denen niemand wusste, dass sie existieren. Applikationen mit fünf Benutzern und riesigem Wartungsaufwand. Doppelte Capabilities. Das unternehmerische Denken kam in die Wertströme, und die Effizienz stieg massiv.\nHeute geht die Bank den nächsten Schritt und baut auch die Aufbauorganisation um: Der Release Train Engineer wird zum Vorgesetzten der Entwickler, der Product Manager zum Vorgesetzten der Product Owner. Ablauf- und Aufbauorganisation verschmelzen im Wertstrom.\nAI und Vibecoding: Warum sauberes Software Engineering wichtiger wird # Im Gespräch kommen wir auch auf die Rolle von AI und Vibecoding zu sprechen. Bei Zühlke setzen wir AI konsequent ein, sie augmentiert unsere Arbeit, ersetzt aber keine Menschen. Wir haben unsere eigene Cybernetic Delivery Method, die beschreibt, wie wir zusammen mit AI Software entwickeln.\nWas ich beim Vibecoding gelernt habe: Du musst genau spezifizieren und Tests schreiben. Für mich als DevOps Thought Leader geht damit ein Traum in Erfüllung, denn AI zwingt uns zu sauberem Software Engineering. Du musst sauber beschreiben, was du willst, deine Tests müssen stimmen, und die Software muss modular architektiert sein, damit der Kontext klein bleibt.\nGleichzeitig sehen wir bei unseren monatlichen AI Exchanges, dass viele erfahrene Software Engineers den Copiloten für Boilerplate Code und Tests nutzen, ihn aber abschalten, wenn es um wirklich neue Algorithmen geht. AI ist kein Allheilmittel. Sie kann kein SAP aus dem Boden stampfen, und man muss in kleinen Schritten vorgehen.\nKernaussagen # Continuous Improvement ist der zentrale Pfeiler. Jeden Tag überlegen, was morgen besser sein kann, und konstant am System arbeiten. Ohne diesen Pfeiler wird jedes Framework zur Bürokratie.\nC-Level Support ist entscheidend. Ohne ein klares Mandat von oben bleiben agile Transformationen auf der Ebene einzelner Teams stecken. Grosse Veränderungen brauchen grosse Unterstützung.\nAbhängigkeiten sind der eigentliche Feind. Nicht fehlendes Tooling oder falsche Frameworks bremsen Teams aus, sondern organisatorische, prozessuale und architektonische Abhängigkeiten. Löse diese auf, und du brauchst weniger Koordination.\nTransformation braucht Geduld. Nicht jede Organisation kann oder muss sich über Nacht verändern. Kleine, kontinuierliche Schritte können genauso zum Ziel führen, solange man dranbleibt.\nEhrliche Vorhersagen schützen vor Wunschkonzert. Priorisierung auf Basis von Daten (Velocity, Burn-up Charts) schafft Transparenz. Oft zeigt sich, dass ein grosser Teil der Anforderungen gar nicht nötig ist.\nAI macht sauberes Engineering wichtiger, nicht überflüssig. Vibecoding und AI-gestützte Entwicklung funktionieren nur mit klaren Spezifikationen, guten Tests und modularer Architektur.\n","date":"7. December 2025","externalUrl":null,"permalink":"/de/blogs/agilitaet-in-aktion-mindset-prozesse-und-echte-ergebnisse/","section":"Blogs","summary":"Wie viel Agilität verträgt Softwareentwicklung wirklich, und wo kippt Agilität in Chaos? In der Podcast-Folge “Modern Work 2 Go” spreche ich mit Florian Schneider über genau diese Fragen. Wir tauchen tief ein in ein konkretes Praxisbeispiel: eine agile Transformation bei einer Schweizer Bank, die ich über acht Jahre begleitet habe. Dabei geht es um die Umstellung von Wasserfall auf Agilität, die Skalierung mit SAFe, den Aufbau von Wertströmen und die Frage, warum Continuous Improvement der zentrale Pfeiler jeder Transformation ist.\n","title":"Agilität in Aktion: Mindset, Prozesse und echte Ergebnisse","type":"blogs"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/agility/","section":"Tags","summary":"","title":"Agility","type":"tags"},{"content":"How much agility can software development really handle, and where does agility tip into chaos? In this episode of the \u0026ldquo;Modern Work 2 Go\u0026rdquo; podcast (in German), I speak with Florian Schneider about exactly these questions. We dive deep into a concrete real-world example: an agile transformation at a Swiss bank that I accompanied over eight years. The conversation covers the shift from waterfall to agility, scaling with SAFe, building value streams, and why continuous improvement is the central pillar of every transformation.\nThe Starting Point: Waterfall Meets Reality # In 2016, I joined a project at a bank that needed to make a regulatory system MiFID II compliant. The deadline was the end of 2017. The original plan was textbook waterfall: four teams, split by technical layers (UI, backend, database, services), each with a project manager, two business analysts, one developer, and one QA engineer. The plan called for six months of specification, three months of implementation, and three months of testing.\nIt was immediately clear to me that this would not work. After about two weeks, I proposed a simple experiment to the program leadership. We attempted a small vertical slice: implementing one small feature end-to-end with the existing teams and deploying it to a test environment. The result was a disaster. Nothing worked. But that experiment was exactly what triggered a change in thinking.\nThe Agile Shift: Domain-Driven Design and Honest Forecasts # We restructured the teams using Domain-Driven Design: identified domains and made the teams truly responsible end-to-end for their bounded context. Then we built a backlog, estimated epics, measured velocity, and created a burn-up chart.\nThe honest forecast was sobering: by November 2017, we could deliver exactly one third of the backlog. Two thirds were not feasible. Management naturally wanted to mandate weekend work and twelve-hour days. My answer: if we do that, we will probably deliver nothing at all. Instead, we consistently prioritized the backlog.\n\u0026ldquo;By the end of the year, we had the system MiFID-compliant and in production. The forecast turned out to be exactly right: we delivered the necessary third. And the other two thirds? They simply disappeared in January. They were wishful thinking.\u0026rdquo;\nThat was a defining experience. Two thirds of the original backlog turned out to be unnecessary. The prioritized third was fully sufficient to meet the regulatory requirements.\nScaling: Why SAFe Alone Is Not a Solution # We scaled from four teams to ten. We introduced Scrum of Scrums, supplemented by selected SAFe elements like mini PI plannings and sync meetings. Scrum of Scrums would have been enough on its own. But the bank adopted SAFe organization-wide, and we were declared an Agile Release Train.\nWhat we actually did: renamed the roles, reduced PI planning from the full two-day format to half a day, and in practice continued doing Scrum of Scrums. The decisive difference from other teams at the bank was that we kept the continuous improvement sprint.\nMany SAFe implementations fail because this innovation sprint is the first thing to be eliminated, since teams \u0026ldquo;need\u0026rdquo; to deliver features. This makes SAFe purely by the book, because you never improve. Our Agile Release Train was one of the showcase ARTs, while other teams complained that they could not get any work done because of all the synchronization meetings.\nMy clear recommendation: SAFe makes sense when you have more than 50 people working on a product with hard dependencies between teams. But if you can resolve those dependencies organizationally, process-wise, and architecturally, you do not need the framework at all. Then teams can work autonomously, and that is the real goal.\nBreaking Down Silos: IT and Business Merge # One of the most impactful experiences was the conflict between IT and business. The bank had a classic setup: IT silo and business silo. Our program manager sat in the business unit, while IT management insisted on the waterfall process. There were bets of several thousand Swiss francs that our project would fail.\nWhen we delivered successfully at the end of 2017, IT wanted to pull the team back and return to waterfall. Instead, the business unit took over the development team entirely. This shortened decision paths and increased efficiency significantly.\nThis experience solidified a conviction that I have since seen confirmed in many projects: in forward-thinking organizations, the separation between IT and business will disappear. There will only be cross-functional teams working on a product, built on a shared platform.\nFrom Value Streams to Organizational Change # Over the years, the bank introduced value streams. The first value streams were drawn along political lines and led to massive friction. But step by step, the organization learned. The real breakthrough came when value streams were given end-to-end responsibility, including budget and the principle of \u0026ldquo;you build it, you run it.\u0026rdquo;\nSuddenly, things were cleaned up: applications that nobody knew existed, applications with five users and enormous maintenance effort, duplicate capabilities. Entrepreneurial thinking entered the value streams, and efficiency increased dramatically.\nToday the bank is taking the next step and restructuring its organizational hierarchy as well: the Release Train Engineer becomes the manager of the developers, the Product Manager becomes the manager of the Product Owners. Process organization and reporting structure merge within the value stream.\nAI and Vibecoding: Why Clean Software Engineering Matters More Than Ever # In the conversation, we also discuss the role of AI and vibecoding. At Zuehlke, we use AI consistently. It augments our work but does not replace people. We have our own Cybernetic Delivery Method that describes how we develop software together with AI.\nWhat I learned from vibecoding: you have to specify precisely and write tests. For me as a DevOps thought leader, this is a dream come true, because AI forces us to practice clean software engineering. You need to describe clearly what you want, your tests need to be correct, and your software needs to be modularly architected so that the context stays small.\nAt the same time, we see in our monthly AI exchanges that many experienced software engineers use copilots for boilerplate code and tests but turn them off when it comes to truly new algorithms. AI is not a silver bullet. It cannot build an SAP system from scratch, and you need to proceed in small steps.\nKey Takeaways # Continuous improvement is the central pillar. Every day, ask what can be better tomorrow, and constantly work on the system. Without this pillar, every framework becomes bureaucracy.\nC-level support is essential. Without a clear mandate from the top, agile transformations get stuck at the level of individual teams. Big changes require big support.\nDependencies are the real enemy. It is not missing tooling or wrong frameworks that slow teams down, but organizational, process, and architectural dependencies. Resolve those, and you need less coordination.\nTransformation requires patience. Not every organization can or must change overnight. Small, continuous steps can be equally effective, as long as you stay committed.\nHonest forecasts prevent wishful thinking. Prioritization based on data (velocity, burn-up charts) creates transparency. It often turns out that a large portion of requirements is not actually needed.\nAI makes clean engineering more important, not obsolete. Vibecoding and AI-assisted development only work with clear specifications, good tests, and modular architecture.\n","date":"7 December 2025","externalUrl":null,"permalink":"/en/blogs/agility-in-action-mindset-processes-and-real-results/","section":"Blogs","summary":"How much agility can software development really handle, and where does agility tip into chaos? In this episode of the “Modern Work 2 Go” podcast (in German), I speak with Florian Schneider about exactly these questions. We dive deep into a concrete real-world example: an agile transformation at a Swiss bank that I accompanied over eight years. The conversation covers the shift from waterfall to agility, scaling with SAFe, building value streams, and why continuous improvement is the central pillar of every transformation.\n","title":"Agility in Action: Mindset, Processes, and Real Results","type":"blogs"},{"content":"Does AI really solve the problems we have? What does it mean for innovation and intellectual property? Will AI replace patent analysts? In this webinar with IamIP, I cut through the fog of AI hype and share a practical framework for understanding where AI genuinely adds value, and where it falls short.\nWe Are Trapped in a Hype # Let me be direct: we are trapped in an AI bubble. In 2025, investments into AI reached $1,000 billion. The revenue generated from AI in the same year? $120 billion. That gap is enormous, and the pattern is familiar. I saw exactly this in the year 2000 with the internet bubble. Every company needed a website and an online store, massive amounts of startups appeared, and then on March 10, 2000, the bubble burst.\nThe indicators today are equally clear. An MIT study on the state of business AI in 2025 found that enterprises spent roughly $30 to $40 billion on generative AI, yet 95% saw no profit and loss impact. Only 5% generated real value.\nWe are living in the era of the AI idiot, where ChatGPT cowboys, clueless politicians, and short-term hyped managers burn billions.\nPlease do not misunderstand: I think AI is absolutely awesome, and I use it every day as my personal assistant. But our job as leaders is to cut through the fog and see what truly matters.\nAI Has No Brain. Use Your Own. # There is widespread confusion about the word \u0026ldquo;intelligence\u0026rdquo; in artificial intelligence. AI is a system that gathers information, interprets it, and derives conclusions. It is not a system that simulates human thinking. It is a pattern matching engine that predicts the next word, the next pixel, or the next video frame based on statistical patterns in training data.\nIf you ask ChatGPT whether you can trust it, it tells you itself: it is a pattern matching engine that predicts the next word. No real understanding of the world, no self-motivation, no planning, no self-reflection. When you tell it a ball on a table gets kicked, it predicts \u0026ldquo;the ball is on the floor\u0026rdquo; not because it understands physics, but because statistically that is the most likely next sentence.\nCan You Build AI Systems You Can Trust? # Out of the box, ChatGPT gives roughly 50% accurate answers. With a RAG (Retrieval Augmented Generation) system using vector databases and your own documents, accuracy improves to 60-70%. To reach 95% accuracy, close to human expert level, you need a master agent with specialized sub-agents, each with their own RAG systems, databases, and extensive prompt engineering.\nWe built such a system at Zühlke with an insurance company. Their support staff needed help navigating complex contracts. The system boosted productivity massively, but it required significant engineering effort, extensive testing by human experts, and humans remain in the loop. You cannot just use AI out of the box; it requires engineering.\nProtecting Your Data # If you use a SaaS LLM service, your data goes to them. They may promise not to use it, but if you have genuine concerns about data security, the only option is to host your own LLMs on-premises or run them locally. Tools like LM Studio and Ollama make it possible to run local LLMs on your own machine. The trade-off: smaller context windows and reduced capabilities compared to cloud-hosted models.\nA Framework for AI in Your Organization # I developed a framework with two dimensions. On the horizontal axis: does the work stay the same (just powered by AI) or is the work itself transformed? On the vertical axis: do humans hand over the work to AI, or do humans and AI work together?\nThis creates four quadrants:\nAutomate and Orchestrate (work stays same, AI takes over): Today, AI automatically scans global patent databases, removes duplicates, and pre-classifies results. In the future, AI agents could handle filings, renewals, and compliance across jurisdictions, with humans focusing only on exceptions and critical approvals.\nAI-First (work transforms, AI takes over): Today, AI co-pilots support inventors with prior art searches and IP system updates. In the future, AI systems could automatically detect market trends, draft patents, and prioritize R\u0026amp;D projects with minimal human input.\nCo-Create on the Frontier (work transforms, humans + AI together): Today, IP experts use AI to draft patent claims and summarize prior art. In the future, AI co-pilots could use internal and global legal data to suggest arguments, predict counterparty responses, and simulate outcomes of legal cases.\nAugment and Scale (work stays same, humans + AI together): Today, AI helps with strategic decisions through simulation of technology trends and innovation opportunities. In the future, AI agents could continuously scan patent, research, and market trends, working alongside legal, R\u0026amp;D, and business teams to shape IP strategies.\nThe Human Advantage # AI has clear strengths: pattern recognition in large datasets, fast calculation, logic, and automation. Humans have different strengths: empathy, intuition, contextual understanding, cultural sensitivity, and the ability to recognize irony and linguistic nuance. A recent study found that current AI systems reflect the culture of western English-speaking societies, meaning cultural sensitivity is simply not present.\nGary Kasparov, who famously lost to a chess AI, put it perfectly:\n\u0026ldquo;The future is not man versus machine. It is man with machine versus man without.\u0026rdquo;\nOur job as leaders is to create environments where humans and AI work together, each contributing their strengths.\nKey Takeaways # We are in an AI bubble. Investments far exceed returns. Be strategic, not swept up in the hype. AI is a pattern matching engine, not a thinking machine. It has no brain. Use your own. Accuracy requires engineering. Out-of-the-box AI is roughly 50% accurate. Reaching expert-level accuracy (95%) takes specialized agents, RAG systems, and significant effort. Protect your data. If it must stay private, host your own models. SaaS means your data leaves your control. Use the four-quadrant framework to decide where AI adds value: automate, go AI-first, co-create, or augment. The future is humans with AI. Create environments where both work together, amplifying human creativity with machine intelligence. ","date":"7 December 2025","externalUrl":null,"permalink":"/en/blogs/beyond-the-ai-hype-innovation-ip-and-rd/","section":"Blogs","summary":"Does AI really solve the problems we have? What does it mean for innovation and intellectual property? Will AI replace patent analysts? In this webinar with IamIP, I cut through the fog of AI hype and share a practical framework for understanding where AI genuinely adds value, and where it falls short.\n","title":"Beyond the AI Hype: How to Use AI Safely for Innovation, IP and R\u0026D","type":"blogs"},{"content":"Löst KI wirklich die Probleme, die wir haben? Was bedeutet sie für Innovation und geistiges Eigentum? Wird KI Patentanalysten ersetzen? In diesem Webinar mit IamIP schneide ich durch den Nebel des KI-Hypes und teile ein praktisches Framework, um zu verstehen, wo KI tatsächlich Mehrwert schafft und wo sie an ihre Grenzen stösst.\nWir stecken in einem Hype # Lassen Sie mich direkt sein: Wir stecken in einer KI-Blase. Im Jahr 2025 erreichten die Investitionen in KI 1.000 Milliarden Dollar. Der im selben Jahr mit KI generierte Umsatz? 120 Milliarden Dollar. Diese Lücke ist enorm, und das Muster ist bekannt. Ich habe genau das im Jahr 2000 mit der Internet-Blase erlebt. Jedes Unternehmen brauchte eine Website und einen Online-Shop, massenhaft Startups entstanden, und dann, am 10. März 2000, platzte die Blase.\nDie Indikatoren sind heute genauso deutlich. Eine MIT-Studie zum Stand der Business-KI 2025 ergab, dass Unternehmen etwa 30 bis 40 Milliarden Dollar für generative KI ausgaben, wobei 95% keinen Einfluss auf Gewinn und Verlust sahen. Nur 5% erzielten echten Wert.\nWir leben in der Ära des KI-Idioten, in der ChatGPT-Cowboys, ahnungslose Politiker und kurzfristig gehypte Manager Milliarden verbrennen.\nBitte missverstehen Sie mich nicht: Ich finde KI absolut grossartig und nutze sie täglich als meinen persönlichen Assistenten. Aber unsere Aufgabe als Führungskräfte ist es, durch den Nebel zu schneiden und zu sehen, was wirklich zählt.\nKI hat kein Gehirn. Benutzen Sie Ihres. # Es gibt weit verbreitete Verwirrung um das Wort \u0026ldquo;Intelligenz\u0026rdquo; in Künstlicher Intelligenz. Besonders im deutschsprachigen Raum wird oft angenommen, es gehe um mentale Fähigkeiten und menschliches Denken. Tatsächlich ist KI ein System, das Informationen sammelt, interpretiert und Schlüsse daraus zieht. Es ist kein System, das menschliches Denken simuliert. Es ist eine Mustererkennungsmaschine, die das nächste Wort, das nächste Pixel oder das nächste Video-Frame basierend auf statistischen Mustern in Trainingsdaten vorhersagt.\nWenn Sie ChatGPT fragen, ob man ihm vertrauen kann, sagt es Ihnen selbst: Es ist eine Mustererkennungsmaschine, die das nächste Wort vorhersagt. Kein echtes Verständnis der Welt, keine Eigenmotivation, keine Planung, keine Selbstreflexion. Wenn man ihm sagt, ein Ball auf einem Tisch bekommt einen Tritt, sagt es \u0026ldquo;Der Ball ist auf dem Boden\u0026rdquo; voraus. Nicht weil es Physik versteht, sondern weil das statistisch der wahrscheinlichste nächste Satz ist.\nKann man KI-Systeme bauen, denen man vertrauen kann? # Direkt ab Werk liefert ChatGPT etwa 50% korrekte Antworten. Mit einem RAG-System (Retrieval Augmented Generation) unter Verwendung von Vektor-Datenbanken und eigenen Dokumenten verbessert sich die Genauigkeit auf 60 bis 70%. Um 95% Genauigkeit zu erreichen, nahe am menschlichen Expertenniveau, braucht man einen Master-Agenten mit spezialisierten Sub-Agenten, jeder mit eigenem RAG-System, eigenen Datenbanken und umfangreichem Prompt Engineering.\nWir haben ein solches System bei Zühlke mit einem Versicherungsunternehmen gebaut. Dessen Supportmitarbeitende brauchten Hilfe bei der Navigation durch komplexe Verträge. Das System steigerte die Produktivität massiv, erforderte aber erheblichen Engineering-Aufwand, umfangreiche Tests durch menschliche Experten, und Menschen bleiben im Prozess eingebunden. Man kann KI nicht einfach fertig aus der Schachtel verwenden; es braucht Engineering.\nIhre Daten schützen # Wenn Sie einen SaaS-LLM-Service nutzen, gehen Ihre Daten zu diesem Anbieter. Der Anbieter kann versprechen, sie nicht zu nutzen, aber wenn Sie echte Bedenken bezüglich Datensicherheit haben, ist die einzige Option, eigene LLMs on-premises zu hosten oder lokal laufen zu lassen. Tools wie LM Studio und Ollama ermöglichen es, lokale LLMs auf dem eigenen Rechner zu betreiben. Der Kompromiss: kleinere Kontextfenster und reduzierte Fähigkeiten im Vergleich zu Cloud-gehosteten Modellen.\nEin Framework für KI in Ihrem Unternehmen # Ich habe ein Framework mit zwei Dimensionen entwickelt. Auf der horizontalen Achse: Bleibt die Arbeit gleich (nur KI-unterstützt) oder wird die Arbeit selbst transformiert? Auf der vertikalen Achse: Übergeben Menschen die Arbeit an KI, oder arbeiten Menschen und KI zusammen?\nDas ergibt vier Quadranten:\nAutomatisieren und Orchestrieren (Arbeit bleibt gleich, KI übernimmt): Heute scannt KI automatisch globale Patentdatenbanken, entfernt Duplikate und klassifiziert Ergebnisse vor. In Zukunft könnten KI-Agenten Anmeldungen, Verlängerungen und Compliance über Jurisdiktionen hinweg übernehmen, wobei Menschen sich nur auf Ausnahmen und kritische Genehmigungen konzentrieren.\nKI-First (Arbeit transformiert sich, KI übernimmt): Heute unterstützen KI-Copiloten Erfinder bei Recherchen zum Stand der Technik und IP-System-Updates. In Zukunft könnten KI-Systeme automatisch Markttrends erkennen, Patententwürfe erstellen und F\u0026amp;E-Projekte mit minimalem menschlichem Eingriff priorisieren.\nCo-Create an der Grenze (Arbeit transformiert sich, Menschen + KI zusammen): Heute nutzen IP-Experten KI zum Erstellen von Patentansprüchen und zum Zusammenfassen von Recherchen zum Stand der Technik. In Zukunft könnten KI-Copiloten interne und globale juristische Daten nutzen, um Argumente vorzuschlagen, Gegenreaktionen vorherzusagen und mögliche Ergebnisse von Rechtsstreitigkeiten zu simulieren.\nAugmentieren und Skalieren (Arbeit bleibt gleich, Menschen + KI zusammen): Heute hilft KI bei strategischen Entscheidungen durch Simulation von Technologietrends und Innovationsmöglichkeiten. In Zukunft könnten KI-Agenten kontinuierlich Patent-, Forschungs- und Markttrends scannen und mit Rechts-, F\u0026amp;E- und Geschäftsteams zusammenarbeiten, um neue IP-Strategien zu entwickeln.\nDer menschliche Vorteil # KI hat klare Stärken: Mustererkennung in grossen Datensätzen, schnelle Berechnungen, Logik und Automatisierung. Menschen haben andere Stärken: Empathie, Intuition, Kontextverständnis, kulturelle Sensibilität und die Fähigkeit, Ironie und sprachliche Nuancen zu erkennen. Eine aktuelle Studie ergab, dass heutige KI-Systeme die Kultur westlicher, englischsprachiger Gesellschaften widerspiegeln. Kulturelle Sensibilität ist schlicht nicht vorhanden.\nGary Kasparov, der berühmterweise einmal gegen eine KI verlor, formulierte es treffend:\n\u0026ldquo;Die Zukunft ist nicht Mensch gegen Maschine. Es ist Mensch mit Maschine gegen Mensch ohne.\u0026rdquo;\nUnsere Aufgabe als Führungskräfte ist es, Umgebungen zu schaffen, in denen Menschen und KI zusammenarbeiten und jeder seine Stärken einbringt.\nKernaussagen # Wir stecken in einer KI-Blase. Investitionen übersteigen die Erträge bei weitem. Strategisch handeln, sich nicht vom Hype mitreissen lassen. KI ist eine Mustererkennungsmaschine, keine denkende Maschine. Sie hat kein Gehirn. Benutzen Sie Ihres. Genauigkeit erfordert Engineering. KI ab Werk ist zu etwa 50% genau. Expertenniveau (95%) zu erreichen, erfordert spezialisierte Agenten, RAG-Systeme und erheblichen Aufwand. Schützen Sie Ihre Daten. Wenn sie privat bleiben müssen, hosten Sie eigene Modelle. SaaS bedeutet: Ihre Daten verlassen Ihre Kontrolle. Nutzen Sie das Vier-Quadranten-Framework, um zu entscheiden, wo KI Mehrwert schafft: automatisieren, KI-first, co-kreieren oder augmentieren. Die Zukunft ist Mensch mit KI. Schaffen Sie Umgebungen, in denen beide zusammenarbeiten und menschliche Kreativität durch maschinelle Intelligenz verstärkt wird. ","date":"7. December 2025","externalUrl":null,"permalink":"/de/blogs/jenseits-des-ki-hypes-innovation-ip-und-forschung/","section":"Blogs","summary":"Löst KI wirklich die Probleme, die wir haben? Was bedeutet sie für Innovation und geistiges Eigentum? Wird KI Patentanalysten ersetzen? In diesem Webinar mit IamIP schneide ich durch den Nebel des KI-Hypes und teile ein praktisches Framework, um zu verstehen, wo KI tatsächlich Mehrwert schafft und wo sie an ihre Grenzen stösst.\n","title":"Jenseits des KI-Hypes: KI sicher nutzen für Innovation, IP und F\u0026E","type":"blogs"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/safe/","section":"Tags","summary":"","title":"SAFe","type":"tags"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/scrum/","section":"Tags","summary":"","title":"Scrum","type":"tags"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/thought-leadership/","section":"Tags","summary":"","title":"Thought Leadership","type":"tags"},{"content":"","date":"7 December 2025","externalUrl":null,"permalink":"/en/tags/value-stream-organization/","section":"Tags","summary":"","title":"Value Stream Organization","type":"tags"},{"content":"","date":"7. December 2025","externalUrl":null,"permalink":"/de/tags/wertstromorganisation/","section":"Tags","summary":"","title":"Wertstromorganisation","type":"tags"},{"content":"Das Werk „The Cybernetic Enterprise: How to Build a Future-Ready Organization“ ist Ihr umfassendes Betriebssystem für die Navigation durch die nächste Ära der Unternehmenstransformation.\nWillkommen zum Leanpub-Launch-Video für den Kurs „The Cybernetic Enterprise: How to Build a Future-Ready Organization“ von Romano Roth.\nÜber den Kurs # Das „Cybernetic Enterprise: How to Build a Future-Ready Organization“ ist Ihr umfassendes Betriebssystem für die nächste Ära der Unternehmenstransformation. Wenn Ihr Unternehmen Agile und DevOps eingeführt hat, aber weiterhin Schwierigkeiten hat, sich im großen Maßstab anzupassen, schnelle Teams, aber langsame Unternehmensstrukturen, ist dieser Kurs genau das Richtige für Sie.\nDies ist kein weiteres, isoliertes Handbuch für Agile, DevOps oder KI. Vielmehr stellt es ein einheitliches, kybernetisches Betriebsmodell vor, das auf kontinuierliches Lernen, KI-gestützte Intelligenz und schnelle Feedbackschleifen über Strategie, Produkt, Technologie und Betrieb hinweg ausgelegt ist. Sie lernen, im Unternehmensmaßstab zu erkennen, zu lernen und sich anzupassen.\nDer Kurs umfasst fast drei Stunden exklusives Videomaterial, in dem der Autor Themen bespricht, die für jede Lektion des Kurses relevant sind.\nDer Kurs bietet ein mehrstufiges Rahmenwerk mit Prinzipien, Praktiken, einer Plattform und messbaren Ergebnissen, das Sie beim Aufbau eines Unternehmens unterstützt, das auf Wandel ausgerichtet ist und nicht nur mit ihm zurechtkommt. Ob Sie CTO, CIO, Enterprise-Architekt, Transformationscoach oder Teamleiter sind, dieser Kurs bietet Ihnen die Modelle und Werkzeuge, um Silos aufzubrechen, die Umsetzung mit der Strategie in Einklang zu bringen und KI verantwortungsvoll zu integrieren.\nMit Vorworten von Prof. Dr. Oliver Gilbert und Prof. Markus Dobbelfeld schlägt dieser Kurs eine Brücke zwischen akademischen Erkenntnissen und Branchenerfahrung und verknüpft Visionen mit deren Umsetzung in den Bereichen Führung, Technologie und Organisationsgestaltung.\nWarum es anders ist # Die meisten Transformationsbemühungen integrieren neue Werkzeuge in veraltete Strukturen. Das Cybernetische Unternehmen hingegen baut die Struktur selbst neu auf. Es unterstützt Sie bei der Gestaltung einer feedbackorientierten, KI-gestützten Organisation, in der Lernen sich gegenseitig verstärkt und Wandel zum Wettbewerbsvorteil wird.\nFür wen es gedacht ist # Führungskräfte bringen Strategie, Investitionen und Ergebnisse in Einklang Architekten und Ingenieure, die KI durch plattformorientiertes Denken verantwortungsvoll skalieren. Produktmanager, Designer, Coaches und Veränderungsmanager, die nach Kohärenz über verschiedene Initiativen hinweg streben. Was Sie tun können werden # Integrieren Sie Feedbackschleifen in jede Ebene Ihrer Organisation.\nInvestitionen an ergebnisorientierten Kennzahlen ausrichten\nBeschleunigung der KI-Einführung durch Plattformentwicklung\nAutonome, langlebige Produktteams gestalten * Leichte, prinzipienorientierte Unternehmensführung schaffen, die Experimente fördert\nTransformationsbemühungen mithilfe strukturierter Diagnostik bewerten und steuern\nBonusmaterial # Der Kurs beinhaltet außerdem einen kostenlosen Gutschein für die Komplettausgabe von „The Cybernetic Enterprise“, ein Paket, das die folgenden vier Bücher umfasst:\nDas kybernetische Unternehmen (das Buch, auf dem dieser Kurs basiert) Das CTO-Handbuch für kybernetische Unternehmen Die Bewertung des kybernetischen Unternehmens Grundlagen des kybernetischen Unternehmens Gestalte das Unternehmen, in dem du arbeiten möchtest. Forme das System, das du führen möchtest. Werde die Organisation, die die Zukunft braucht. Deine Reise in die digitale Welt beginnt jetzt.\n","date":"4. December 2025","externalUrl":null,"permalink":"/de/blogs/leanpub-kursstart-der-kurs-das-kybernetische-unternehmen-wie-man-eine-zukunftsfaehige-organisation/","section":"Blogs","summary":"Das Werk „The Cybernetic Enterprise: How to Build a Future-Ready Organization“ ist Ihr umfassendes Betriebssystem für die Navigation durch die nächste Ära der Unternehmenstransformation.\nWillkommen zum Leanpub-Launch-Video für den Kurs „The Cybernetic Enterprise: How to Build a Future-Ready Organization“ von Romano Roth.\n","title":"Leanpub-Kursstart: Der Kurs „Das kybernetische Unternehmen: Wie man eine zukunftsfähige Organisation aufbaut“ ","type":"blogs"},{"content":"The Cybernetic Enterprise: How to Build a Future-Ready Organization is your comprehensive operating system for navigating the next era of business transformation.\nWelcome to the Leanpub Launch video for The Cybernetic Enterprise Course: How to Build a Future-Ready Organization by Romano Roth\nAbout the Course # The Cybernetic Enterprise: How to Build a Future-Ready Organization is your comprehensive operating system for navigating the next era of business transformation. If your company has adopted Agile and DevOps but still struggles to adapt at scale, fast teams, slow enterprise, this course is for you.\nThis is not another Agile, DevOps, or AI playbook in isolation. Instead, it introduces a unified cybernetic operating model, one designed for continuous learning, AI-augmented intelligence, and fast feedback loops across strategy, product, technology, and operations. You\u0026rsquo;ll learn to sense, learn, and adapt at enterprise scale.\nThe course includes nearly three hours of exclusive videos with the author discussing topics relevant to every lesson in the course.\nThe course offers a layered framework, principles, practices, platform, outcomes, that guides you in building an enterprise designed for change, not just coping with it. Whether you are a CTO, CIO, enterprise architect, transformation coach, or team leader, this course offers the models and tools to break silos, align execution with strategy, and embed AI responsibly.\nWith forewords by Prof. Dr. Oliver Gilbert and Prof. Markus Dobbelfeld, this course bridges academic insight and industry experience, linking vision with execution across leadership, technology, and organizational design.\nWhy It’s Different # Most transformation efforts bolt new tools onto outdated structures. The Cybernetic Enterprise rebuilds the structure itself. It helps you design a feedback-driven, AI-augmented organization where learning compounds and change becomes a competitive advantage.\nWho It’s For # Executives aligning strategy, investment, and outcomes Architects and engineers scaling AI responsibly through platform thinking Product managers, designers, coaches, and change agents seeking coherence across initiatives What You’ll Be Able to Do # Build feedback loops into every layer of your organization\nAlign investment with outcome-based metrics\nAccelerate AI adoption through platform engineering\nDesign autonomous, durable product teams* Create lightweight, principled governance that fosters experimentation\nAssess and steer transformation efforts with structured diagnostics\nBonus Material # The course also includes a free coupon for The Cybernetic Enterprise Complete Edition, a bundle that includes the following four books:\nThe Cybernetic Enterprise (the book which this course is based on) The Cybernetic Enterprise CTO Playbook The Cybernetic Enterprise Assessment Foundations of The Cybernetic Enterprise Build the enterprise you want to work in. Shape the system you want to lead. Become the organization the future demands. Your cybernetic journey starts now.\n","date":"4 December 2025","externalUrl":null,"permalink":"/en/blogs/leanpub-course-launch-the-cybernetic-enterprise-course-how-to-build-a-future-ready-organization-co/","section":"Blogs","summary":"The Cybernetic Enterprise: How to Build a Future-Ready Organization is your comprehensive operating system for navigating the next era of business transformation.\nWelcome to the Leanpub Launch video for The Cybernetic Enterprise Course: How to Build a Future-Ready Organization by Romano Roth\n","title":"Leanpub Course LAUNCH: The Cybernetic Enterprise Course: How to Build a Future-Ready Organization Course by Ro","type":"blogs"},{"content":"The Cybernetic Enterprise: How to Build a Future-Ready Organization ist Ihr umfassendes Betriebssystem, um die nächste Ära der Unternehmenstransformation zu meistern.\nWillkommen zum Leanpub-Launch-Video für The Cybernetic Enterprise Course: How to Build a Future-Ready Organization von Romano Roth.\nÜber den Kurs # The Cybernetic Enterprise: How to Build a Future-Ready Organization ist Ihr umfassendes Betriebssystem, um die nächste Ära der Unternehmenstransformation zu meistern. Wenn Ihr Unternehmen Agile und DevOps eingeführt hat, aber immer noch Schwierigkeiten hat, im großen Maßstab zu agieren (schnelle Teams, langsames Unternehmen), dann ist dieser Kurs genau richtig für Sie.\nDies ist kein weiteres isoliertes Agile-, DevOps- oder KI-Handbuch. Stattdessen führt er ein vereinheitlichtes kybernetisches Betriebsmodell ein, das für kontinuierliches Lernen, KI-gestützte Intelligenz und schnelle Feedback-Schleifen über Strategie, Produkt, Technologie und Betrieb hinweg konzipiert ist. Sie lernen, im Unternehmensmaßstab zu erfassen, zu lernen und sich anzupassen.\nDer Kurs beinhaltet fast drei Stunden exklusive Videos, in denen der Autor Themen bespricht, die für jede Lektion im Kurs relevant sind.\nDer Kurs bietet ein mehrschichtiges Framework (Prinzipien, Praktiken, Plattform, Ergebnisse), das Sie beim Aufbau eines Unternehmens anleitet, das für Veränderung konzipiert ist und nicht nur damit zurechtkommt. Ob Sie CTO, CIO, Enterprise Architect, Transformationscoach oder Teamleiter sind: Dieser Kurs bietet die Modelle und Werkzeuge, um Silos aufzubrechen, die Umsetzung an der Strategie auszurichten und KI verantwortungsvoll einzubetten.\nMit Vorworten von Prof. Dr. Oliver Gilbert und Prof. Markus Dobbelfeld verbindet dieser Kurs akademische Erkenntnisse mit Branchenerfahrung und verknüpft Vision mit Umsetzung über Führung, Technologie und Organisationsdesign hinweg.\nWarum er anders ist # Die meisten Transformationsvorhaben schrauben neue Tools auf veraltete Strukturen. The Cybernetic Enterprise baut die Struktur selbst neu auf. Es hilft Ihnen, eine feedback-gesteuerte, KI-gestützte Organisation zu gestalten, in der sich Lernen potenziert und Veränderung zum Wettbewerbsvorteil wird.\nFür wen der Kurs gedacht ist # Führungskräfte, die Strategie, Investitionen und Ergebnisse aufeinander abstimmen Architekten und Engineers, die KI durch Plattformdenken verantwortungsvoll skalieren Produktmanager, Designer, Coaches und Change Agents, die Kohärenz über Initiativen hinweg suchen Was Sie danach können werden # Feedback-Schleifen in jede Ebene Ihrer Organisation einbauen\nInvestitionen an ergebnisbasierten Metriken ausrichten\nKI-Einführung durch Platform Engineering beschleunigen\nAutonome, langlebige Produktteams gestalten\nLeichtgewichtige, prinzipienbasierte Governance schaffen, die Experimentieren fördert\nTransformationsvorhaben mit strukturierter Diagnostik bewerten und steuern\nBonusmaterial # Der Kurs beinhaltet außerdem einen kostenlosen Gutschein für die Cybernetic Enterprise Complete Edition, ein Bundle, das die folgenden vier Bücher umfasst:\nThe Cybernetic Enterprise (das Buch, auf dem dieser Kurs basiert) The Cybernetic Enterprise CTO Playbook The Cybernetic Enterprise Assessment Foundations of The Cybernetic Enterprise Bauen Sie das Unternehmen auf, in dem Sie arbeiten möchten. Gestalten Sie das System, das Sie führen möchten. Werden Sie die Organisation, die die Zukunft verlangt. Ihre kybernetische Reise beginnt jetzt.\n","date":"4. December 2025","externalUrl":null,"permalink":"/de/blogs/leanpub-kurs-launch-der-cybernetic-enterprise-kurs-wie-man-eine-zukunftsfaehige-organisation-aufbaut/","section":"Blogs","summary":"The Cybernetic Enterprise: How to Build a Future-Ready Organization ist Ihr umfassendes Betriebssystem, um die nächste Ära der Unternehmenstransformation zu meistern.\nWillkommen zum Leanpub-Launch-Video für The Cybernetic Enterprise Course: How to Build a Future-Ready Organization von Romano Roth.\n","title":"Leanpub Kurs Launch: Der Cybernetic Enterprise Kurs: Wie man eine zukunftsfähige Organisation aufbaut","type":"blogs"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/ai-ready/","section":"Tags","summary":"","title":"AI-Ready","type":"tags"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/data-driven/","section":"Tags","summary":"","title":"Data-Driven","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/datengetrieben/","section":"Tags","summary":"","title":"Datengetrieben","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/fertigung/","section":"Tags","summary":"","title":"Fertigung","type":"tags"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/future-proof/","section":"Tags","summary":"","title":"Future-Proof","type":"tags"},{"content":"When people, machines, and algorithms work as a \u0026ldquo;team,\u0026rdquo; more than automation emerges: a learning and resilient factory. But how can industrial companies make the leap into the AI era without losing their human element?\nIn times of increasing pressure for efficiency, costs, and differentiation, heightened geopolitical tensions, supply chain risks, and sustainability requirements, and where resources and skilled workers are becoming scarcer, industrial companies must become \u0026ldquo;AI ready.\u0026rdquo; And fast.\nCase studies already show that AI- supported factories achieve up to 20 percent higher OEE (Overall Equipment Effectiveness) values than traditional factories. Analyzing data in real time, proactively managing maintenance cycles, and networking supply chains: this reduces costs and increases resilience. By investing in AI early on, companies gain measurable competitive advantages and actively shape their future viability.\nThe focus is shifting from pure automation to true autonomy: self-learning, self-regulating systems under human supervision. The path to this is not a leap, but an evolution.\nMaturity levels measure how companies can gradually raise the interaction between humans and machines to a new level, from context-based optimization recommendations from AI (assistance) to joint problem-solving (co-creation) or orchestration and prioritization tasks (moderation) to AI systems that regulate or “heal” themselves (high autonomy), with humans as supervisors.\nHow to build an AI-supported organization # Technological complexity, a lack of skills among employees, regulatory hurdles, and cultural reservations are hindering many pilot projects. Without a robust data architecture and a reliable MLOPS framework (Machine Learning Operations), AI models remain isolated solutions. Furthermore, the transition from siloed, hierarchical organizations to agile, cross-functional teams requires significant leadership and active change management.\nImplementing AI is obviously not a plug-and-play project. It requires a holistic approach that considers both people and technology together. Four dimensions prove to be particularly critical to success on the path to the \u0026ldquo;cybernetic enterprise\u0026rdquo;:\nData-driven production: When sensors continuously supply the necessary \u0026ldquo;raw material,\u0026rdquo; edge AI can process the data directly at the machine, without detours via the cloud. This saves time, increases reaction speed, and minimizes downtime. Platform-based architecture: Open interfaces and digital twins enable the in-depth networking of development, production, and service processes. A scalable platform forms the basis for the fast, secure, flexible, and interconnected use of AI applications. Learning systems: An organization is constantly in motion, like a living system. Feedback loops are essential for this. They form the core of continuous development and optimization. Humans as conductors: Collaborative robots (cobots) take over monotonous tasks. Humans orchestrate the value creation, supported by Explainable AI, which makes the decisions, predictions, or recommendations of an AI system comprehensible to humans, thus creating transparency and trust. Why \u0026ldquo;cybernetic,\u0026rdquo; exactly? For the past 15 to 20 years, digital transformation has been the dominant term. But in the age of AI, that falls short, both in terms of content and concept. The term cybernetics derives from the Greek word for \u0026ldquo;helmsman\u0026rdquo; and refers to control principles in complex systems, where feedback and circular processes play a central role here. This makes it ideally suited to describing models for collaboration between humans and AI.\n“Cybernetic Transformation”: Step by step # To successfully navigate the transformation to a \u0026ldquo;cybernetic enterprise,\u0026rdquo; a solid transformation path is essential. A proven roadmap helps companies avoid or overcome obstacles:\nPrioritize vision and use cases: A clear target image is essential. Furthermore, realistic use cases that offer both quick wins and long-term potential make getting started tangible, from condition monitoring to autonomous intralogistics. Define your data strategy: Who is responsible for which data? How is governance organized? What security standards apply? A data strategy must answer these key questions. Establish platform engineering: It is recommended to build central platform teams that automatically deploy Devsecops pipelines (development, security, operations), self-service APIs, and standardized infrastructure components (microservices). These teams are key enablers for independent, fast, and secure work with AI products. Empowering the workforce: Further training is essential. Whether it\u0026rsquo;s upskilling, a citizen data scientist program, or AI ethics training, employees must be able to work with the technology \u0026ldquo;as a team.\u0026rdquo; Because this is about nothing less than a paradigm shift. Ensuring scalability and operation: AI systems need clear processes for edge deployment, model lifecycle management, and compliance checks to keep things running smoothly. Or perhaps \u0026ldquo;Industry 5.0\u0026rdquo;? # After using the term Industry 4.0 for so many years, it\u0026rsquo;s tempting to simply declare it a new release. But beware: the term can lead to Industry 4.0 being considered complete, even though many of its technological foundations, such as robotics, IoT (Internet of Things), and AI, are only now experiencing their productive breakthrough.\nWhat\u0026rsquo;s new is the even stronger focus on people, resilience, and sustainability. This is how the EU Commission defined this industrial phase several years ago. However, as long as \u0026ldquo;5.0\u0026rdquo; remains more of a buzzword and narrative than a reliable level of maturity, companies should critically examine the label, align themselves with the principles of the \u0026ldquo;cybernetic enterprise,\u0026rdquo; and pragmatically focus on concrete business results.\nMan and machine: competitive advantage and unbeatable team # In the organization of the future, there is no longer a separation between human intelligence and machine precision. A new operating system for value creation is emerging: collaborative, adaptive, resilient.\nThose who have the courage to put people first and orchestrate AI responsibly are not only redesigning processes, but also the culture of collaboration. The path to the \u0026ldquo;cybernetic enterprise\u0026rdquo; is not a trend, but an evolutionary step. And it begins now.\nOriginal article: https://www.industry-of-things.de/mensch-maschine-algorithmen-team-industrie-ki-ae-a-1d27fef006e523ef55d1dfb53538b4ac/\n","date":"23 November 2025","externalUrl":null,"permalink":"/en/blogs/how-industrial-companies-can-become-ai-ready-and-future-proof/","section":"Blogs","summary":"When people, machines, and algorithms work as a “team,” more than automation emerges: a learning and resilient factory. But how can industrial companies make the leap into the AI era without losing their human element?\n","title":"How industrial companies can become “AI-ready” and future-proof","type":"blogs"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/industrial-ai/","section":"Tags","summary":"","title":"Industrial AI","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/industrielle-ki/","section":"Tags","summary":"","title":"Industrielle KI","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/ki-ready/","section":"Tags","summary":"","title":"KI-Ready","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/kybernetische-transformation/","section":"Tags","summary":"","title":"Kybernetische Transformation","type":"tags"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/manufacturing/","section":"Tags","summary":"","title":"Manufacturing","type":"tags"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/strategie/","section":"Tags","summary":"","title":"Strategie","type":"tags"},{"content":"","date":"23 November 2025","externalUrl":null,"permalink":"/en/tags/strategy/","section":"Tags","summary":"","title":"Strategy","type":"tags"},{"content":"Wenn Menschen, Maschinen und Algorithmen als „Team\u0026quot; arbeiten, entsteht mehr als Automatisierung, eine lernende und resiliente Fabrik. Doch wie gelingt Industrieunternehmen der Sprung in die KI-Ära, ohne den Menschen zu verlieren?\nIn Zeiten, in denen der Effizienz-, Kosten- und Differenzierungsdruck steigt, geopolitische Spannungen, Lieferkettenrisiken und Nachhaltigkeitsanforderungen zunehmen und Ressourcen genauso wie Fachkräfte knapper werden, müssen sich Industrieunternehmen „AI ready\u0026quot; machen. Und zwar schnell.\nBereits heute zeigen Fallbeispiele, dass KI gestützte Werke bis zu 20 Prozent höhere OEE-Werte (Overall Equipment Effectiveness) erreichen als klassische Fabriken. Daten in Echtzeit analysieren, Wartungszyklen proaktiv steuern und Lieferketten vernetzen: Das senkt Kosten und erhöht die Resilienz. Mit frühzeitigen KI Investitionen erzielen Unternehmen also messbare Wettbewerbsvorteile und gestalten aktiv ihre Zukunftsfähigkeit.\nDer Fokus verlagert sich von reiner Automatisierung hin zu echter Autonomie, selbstlernende, selbststeuernde Systeme unter menschlicher Aufsicht. Der Weg dahin ist kein Sprung, sondern eine Entwicklung.\nIn Reifegraden lässt sich messen, wie Unternehmen die Interaktion zwischen Mensch und Maschine Schritt für Schritt auf ein neues Level heben können: von kontextbasierten Optimierungsempfehlungen der KI (Assistenz) über gemeinsame Lösungsfindung (Ko-Kreation) oder Orchestrierungs- und Priorisierungsaufgaben (Moderation) bis hin zu KI-Systemen, die sich selbst regulieren oder „heilen\u0026quot; (Hochautonomie), mit dem Menschen als Supervisor.\nSo gelingt der Aufbau einer KI-gestützten Organisation # Technologische Komplexität, fehlende Skills bei den Mitarbeitenden, regulatorische Hürden und kulturelle Vorbehalte bremsen viele Pilotprojekte aus. Ohne robuste Datenarchitektur und verlässliches MLOps Framework (Machine Learning Operations) bleiben KI Modelle Einzellösungen. Zudem erfordert der Übergang von der silobasierten Linienorganisation zu agilen, funktionsübergreifenden Teams viel Führungsarbeit und aktives Change Management.\nDie Implementierung von KI ist selbstredend kein Plug-and-Play-Projekt. Es braucht einen ganzheitlichen Ansatz, der Mensch und Technologie zusammen denkt. Vier Dimensionen erweisen sich auf dem Weg zum „Cybernetic Enterprise\u0026quot; als besonders erfolgskritisch:\nDatengetriebene Produktion: Wenn die Sensorik kontinuierlich den notwendigen „Rohstoff\u0026quot; liefert, kann Edge-KI die Daten direkt an der Maschine verarbeiten, ohne Umwege über die Cloud. Das spart Zeit, erhöht die Reaktionsgeschwindigkeit und minimiert Ausfallzeiten.\nPlattformbasierte Architektur: Offene Schnittstellen und digitale Zwillinge ermöglichen die tiefgreifende Vernetzung von Entwicklungs-, Produktions- und Serviceprozessen. Eine skalierbare Plattform bildet die Basis für eine schnelle, sichere, flexible und anschlussfähige Nutzung von KI-Anwendungen.\nLernende Systeme: Eine Organisation ist ständig in Bewegung, wie ein lebendiges System. Dafür sind Feedback-Loops essentiell. Sie bilden das Herzstück kontinuierlicher Weiterentwicklung und Optimierung.\nDer Mensch als Dirigent: Kollaborative Roboter (Cobots) übernehmen monotone Aufgaben. Menschen orchestrieren die Wertschöpfung, unterstützt durch Explainable AI, die Entscheidungen, Vorhersagen oder Empfehlungen eines KI-Systems für Menschen nachvollziehbar macht und damit Transparenz und Vertrauen schafft.\nWarum eigentlich „cybernetic\u0026quot;? In den letzten 15 bis 20 Jahren war die digitale Transformation das Maß der Dinge. Doch im KI-Zeitalter greift das kurz, inhaltlich wie begrifflich. Der Kybernetik-Begriff leitet sich vom griechischen Wort für „Steuermann\u0026quot; ab und bezeichnet Regelungsprinzipien in komplexen Systemen, wobei Rückkopplung und zirkuläre Prozesse spielen hier eine zentrale Rolle. Damit eignet er sich hervorragend, um Modelle für die Zusammenarbeit zwischen Mensch und KI zu beschreiben.\n„Cybernetic Transformation\u0026quot;: Schritt für Schritt # Um den Wandel zum „Cybernetic Enterprise\u0026quot; zu gestalten, braucht es einen trittfesten Transformationspfad. Ein erprobter Fahrplan hilft Unternehmen dabei, Stolpersteine zu umgehen oder zu beseitigen:\nVision und Use Cases priorisieren: Ein klares Zielbild ist unerlässlich. Zudem machen realistische Anwendungsfälle, die sowohl Quick Wins als auch langfristiges Potenzial bieten, den Einstieg greifbar, vom Condition Monitoring bis zur autonomen Intralogistik.\nDatenstrategie definieren: Wer verantwortet welche Daten? Wie wird Governance organisiert? Welche Sicherheitsstandards gelten? Eine Datenstrategie muss diese zentralen Fragen klären.\nPlatform Engineering etablieren: Es empfiehlt sich, zentrale Plattformteams aufzubauen, die DevSecOps-Pipelines (Development, Security, Operations), Self-Service-APIs und standardisierte Infrastruktur-Komponenten (Microservices) automatisiert bereitstellen. Sie sind zentrale Enabler für das eigenständige, schnelle und sichere Arbeiten mit KI-Produkten.\nBelegschaft befähigen: Weiterbildung ist Pflicht. Ob Upskilling, Citizen Data Scientist-Programm oder KI-Ethik-Training, Mitarbeitende müssen dazu in der Lage sein, mit der Technologie „im Team\u0026quot; zu arbeiten. Denn hier geht es um nicht mehr und nicht weniger als einen Paradigmenwechsel.\nSkalierung und Betrieb sichern: KI-Systeme brauchen klare Prozesse für Edge-Deployment, Model Lifecycle Management und Compliance-Checks, damit der Laden läuft.\nOder doch lieber „Industrie 5.0\u0026quot;? # Nachdem wir über so viele Jahre mit dem Begriff Industrie 4.0 operiert haben, wirkt es verführerisch, hier einfach das neue Release auszurufen. Doch Vorsicht: Der Begriff verleitet dazu, Industrie 4.0 für abgeschlossen zu erklären, obwohl viele ihrer technologischen Grundlagen wie Robotik, IoT (Internet of Things) und KI erst jetzt ihren produktiven Durchbruch erleben.\nNeu ist die noch stärkere Fokussierung auf den Menschen, auf Resilienz und Nachhaltigkeit, so hat die EU-Kommission diese industrielle Phase bereits vor einigen Jahren definiert. Doch solange „5.0\u0026quot; eher Buzzword und Narrativ als belastbarer Reifegrad ist, sollten Unternehmen das Etikett kritisch prüfen, sich an den Prinzipien der „Cybernetic Enterprise\u0026quot; orientieren und pragmatisch auf konkrete Geschäftsergebnisse konzentrieren.\nMensch und Maschine: Wettbewerbsvorteil und unschlagbares Team # In der Organisation der Zukunft gibt es keine Trennung mehr zwischen menschlicher Intelligenz und maschineller Präzision. Es entsteht ein neues Betriebssystem für Wertschöpfung: kollaborativ, lernfähig, resilient.\nWer den Mut hat, den Menschen in den Mittelpunkt zu stellen und KI verantwortungsvoll zu orchestrieren, gestaltet nicht nur Prozesse neu, sondern auch die Kultur des Miteinanders. Der Weg zum „Cybernetic Enterprise\u0026quot; ist kein Trend, sondern ein Evolutionsschritt. Und er beginnt jetzt.\nOriginal Artikel: https://www.industry-of-things.de/mensch-maschine-algorithmen-team-industrie-ki-ae-a-1d27fef006e523ef55d1dfb53538b4ac/\n","date":"23. November 2025","externalUrl":null,"permalink":"/de/blogs/wie-industrieunternehmen-ki-ready-werden/","section":"Blogs","summary":"Wenn Menschen, Maschinen und Algorithmen als „Team\" arbeiten, entsteht mehr als Automatisierung, eine lernende und resiliente Fabrik. Doch wie gelingt Industrieunternehmen der Sprung in die KI-Ära, ohne den Menschen zu verlieren?\n","title":"Wie sich Industrieunternehmen «AI-ready» und zukunftsfit machen","type":"blogs"},{"content":"","date":"23. November 2025","externalUrl":null,"permalink":"/de/tags/zukunftsf%C3%A4higkeit/","section":"Tags","summary":"","title":"Zukunftsfähigkeit","type":"tags"},{"content":" Wenn Menschen, Maschinen und Algorithmen als „Team“ arbeiten, entsteht mehr als Automatisierung, eine lernende und resiliente Fabrik. Doch wie gelingt Industrieunternehmen der Sprung in die KI-Ära, ohne den Menschen zu verlieren?\nIn Zeiten, in denen der Effizienz-, Kosten- und Differenzierungsdruck steigt, geopolitische Spannungen, Lieferkettenrisiken und Nachhaltigkeitsanforderungen zunehmen und Ressourcen genauso wie Fachkräfte knapper werden, müssen sich Industrieunternehmen „AI ready“ machen. Und zwar schnell.\nBereits heute zeigen Fallbeispiele, dass KI gestützte Werke bis zu 20 Prozent höhere OEE-Werte (Overall Equipment Effectiveness) erreichen als klassische Fabriken. Daten in Echtzeit analysieren, Wartungszyklen proaktiv steuern und Lieferketten vernetzen: Das senkt Kosten und erhöht die Resilienz. Mit frühzeitigen KI Investitionen erzielen Unternehmen also messbare Wettbewerbsvorteile und gestalten aktiv ihre Zukunftsfähigkeit.\nDer Fokus verlagert sich von reiner Automatisierung hin zu echter Autonomie, selbstlernende, selbststeuernde Systeme unter menschlicher Aufsicht. Der Weg dahin ist kein Sprung, sondern eine Entwicklung.\nIn Reifegraden lässt sich messen, wie Unternehmen die Interaktion zwischen Mensch und Maschine Schritt für Schritt auf ein neues Level heben können: von kontextbasierten Optimierungsempfehlungen der KI (Assistenz) über gemeinsame Lösungsfindung (Ko-Kreation) oder Orchestrierungs- und Priorisierungsaufgaben (Moderation) bis hin zu KI-Systemen, die sich selbst regulieren oder „heilen“ (Hochautonomie), mit dem Menschen als Supervisor.\nSo gelingt der Aufbau einer KI-gestützten Organisation # Technologische Komplexität, fehlende Skills bei den Mitarbeitenden, regulatorische Hürden und kulturelle Vorbehalte bremsen viele Pilotprojekte aus. Ohne robuste Datenarchitektur und verlässliches Mlops Framework (Machine Learning Operations) bleiben KI Modelle Einzellösungen. Zudem erfordert der Übergang von der silobasierten Linienorganisation zu agilen, funktionsübergreifenden Teams viel Führungsarbeit und aktives Change Management.\nDie Implementierung von KI ist selbstredend kein Plug-and-Play-Projekt. Es braucht einen ganzheitlichen Ansatz, der Mensch und Technologie zusammen denkt. Vier Dimensionen erweisen sich auf dem Weg zum „Cybernetic Enterprise“ als besonders erfolgskritisch:\nDatengetriebene Produktion: Wenn die Sensorik kontinuierlich den notwendigen „Rohstoff“ liefert, kann Edge-KI die Daten direkt an der Maschine verarbeiten, ohne Umwege über die Cloud. Das spart Zeit, erhöht die Reaktionsgeschwindigkeit und minimiert Ausfallzeiten. Plattformbasierte Architektur: Offene Schnittstellen und digitale Zwillinge ermöglichen die tiefgreifende Vernetzung von Entwicklungs-, Produktions- und Serviceprozessen. Eine skalierbare Plattform bildet die Basis für eine schnelle, sichere, flexible und anschlussfähige Nutzung von KI-Anwendungen. Lernende Systeme: Eine Organisation ist ständig in Bewegung, wie ein lebendiges System. Dafür sind Feedback-Loops essentiell. Sie bilden das Herzstück kontinuierlicher Weiterentwicklung und Optimierung. Der Mensch als Dirigent: Kollaborative Roboter (Cobots) übernehmen monotone Aufgaben. Menschen orchestrieren die Wertschöpfung, unterstützt durch Explainable AI, die Entscheidungen, Vorhersagen oder Empfehlungen eines KI-Systems für Menschen nachvollziehbar macht und damit Transparenz und Vertrauen schafft. Warum eigentlich „cybernetic“? In den letzten 15 bis 20 Jahren war die digitale Transformation das Maß der Dinge. Doch im KI-Zeitalter greift das kurz, inhaltlich wie begrifflich. Der Kybernetik-Begriff leitet sich vom griechischen Wort für „Steuermann“ ab und bezeichnet Regelungsprinzipien in komplexen Systemen, wobei Rückkopplung und zirkuläre Prozesse spielen hier eine zentrale Rolle. Damit eignet er sich hervorragend, um Modelle für die Zusammenarbeit zwischen Mensch und KI zu beschreiben.\n„Cybernetic Transformation“: Schritt für Schritt # Um den Wandel zum „Cybernetic Enterprise“ zu gestalten, braucht es einen trittfesten Transformationspfad. Ein erprobter Fahrplan hilft Unternehmen dabei, Stolpersteine zu umgehen oder zu beseitigen:\nVision und Use Cases priorisieren: Ein klares Zielbild ist unerlässlich. Zudem machen realistische Anwendungsfälle, die sowohl Quick Wins als auch langfristiges Potenzial bieten, den Einstieg greifbar, vom Condition Monitoring bis zur autonomen Intralogistik. Datenstrategie definieren: Wer verantwortet welche Daten? Wie wird Governance organisiert? Welche Sicherheitsstandards gelten? Eine Datenstrategie muss diese zentralen Fragen klären. Platform Engineering etablieren: Es empfiehlt sich, zentrale Plattformteams aufzubauen, die Devsecops-Pipelines (Development, Security, Operations), Self-Service-APIs und standardisierte Infrastruktur-Komponenten (Microservices) automatisiert bereitstellen. Sie sind zentrale Enabler für das eigenständige, schnelle und sichere Arbeiten mit KI-Produkten. Belegschaft befähigen: Weiterbildung ist Pflicht. Ob Upskilling, Citizen Data Scientist-Programm oder KI-Ethik-Training, Mitarbeitende müssen dazu in der Lage sein, mit der Technologie „im Team“ zu arbeiten. Denn hier geht es um nicht mehr und nicht weniger als einen Paradigmenwechsel. Skalierung und Betrieb sichern: KI-Systeme brauchen klare Prozesse für Edge-Deployment, Model Lifecycle Management und Compliance-Checks, damit der Laden läuft. Oder doch lieber „Industrie 5.0“? # Nachdem wir über so viele Jahre mit dem Begriff Industrie 4.0 operiert haben, wirkt es verführerisch, hier einfach das neue Release auszurufen. Doch Vorsicht: Der Begriff verleitet dazu, Industrie 4.0 für abgeschlossen zu erklären, obwohl viele ihrer technologischen Grundlagen wie Robotik, IoT (Internet of Things) und KI erst jetzt ihren produktiven Durchbruch erleben.\nNeu ist die noch stärkere Fokussierung auf den Menschen, auf Resilienz und Nachhaltigkeit, so hat die EU‑Kommission diese industrielle Phase bereits vor einigen Jahren definiert. Doch solange „5.0“ eher Buzzword und Narrativ als belastbarer Reifegrad ist, sollten Unternehmen das Etikett kritisch prüfen, sich an den Prinzipien der „Cybernetic Enterprise“ orientieren und pragmatisch auf konkrete Geschäftsergebnisse konzentrieren.\nMensch und Maschine: Wettbewerbsvorteil und unschlagbares Team # In der Organisation der Zukunft gibt es keine Trennung mehr zwischen menschlicher Intelligenz und maschineller Präzision. Es entsteht ein neues Betriebssystem für Wertschöpfung: kollaborativ, lernfähig, resilient.\nWer den Mut hat, den Menschen in den Mittelpunkt zu stellen und KI verantwortungsvoll zu orchestrieren, gestaltet nicht nur Prozesse neu, sondern auch die Kultur des Miteinanders. Der Weg zum „Cybernetic Enterprise“ ist kein Trend, sondern ein Evolutionsschritt. Und er beginnt jetzt.\nOriginal Artikel: https://www.industry-of-things.de/mensch-maschine-algorithmen-team-industrie-ki-ae-a-1d27fef006e523ef55d1dfb53538b4ac/\n","date":"23. November 2025","externalUrl":null,"permalink":"/de/blogs/wie-sich-industrieunternehmen-ai-ready-und-zukunftsfit-machen/","section":"Blogs","summary":" Wenn Menschen, Maschinen und Algorithmen als „Team“ arbeiten, entsteht mehr als Automatisierung, eine lernende und resiliente Fabrik. Doch wie gelingt Industrieunternehmen der Sprung in die KI-Ära, ohne den Menschen zu verlieren?\n","title":"Wie sich Industrieunternehmen „AI-ready“ und zukunftsfit machen","type":"blogs"},{"content":"","date":"19 November 2025","externalUrl":null,"permalink":"/en/tags/ai-governance/","section":"Tags","summary":"","title":"AI Governance","type":"tags"},{"content":"","date":"19. November 2025","externalUrl":null,"permalink":"/de/tags/ki-governance/","section":"Tags","summary":"","title":"KI-Governance","type":"tags"},{"content":" Summary # The NZZ article examines \u0026ldquo;Workslop\u0026rdquo; - a new term for sloppy work produced through careless AI use. While tech companies promote AI as a productivity miracle, the reality shows a darker side: AI makes it easy to produce polished-looking but often substanceless or incorrect content. This creates extra work for colleagues who must clean up the mess, damages trust in teams, and ultimately destroys the productivity AI was supposed to improve.\nThe article highlights how AI-generated content now makes up 50% of internet content, how marketing professionals \u0026ldquo;despair at polished AI garbage,\u0026rdquo; and how even major consulting firms like Deloitte have suffered reputational damage from unchecked AI errors.\nMy Quotes # \u0026ldquo;In the past, poor writers produced little, and certainly nothing that sounded this good.\u0026rdquo;\nOn the importance of maintaining ownership and control over AI-generated content:\n\u0026ldquo;AI cannot take responsibility. It must always remain your own content.\u0026rdquo;\nI advise to always maintain \u0026ldquo;Ownership\u0026rdquo; and to always verify AI-generated content before using it.\nRead the full article on NZZ\n","date":"19 November 2025","externalUrl":null,"permalink":"/en/publications/nzz-workslop-ai-productivity/","section":"Publications","summary":"Summary # The NZZ article examines “Workslop” - a new term for sloppy work produced through careless AI use. While tech companies promote AI as a productivity miracle, the reality shows a darker side: AI makes it easy to produce polished-looking but often substanceless or incorrect content. This creates extra work for colleagues who must clean up the mess, damages trust in teams, and ultimately destroys the productivity AI was supposed to improve.\n","title":"NZZ: Workslop, When AI Destroys Productivity","type":"publications"},{"content":"","date":"19 November 2025","externalUrl":null,"permalink":"/en/tags/productivity/","section":"Tags","summary":"","title":"Productivity","type":"tags"},{"content":"","date":"19. November 2025","externalUrl":null,"permalink":"/de/tags/produktivit%C3%A4t/","section":"Tags","summary":"","title":"Produktivität","type":"tags"},{"content":"","date":"19. November 2025","externalUrl":null,"permalink":"/de/tags/qualit%C3%A4t/","section":"Tags","summary":"","title":"Qualität","type":"tags"},{"content":"","date":"19 November 2025","externalUrl":null,"permalink":"/en/tags/quality/","section":"Tags","summary":"","title":"Quality","type":"tags"},{"content":"","date":"19 November 2025","externalUrl":null,"permalink":"/en/tags/workslop/","section":"Tags","summary":"","title":"Workslop","type":"tags"},{"content":"Artificial Intelligence is on everyone\u0026rsquo;s lips. But between media hype and concrete value for facility management, there is often a gap.\nWhat This Talk Covers # In this talk, Romano Roth first explains what AI really is and how it works, giving participants a clear foundation to properly assess the technology.\nBuilding on that, he shows practical use cases from facility management. Through a typical workday, it becomes clear how AI can support work and increase efficiency without replacing human decision-making authority.\nKey Messages # 1. Understanding AI, Not Just Talking About It What AI really is and how it works. A clear foundation for assessing the technology beyond the buzzwords.\n2. Practice Over Theory Through a typical workday in facility management, the talk shows how AI can concretely support and improve work efficiency without replacing human decision-making.\n3. Realistically Assessing Opportunities and Limits It is not just about possibilities, but also about the limits and risks of AI solutions. Cutting through the buzzword fog to show how a trend becomes real value.\n","date":"23 October 2025","externalUrl":null,"permalink":"/en/speaking/ki-im-facility-management/","section":"Speaking","summary":"Artificial Intelligence is on everyone’s lips. But between media hype and concrete value for facility management, there is often a gap.\nWhat This Talk Covers # In this talk, Romano Roth first explains what AI really is and how it works, giving participants a clear foundation to properly assess the technology.\n","title":"AI in Facility Management: From Trend to Real Value","type":"speaking"},{"content":"","date":"23 October 2025","externalUrl":null,"permalink":"/en/tags/facility-management/","section":"Tags","summary":"","title":"Facility Management","type":"tags"},{"content":"Von Nazila Sfika und Romano Roth\nAlle reden von industrieller KI, aber wo steckt der breite Nutzen? Zu viele Unternehmen stecken in der \u0026ldquo;Pilotphase\u0026rdquo; fest, mit fragmentierten Tools und begrenzten Ergebnissen. In diesem Artikel zeigen wir, wie Cybernetic Thinking den PoC-Loop durchbrechen und KI in Ihrem Unternehmen skalieren kann, um Nutzen im großen Maßstab zu erzielen.\nIndustrial AI wird oft als Allheilmittel für die Herausforderungen der Industrie propagiert. Unsere Erfahrung zeigt jedoch: Die Realität sieht anders aus. Viele Initiativen starten mit großem Enthusiasmus, bleiben dann aber in der Konzeptphase stecken. Laut IDC schaffen es 88 % aller untersuchten Proof-of-Concepts nicht in die Produktion. Das bedeutet: Von 33 gestarteten Projekten erreichen nur vier die Umsetzung.\nDiese „Pilotfalle“ (Pilot Purgatory) ist in der digitalisierten Produktion kein neues Phänomen. Lokale Optimierungen, etwa in der Wartung oder Qualitätskontrolle, bringen zwar Verbesserungen in Größenordnungen von 5-10 %, aber ohne systemische Integration bleibt der Gesamterfolg aus. Die eigentliche Skalierungslücke liegt in der Organisation und Architektur begründet.\nWarum der Status quo nicht reicht? Argumente für den Change # Inkrementelle Verbesserungen oder isolierte Projekte bringen nicht den gewünschten Erfolg. Industrieunternehmen stehen unter hohem Wettbewerbsdruck, kämpfen mit unsicheren Lieferketten und sinkenden Margen. Kund:innen und Regulierungsbehörden verlangen höhere Standards bei Sicherheit, Transparenz und Nachhaltigkeit.\nViele Initiativen für KI in der Industrie konzentrieren sich auf einzelne Maschinen, Linien oder Abteilungen und lassen angegliederte Prozesse außen vor. Das führt zu punktuellen Beschleunigungen, aber einem insgesamt trägen Unternehmen. Mehr Pilotprojekte bedeuten nicht mehr Fortschritt, denn nur eine systemische Integration führt zum Ziel.\nFührungskräfte müssen den Change von Projektdenken zu Systemdenken vollziehen. Das bedeutet: KI sollte nicht als Zusatzmodul verstanden werden, sondern als Teil eines lebenden Steuerungssystems für das gesamte Unternehmen.\nDas Industrial AI Paradoxon: Erfolgreiche Use Cases, wenig Gesamtnutzen # Selbst erfolgreiche KI-Piloten bringen häufig nur isolierte Vorteile. Daten bleiben über OT- und IT-Systeme hinweg fragmentiert, von Fertigungsanlagen über Qualitätssysteme bis zu ERP- und MES-Schichten. Predictive-Maintenance-Modelle laufen unabhängig von Qualitätsprüfungen, und Algorithmen bleiben punktuelle Lösungen. Das Problem: KI auf bestehende Einzelprozesse zu „schichten“, bringt kaum nachhaltige Wirkung\nGleichzeitig steigen die Investitionen weiter. IDC prognostiziert weltweite KI-Ausgaben von rund 632 Milliarden US-Dollar bis 2028. Gewiss: Skalierung ist unverzichtbar, doch sie muss koordiniert erfolgen, um echten Mehrwert zu schaffen.\nOhne einheitliche Datenprodukte, klar definierte Schnittstellen und domänenübergreifendes Feedback wird der Prozess lediglich komplexer, ohne eine nennenswerte Wirkung zu erzielen. Was nützt ein mit einem prädiktiven Modell optimierter Prozessor, wenn er in der Produktionsplanung nicht berücksichtig wird?\nCybernetic Thinking als Antwort: Das lernende Unternehmen # Cybernetic Thinking verspricht einen Ausweg aus der Pilotfalle. Anstatt isolierten KI-Anwendungsfällen hinterherzujagen, wird das Unternehmen selbst zu einem lernenden, adaptiven System, in dem Strategie, Betrieb und Technologie kontinuierlich aufeinander abgestimmt werden.\nWir sprechen hier vom sogenannten Cybernetic Enterprise, einem lebenden Betriebssystem für das Unternehmen, das fortlaufend analysiert, entscheidet und handelt. Gestützt auf Feedback-Loops, KI-gestützte Daten und handlungsfähige Teams entsteht eine Organisation, die sich selbst steuert und ständig verbessert.\nFunktionsübergreifende Teams sind entlang domänenorientierter Value Streams organisiert. Sie tragen von Anfang bis Ende die volle Verantwortung für ihre Ergebnisse brechen Silos auf. Domänen könnten etwa Smart-Factory-Operations, Maintenance \u0026amp; Asset Reliability, Lieferkettenresilienz oder Kundenservice sein.\nIm Mittelpunkt steht die Triade aus Organisation, Technologie und Prozess, die als ein einziges System konzipiert sein muss. Ohne diese Integration bleiben KI-Anwendungsfälle isoliert und kommen in der Skalierung nicht voran.\nZentrale Merkmale des Cybernetic Enterprise in der Industrie # Kontinuierliche Abstimmung # Strategie und operativer Betrieb sind über Echtzeit-Feedback miteinander verbunden. Dies ermöglicht schnelle Entscheidungen, die auf Live-Daten basieren.\nDomänenorientierte Value Streams # Funktionsübergreifende Teams übernehmen die komplette Verantwortung für Wertströme, z. B. in Domänen wie Smart Factory, Wartung \u0026amp; Anlagenzuverlässigkeit, Lieferkettenresilienz oder Customer Onboarding. Silos werden aufgebrochen.\nEmbedded AI # KI wird als Entscheidungspartner verstanden. Sie unterstützt menschliches Urteilsvermögen durch Einblicke in Echtzeit.\nDatengetriebene Architektur # OT- und IT-Systeme liefern hochwertige Datenprodukte über standardisierte Schnittstellen, skalierbar und interoperabel.\nPlattform als Produkt # Die interne Plattform wird wie jedes andere Produkt behandelt, mit standardisierten Arbeitsabläufen, Policy-as-Code, Observability und eingebetteter KI. Governance wird zu einem natürlichen Nebeneffekt statt zur Hürde.\nSelbstoptimierung # Das System lernt und passt sich an. Es erkennt Veränderungen in der Umgebung und justiert Prozesse, Ressourcen und Prioritäten in Echtzeit.\nWo liegen die Grenzen des Cybernetic Enterprise? # Das Cybernetic Enterprise ist kein Allheilmittel. Seine Stärke liegt darin, Sensorik, Entscheidung und Handlung im gesamten Unternehmen zu verknüpfen und nicht darin, jede Herausforderung zu lösen. Wir möchten Ihnen daher auch ganz transparent zeigen, wo der Ansatz an seine Grenzen stößt und welche Aspekte er nicht ersetzen kann:\nMenschliches Urteilsvermögen: Strategische Abwägungen und ethische Entscheidungen bleiben in Menschenhand. Unvorhersehbare Ereignisse: Resilienz ermöglicht eine bessere Reaktionsfähigkeit, kann jedoch Disruptionen nicht vorhersagen. Datenqualität: Schlechte oder verzerrte Daten führen zu schlechten Ergebnissen, daher ist Governance unerlässlich. Kultur: Ohne Führung und Empowerment scheitern selbst die besten Systeme. Physikalische Gegebenheiten und Regulierung: Bestehende Einschränkungen in Bezug auf Produktionszyklen, Sicherheitsvorgaben und Validierungsprozesse bleiben unverhandelbar. Cybernetic Thinking: Warum Führungskräfte jetzt handeln müssen # Punktuelle Verbesserungen und isolierte Piloten sind zu wenig. Kostendruck, Lieferkettenrisiken und regulatorische Anforderungen verlangen ganzheitliche unternehmensweite Lösungen. Das Kybernetik-Modell ist der Schlüssel zu operativer Resilienz, Wettbewerbsfähigkeit und Attraktivität für technische Fachkräfte und Betreiber.\nZühlke hat daher eine 90-Tage-Roadmap entwickelt, die Führungskräfte dabei unterstützt, das Kybernetik-Modell in die Praxis umzusetzen. An dieser Stelle sei auch angemerkt, dass der Prozess nicht nach 90 Tagen abgeschlossen ist. Dieser Zeitraum bildet lediglich den Einstieg in eine kontinuierliche Transformation.\n90-Tage-Roadmap: Vom Pilotprojekt zur Plattform # Die Vision zu verstehen ist der erste Schritt. Entscheidend ist jedoch die Umsetzung: Aus einem isolierten Piloten muss eine skalierbare Plattform entstehen.\nDie ersten 90 Tage auf dem Weg zum Cybernetic Enterprise # 1. Basis schaffen (Tag 0 - 30) # Ziel: Einen soliden, kontrollierten Ausgangspunkt schaffen.\nEine stabile Basislinie wählen, zentrale KPIs als Basis festlegen, Umgebung sichern mit ISA-95-Mapping und IEC 62443-Zonen.\n2. Vernetzung und Validierung (Tag 31 - 60) # Ziel: Systeme verknüpfen, Datenqualität sicherstellen und KI-Empfehlungen testen.\nSysteme über OPC UA/MQTT verbinden, Datenintegrität validieren, „Shadow AI“ einsetzen mit Operator-Feedback.\n3. Closing the loop (Tag 61 - 90) # Ziel: Vom Testen zum echten Handeln übergehen.\nEinen Loop mit menschlicher Aufsicht automatisieren, ein skalierbares Playbook dokumentieren, eine Toolbox für die Skalierung vorbereiten.\n4. Transformation fortsetzen # Validieren Sie die Datenintegrität und führen Sie die KI im „Human-in-the-Loop“-Modus mit Expertenfeedback aus.\nDiese Roadmap beschreiben wir ausführlich in unserem kommenden Whitepaper, von der Bewertung des Ist-Zustands über die Konzeption eines individuell passenden Kybernetik-Modells bis zur Umsetzung von Veränderungen in Sprints.\nDarüber hinaus beschreibt das Whitepaper Rahmenbedingungen und Anwendungsbeispiele, wie sich ein solches Modell in die Praxis umsetzen lässt.\nFühren Sie die Transformation über den Hype hinaus # Der Hype um KI verblasst. Wer langfristig erfolgreich sein will, braucht echte Anpassungsfähigkeit. Genau die liefert das Cybernetic Enterprise: ein Unternehmen, das kontinuierlich lernt, sich weiterentwickelt und innovativ ist.\nDie Schritte der Transformation im Überblick:\nWählen sie einen konkreten Value Stream aus, der optimiert werden soll. Ernennen Sie eine verantwortliche Person. Identifizieren Sie zentrale Prozesse und Abhängigkeiten: Was schafft wirklich Wert? Definieren Sie kritische Datenquellen und System-Schnittstellen. Legen Sie drei nicht verhandelbare KPIs als Erfolgsmaß fest. Integrieren Sie EU-AI-Act-Readiness in jede KI-Story. Etablieren Sie Feedback-Loops, um Ergebnisse und Learnings kontinuierlich zu erfassen. Richten Sie IT-, OT- und Business-Teams auf gemeinsame Ziele aus. Bauen Sie Kompetenzen für sicheren, wirksamen KI-Einsatz auf. Denken Sie daran: Regelmäßig überprüfen, lernen, anpassen und erneut iterieren. Transformation ist ein anspruchsvoller Prozess, der jedoch alle Mühe lohnt. Die Zukunft gehört Unternehmen, die den Wandel als natürliche Entwicklung begreifen und schneller lernen und reagieren als die Welt sich verändert.\nWoher wissen Sie, dass Sie auf dem richtigen Weg sind?\nDeployments sind kleiner und erfolgen sicherer. Teams diskutieren über Outcomes statt Outputs. Dashboards bilden Wirkung statt Aktivität ab. Führungskräfte steuern anhand von Live-Daten statt statischer Reports. In der industriellen Transformation sind Geschwindigkeit und Anpassungsfähigkeit die entscheidenden Differenzierungsmerkmale. Das Cybernetic Enterprise liefert die Architektur dafür. Die Frage ist nicht ob, sondern wie schnell Sie Ihren Feedback-Loop aufbauen.\nOriginal Artikel: https://www.zuehlke.com/de/insights/industrial-ai-im-grossen-massstab-warum-fuehrung-heute-kybernetisch-denken-muss\n","date":"15. October 2025","externalUrl":null,"permalink":"/de/blogs/industrial-ai-im-grossen-massstab-warum-fuehrung-heute-kybernetisch-denken-muss/","section":"Blogs","summary":"Von Nazila Sfika und Romano Roth\nAlle reden von industrieller KI, aber wo steckt der breite Nutzen? Zu viele Unternehmen stecken in der “Pilotphase” fest, mit fragmentierten Tools und begrenzten Ergebnissen. In diesem Artikel zeigen wir, wie Cybernetic Thinking den PoC-Loop durchbrechen und KI in Ihrem Unternehmen skalieren kann, um Nutzen im großen Maßstab zu erzielen.\n","title":"Industrial AI im großen Maßstab: Warum Führung heute kybernetisch denken muss","type":"blogs"},{"content":"Everyone talks about Industrial AI, but where\u0026rsquo;s the impact at scale? Too many companies are stuck in pilot purgatory, with fragmented tools and limited results. In this article, we show how cybernetic thinking can break the PoC loop and scale AI across your organisation for real business impact.\nIndustrial AI is often portrayed as the cure-all for the industrial sector’s challenges. Yet in our daily work, we see that reality as more complex. Many initiatives launch with fanfare but stall at the proof-of-concept (PoC) stage. Recent research from IDC found that 88% of observed AI proof-of-concepts did not scale to production, meaning that for every 33 PoCs, only four successfully moved into production. ‘Pilot purgatory’ is not new in digital manufacturing, isolated successes rarely scale across the enterprise.\nThis mirrors what we see on the ground. Local optimisations in maintenance or quality yield improvements of 5-10%, but without systemic integration, global OEE or throughput barely budges. The scaling gap is organisational and architectural, not analytical.\nThe case for change: why is the status quo not enough? # Incremental improvements or siloed projects are no longer sufficient. Industrial companies face intense global competition, shrinking margins, and volatile supply chains. Customers and regulators increasingly demand higher standards for safety, transparency, and sustainability.\nMany industrial AI initiatives optimise a single cell, machine, or department while leaving surrounding processes untouched. The result is faster pockets but a slow enterprise. More pilots alone will not speed up progress, systemic integration is essential.\nLeaders must shift from \u0026lsquo;project thinking\u0026rsquo; to \u0026lsquo;system thinking\u0026rsquo;. This means treating AI not as a bolt-on to existing workflows but as part of a living control system for the enterprise.\nIndustrial AI paradox: successful use cases, little overall gain # Even successful AI pilots often deliver siloed benefits. Data remains fragmented across operational technology and information technology systems, including industrial and manufacturing systems \u0026amp; technologies representing different layers of automation and management system. Predictive maintenance runs apart from quality checks, and algorithms remain point solutions. Layering AI on broken processes delivers little overall impact.\nMeanwhile, investment continues to rise. IDC forecasts worldwide AI spending of about US$ 632 billion by 2028. Scale matters, but disciplined scale matters more.\nWithout unified data products, governed interfaces, and cross-domain feedback, these investments compound complexity rather than value. A predictive model may optimise a compressor, but if production scheduling ignores it, the benefit evaporates.\nThe cybernetic response: a living, learning system # Escaping pilot purgatory requires cybernetic thinking. Instead of chasing isolated AI use cases, the organisation should operate as a learning, adaptive system, where strategy, operations, and technology work in continuous alignment. The so-called Cybernetic Enterprise. Think of it as the organisation’s operating system: continuously sensing, deciding, and acting through feedback loops, AI-augmented intelligence, and empowered teams.\nCross-functional teams are organised around domain-oriented value streams, owning outcomes end-to-end and breaking down silos. Domains may include smart factory operations, maintenance \u0026amp; asset reliability, supply chain resilience, or customer service. At the core sits the Triad of Intelligence: organisation, technology, and process, which must be designed as one system. Without this integration, AI use cases remain isolated and stall at scale.\nCore characteristics of the Industrial Cybernetic Enterprise include: # Continuous alignment # Strategy and operations stay tightly connected through live feedback loops, enabling rapid, evidence-based decisions.\nEmbedded AI # AI acts as a decision-support partner, augmenting human judgement and providing real-time insights.\nPlatform as product # The internal platform is treated like any other product, with golden paths, policy-as-code, observability, and embedded AI. It enables speed and safety by design and turns governance into a natural side-effect.\nDomain-oriented value streams # Cross-functional teams own outcomes end-to-end, dismantling silos. Domains may include smart factory operations, supply chain resilience, or customer onboarding.\nData-driven architecture # OT/IT systems deliver high-quality data products through standardised interfaces, enabling scalable, interoperable solutions.\nSelf-tuning and learning # Continuous optimisation by sensing environmental changes and adapting resources, processes, and priorities quickly.\nIs there anything Cybernetic Enterprise can’t do? # Yes, indeed. The Cybernetic Enterprise is powerful because it connects sensing, decision, and action across the whole organisation, enabling adaptability and scale. But it’s not a silver bullet. Treat the following as design constraints, limits you must explicitly respect when building a cybernetic organisation:\nReplace human judgement: Strategic trade-offs and ethics remain with people; AI is a co-pilot. Predict every disruption: Black swans still surprise, resilience improves response, not prophecy. Fix bad data: Poor or biased data produces poor outcomes; governance is essential. Solve cultural problems: Without leadership and empowerment, even the best systems fail. Defy physics or regulation: Cycle times, safety, and validation constraints still apply. The cybernetic imperative: Why leaders must act now # Incremental improvements and siloed pilots are no longer sufficient. Cost pressure, supply chain volatility, and rising regulatory expectations demand systemic, enterprise-wide solutions. Adopting the cybernetic model is key to operational resilience, competitive advantage, and attracting skilled engineers and operators.\nTo help you get started, we created a 90-day roadmap that helps leaders implement the cybernetic model in practice. But please be aware that transformation is continuous, it does not stop after 90 days, this is just the beginning.\nThe first 90 days: roadmap from pilot to platform # Understanding the vision is one step, executing it is where the real transformation begins. The next question is: how do we do this in practice? The path should take you from an isolated pilot to a scalable platform.\nThe first 90 days on the road to the Cybernetic Enterprise # 1. Laying the foundation (day 0 - 30) # Goal: Establish a solid, controlled starting point.\nSelect one stable line, baseline key KPIs, and secure the environment with ISA-95 mapping and IEC 62443 zones.\n2. Connecting and validating (day 31 - 60) # Goal: Link systems, ensure data quality, and test AI recommendations.\nConnect systems via OPC UA/MQTT, validate data integrity, and run ‘shadow AI’ with operator feedback.\n3. Closing the loop (day 61 - 90) # Goal: Move from testing to real action.\nAutomate one loop with human oversight, document a repeatable playbook, and prepare a replication kit for scaling.\n4. Continue the transformation # Validate data integrity and run the AI in human-in-the-loop mode with expert feedback.\nOur upcoming whitepaper expands on this roadmap: assessing the current state, designing a tailored cybernetic model, and executing change in sprints. It provides frameworks and real-life examples to translate cybernetic vision into operational reality.\nLead the shift beyond the hype # As AI hype fades, lasting advantage will come from systemic adaptability. This is the cybernetic imperative: building enterprises that learn, adapt, and innovate continuously. For industrial leaders, the call is clear. This quarter:\nChoose a value stream to optimise. Nominate a value-stream owner. Map key processes and dependencies within the value stream (to understand what really drives value). Identify critical data sources and system touchpoints (ensure the right inputs for AI and process improvements). Set three non-negotiable KPIs as metrics. Require EU AI Act readiness in every AI user story from now on. Establish a feedback loop to capture lessons and outcomes continuously. Align IT, OT, and business teams around the chosen value stream. Invest in skill-building for teams to operate and innovate with AI safely. Review and iterate continuously and adjust based on results. Transformation won’t be easy, but the reward is an organisation built for change. The future belongs to enterprises that learn and pivot faster than the world changes. The time to lead that shift is now.\nYou will know you are on the right path when these signals emerge:\nSmaller, safer deployments Teams discussing outcomes rather than outputs Dashboards shifting from activity metrics to impact metrics Executives steering by live feedback rather than static reports In industrial transformation, speed and adaptability are the differentiators. The Cybernetic Enterprise provides the architecture to achieve it. The question is not if, but how fast you can build your feedback loop.\nOriginal Article: https://www.zuehlke.com/en/insights/industrial-ai-at-scale-the-cybernetic-imperative-for-leaders\n","date":"14 October 2025","externalUrl":null,"permalink":"/en/blogs/industrial-ai-at-scale-the-cybernetic-imperative-for-leaders/","section":"Blogs","summary":"Everyone talks about Industrial AI, but where’s the impact at scale? Too many companies are stuck in pilot purgatory, with fragmented tools and limited results. In this article, we show how cybernetic thinking can break the PoC loop and scale AI across your organisation for real business impact.\n","title":"Industrial AI at scale: The cybernetic imperative for leaders","type":"blogs"},{"content":"","date":"14 October 2025","externalUrl":null,"permalink":"/en/tags/industry/","section":"Tags","summary":"","title":"Industry","type":"tags"},{"content":"","date":"12 October 2025","externalUrl":null,"permalink":"/en/tags/book/","section":"Tags","summary":"","title":"Book","type":"tags"},{"content":"","date":"12. October 2025","externalUrl":null,"permalink":"/de/tags/buch/","section":"Tags","summary":"","title":"Buch","type":"tags"},{"content":"In this LeanPub podcast episode, host Len Epp and I have a deep conversation about my book \u0026ldquo;The Cybernetic Enterprise: How to Build a Future-Ready Organization.\u0026rdquo; We cover everything from my career journey at Zühlke, to why the future is cybernetic rather than just AI, to the practical steps of enterprise transformation. If you have ever wondered what it takes to build an organization that can continuously adapt, this conversation covers the essential ideas.\nFrom Civil Engineering to Software Engineering # My path into technology started in Basel, Switzerland, where I grew up. I did an apprenticeship in civil engineering, and during that time in 1994, computers and the internet arrived. I was always drawn to them, drawing my plans on the computer even though the final exam required hand drawings. After that apprenticeship, I went to university to study technical information science, visited Zühlke during a company tour, and joined right after graduation as a junior .NET engineer. Over 23 years at Zühlke, I progressed from junior to expert software engineer, lead architect, principal consultant, and now global chief of cybernetic transformation.\nOne thing that was always close to my heart: how can we continuously deliver value, automate things, and ensure quality? That question led me through DevOps, platform engineering, and ultimately to the concept of the Cybernetic Enterprise.\nThe Missing Piece: System Thinking # As a consultant working with different clients, I kept seeing the same pattern. Companies would ask me to improve their development process. The developers got faster, but then testing became a bottleneck. We fixed testing, and operations became the bottleneck. The business side had problems bringing requirements in efficiently.\nThe fundamental thing that is usually missing is that we focus too much on one part and don\u0026rsquo;t understand the root cause. We don\u0026rsquo;t have an overview of the whole system.\nThis is why I wrote \u0026ldquo;The Cybernetic Enterprise.\u0026rdquo; Organizations need to zoom out and look at the entire system: technology, processes, and organization together. You cannot fix technology without adapting processes, and you will not get the real benefits unless you also adapt the organization.\nWhy the Future Is Cybernetic, Not AI # When I dove into the AI topic, I soon realized that AI is a powerful tool, one I use every day, but it is still just a tool. Then I discovered the concept of cybernetics, which dates back to the 1940s. Cybernetics means that humans and technology (including AI) work together in closed feedback loops.\nThis is exactly what I always say: AI will not replace us. We need to build organizations where AI and humans work together. The moon landing was a cybernetic system, a profoundly impressive one, where humans and technology collaborated to achieve something extraordinary. An enterprise is the same: a cybernetic system where technology and humans operate in closed feedback loops.\nThe problem in most enterprises is that these feedback loops are too slow. Budgeting happens once a year. Companies need to adapt much faster in a world where markets shift, tariffs appear overnight, and technology evolves at breakneck speed. The Cybernetic Enterprise shortens these feedback loops so the organization can continuously adapt and improve.\nAdaptive Systems and the Power of Focus # When I talk about adaptive systems, I mean bringing the agility of a startup into larger organizations. Today, most companies have their organizational structure set in stone. In a Cybernetic Enterprise, you decouple organizational units, give them more trust and responsibility, and make them responsive to market demands. Think of smaller units operating like startups within the larger enterprise.\nYou need to architect your organization as you architect your technology landscape or your software.\nFocus is critical and often underestimated. Focus means saying no. When you design the Cybernetic Enterprise, you need to create units that have a clear focus and clear responsibility. Without that, you end up with the organizational equivalent of a big ball of mud.\nEngineering Practices Matter More Than Ever # With AI, many managers believe they will not need developers anymore. I have seen this before. When Java arrived, managers said the same thing. The opposite happened: because you could build more complex applications, you needed more developers.\nThe same goes for AI. When I vibe-code for more than two hours, everything falls apart. What you need to get it right is engineering practices: creating tests, engineering the system, defining context, designing architecture. Programming was never the bottleneck in a developer\u0026rsquo;s day. It is perhaps 30% of the time. The rest is thinking through problems, understanding context, and ensuring quality. AI helps with all of that, but it does not replace the need for engineering.\nAI will not completely replace developers. Developers are needed to give context, to engineer, to see the bigger picture.\nThe Cybernetic Transformation: Start Small # Where does transformation begin? With real need. Either the management is standing on a burning platform, or you have a group of people who genuinely want change. Without that buy-in, stop. The change will never happen.\nOnce you have buy-in, start with a pilot team. I am not a fan of massive transformations that try to change everything at once, because the danger of creating a mess and destroying things that work is too high. Instead, probe the system with a smaller team, create a protective bubble around them (this is where management support is essential), give them full responsibility and tools, and move fast with short feedback loops. Learn what works and what does not. Then scale to other teams based on what you learned.\nThe transformation is complete not when the program ends, but when the organization has built the capabilities to continuously evolve, learn, and thrive, even without external intervention.\nGovernance: The Fourth Pillar # Beyond organization, processes, and technology, governance is the fourth essential element of a Cybernetic Enterprise. You cannot fix ethical questions, data handling policies, or AI ethics with processes or technology alone. These require governance, guiding rules set at the highest levels of the organization. Usually, enterprises already have governance in place, but it needs to be adapted for the cybernetic model.\nKey Takeaways # The future is cybernetic, not just AI: Cybernetics means humans and technology working in closed feedback loops to continuously adapt Zoom out: Most transformation failures happen because organizations focus on one part without understanding the whole system Focus is saying no: Create organizational units with clear responsibilities, just like components in software architecture Engineering practices matter more than ever: AI accelerates development, but does not replace the need for solid architecture, testing, and system design Start small, learn fast: Begin transformation with pilot teams, protect them, measure outcomes, and scale based on real learnings Governance is essential: Ethical guidelines, data policies, and AI ethics cannot be solved by technology or processes alone ","date":"12 October 2025","externalUrl":null,"permalink":"/en/blogs/how-to-build-a-future-ready-organization/","section":"Blogs","summary":"In this LeanPub podcast episode, host Len Epp and I have a deep conversation about my book “The Cybernetic Enterprise: How to Build a Future-Ready Organization.” We cover everything from my career journey at Zühlke, to why the future is cybernetic rather than just AI, to the practical steps of enterprise transformation. If you have ever wondered what it takes to build an organization that can continuously adapt, this conversation covers the essential ideas.\n","title":"How to Build a Future-Ready Organization","type":"blogs"},{"content":"","date":"12 October 2025","externalUrl":null,"permalink":"/en/tags/software-engineering/","section":"Tags","summary":"","title":"Software Engineering","type":"tags"},{"content":"In dieser Folge des LeanPub-Podcasts führe ich mit Moderator Len Epp ein ausführliches Gespräch über mein Buch «The Cybernetic Enterprise: How to Build a Future-Ready Organization». Wir sprechen über meinen Werdegang bei Zühlke, darüber, warum die Zukunft kybernetisch ist und nicht einfach nur KI, und über die praktischen Schritte der Unternehmenstransformation. Wenn Sie sich jemals gefragt haben, was es braucht, um eine Organisation aufzubauen, die sich kontinuierlich anpassen kann, deckt dieses Gespräch die wesentlichen Ideen ab.\nVom Bauingenieur zum Software Engineer # Mein Weg in die Technologie begann in Basel, wo ich aufgewachsen bin. Ich absolvierte eine Lehre im Bauingenieurwesen, und während dieser Zeit im Jahr 1994 kamen Computer und Internet auf. Mich zog es immer dorthin. Ich zeichnete meine Pläne am Computer, obwohl die Abschlussprüfung Handzeichnungen verlangte. Nach der Lehre studierte ich technische Informatik, besuchte während einer Firmenbesichtigung Zühlke und trat direkt nach dem Studium als Junior-.NET-Engineer ein. Über 23 Jahre bei Zühlke entwickelte ich mich vom Junior zum Expert Software Engineer, Lead Architect, Principal Consultant und heute Global Chief of Cybernetic Transformation.\nEine Frage hat mich immer begleitet: Wie können wir kontinuierlich Wert liefern, Dinge automatisieren und Qualität sicherstellen? Diese Frage führte mich über DevOps und Platform Engineering zum Konzept des Cybernetic Enterprise.\nDas fehlende Puzzlestück: Systemdenken # Als Berater bei verschiedenen Kunden sah ich immer wieder dasselbe Muster. Unternehmen baten mich, ihren Entwicklungsprozess zu verbessern. Die Entwickler wurden schneller, aber dann wurde das Testing zum Engpass. Wir verbesserten das Testing, und der Betrieb wurde zum Engpass. Der Fachbereich hatte Probleme, Anforderungen effizient einzubringen.\nDas Grundlegende, was meist fehlt, ist, dass wir uns zu sehr auf einen Teil fokussieren und die Ursache nicht verstehen. Wir haben keinen Überblick über das Gesamtsystem.\nDeshalb habe ich «The Cybernetic Enterprise» geschrieben. Organisationen müssen herauszoomen und das gesamte System betrachten: Technologie, Prozesse und Organisation zusammen. Man kann Technologie nicht reparieren, ohne Prozesse anzupassen, und man wird den wirklichen Nutzen nicht erreichen, wenn man nicht auch die Organisation anpasst.\nWarum die Zukunft kybernetisch ist, nicht KI # Als ich mich in das KI-Thema vertiefte, wurde mir schnell klar, dass KI ein mächtiges Werkzeug ist, das ich täglich nutze, aber eben nur ein Werkzeug. Dann entdeckte ich das Konzept der Kybernetik, das in die 1940er Jahre zurückreicht. Kybernetik bedeutet, dass Menschen und Technologie (einschliesslich KI) in geschlossenen Feedback-Loops zusammenarbeiten.\nGenau das sage ich immer: KI wird uns nicht ersetzen. Wir müssen Organisationen bauen, in denen KI und Menschen zusammenarbeiten. Die Mondlandung war ein kybernetisches System, ein zutiefst beeindruckendes, in dem Menschen und Technologie zusammenwirkten, um etwas Aussergewöhnliches zu erreichen. Ein Unternehmen ist dasselbe: ein kybernetisches System, in dem Technologie und Menschen in geschlossenen Feedback-Loops agieren.\nDas Problem in den meisten Unternehmen ist, dass diese Feedback-Loops zu langsam sind. Budgetierung passiert einmal im Jahr. Unternehmen müssen sich viel schneller anpassen in einer Welt, in der sich Märkte verschieben, Zölle über Nacht auftauchen und Technologie sich rasant weiterentwickelt. Das Cybernetic Enterprise verkürzt diese Feedback-Loops, damit die Organisation sich kontinuierlich anpassen und verbessern kann.\nAdaptive Systeme und die Kraft des Fokus # Wenn ich von adaptiven Systemen spreche, meine ich, die Agilität eines Startups in grössere Organisationen zurückzubringen. Heute sind in den meisten Unternehmen die Organisationsstrukturen in Stein gemeisselt. In einem Cybernetic Enterprise entkoppelt man Organisationseinheiten, gibt ihnen mehr Vertrauen und Verantwortung und macht sie reaktionsfähig gegenüber Marktanforderungen. Stellen Sie sich kleinere Einheiten vor, die wie Startups innerhalb des grösseren Unternehmens operieren.\nMan muss seine Organisation genauso architektonisch gestalten wie seine Technologielandschaft oder seine Software.\nFokus ist entscheidend und wird oft unterschätzt. Fokus bedeutet Nein sagen. Wenn man das Cybernetic Enterprise gestaltet, muss man Einheiten schaffen, die einen klaren Fokus und eine klare Verantwortung haben. Ohne das endet man beim organisatorischen Äquivalent eines Big Ball of Mud.\nEngineering-Praktiken sind wichtiger denn je # Mit KI glauben viele Manager, dass sie keine Entwickler mehr brauchen. Das habe ich schon einmal erlebt. Als Java aufkam, sagten Manager dasselbe. Das Gegenteil trat ein: Weil man komplexere Anwendungen bauen konnte, brauchte man mehr Entwickler.\nDasselbe gilt für KI. Wenn ich länger als zwei Stunden «Vibe Coding» mache, fällt alles auseinander. Was man braucht, um es richtig zu machen, sind Engineering-Praktiken: Tests schreiben, das System entwerfen, den Kontext definieren, die Architektur gestalten. Programmieren war nie der Engpass im Alltag eines Entwicklers. Es sind vielleicht 30% der Zeit. Der Rest ist Nachdenken über Probleme, Kontext verstehen und Qualität sicherstellen. KI hilft bei alldem, ersetzt aber nicht die Notwendigkeit von Engineering.\nKI wird Entwickler nicht vollständig ersetzen. Entwickler werden gebraucht, um Kontext zu geben, zu engineeren und das Gesamtbild zu sehen.\nDie kybernetische Transformation: Klein anfangen # Wo beginnt die Transformation? Mit echtem Bedarf. Entweder steht das Management auf einer brennenden Plattform, oder es gibt eine Gruppe von Menschen, die wirklich Veränderung wollen. Ohne dieses Buy-in: Aufhören. Die Veränderung wird nie stattfinden.\nSobald man das Buy-in hat, beginnt man mit einem Pilotteam. Ich bin kein Fan von Grosstransformationen, die alles auf einmal ändern wollen, denn die Gefahr, Chaos zu erzeugen und funktionierende Dinge zu zerstören, ist zu gross. Stattdessen tastet man sich mit einem kleineren Team ins System vor, schafft eine schützende Blase um sie (hier ist die Unterstützung des Managements essenziell), gibt ihnen volle Verantwortung und Werkzeuge und bewegt sich schnell mit kurzen Feedback-Loops. Man lernt, was funktioniert und was nicht. Dann skaliert man auf andere Teams basierend auf den gewonnenen Erkenntnissen.\nDie Transformation ist nicht abgeschlossen, wenn das Programm endet, sondern wenn die Organisation die Fähigkeit aufgebaut hat, sich kontinuierlich weiterzuentwickeln, zu lernen und zu gedeihen, auch ohne externe Unterstützung.\nGovernance: Die vierte Säule # Neben Organisation, Prozessen und Technologie ist Governance das vierte essenzielle Element eines Cybernetic Enterprise. Ethische Fragen, Datenrichtlinien oder KI-Ethik lassen sich nicht allein mit Prozessen oder Technologie lösen. Es braucht Governance: Leitprinzipien, die auf höchster Ebene der Organisation festgelegt werden. Meist haben Unternehmen bereits Governance, aber sie muss für das kybernetische Modell angepasst werden.\nKernaussagen # Die Zukunft ist kybernetisch, nicht einfach nur KI: Kybernetik bedeutet, dass Menschen und Technologie in geschlossenen Feedback-Loops zusammenarbeiten, um sich kontinuierlich anzupassen Herauszoomen: Die meisten Transformationsmisserfolge passieren, weil Organisationen sich auf einen Teil fokussieren, ohne das Gesamtsystem zu verstehen Fokus heisst Nein sagen: Organisationseinheiten mit klarer Verantwortung schaffen, genau wie Komponenten in der Softwarearchitektur Engineering-Praktiken sind wichtiger denn je: KI beschleunigt die Entwicklung, ersetzt aber nicht die Notwendigkeit solider Architektur, Tests und Systemdesign Klein anfangen, schnell lernen: Transformation mit Pilotteams beginnen, sie schützen, Ergebnisse messen und auf Basis realer Erkenntnisse skalieren Governance ist essenziell: Ethische Richtlinien, Datenrichtlinien und KI-Ethik lassen sich nicht allein durch Technologie oder Prozesse lösen ","date":"12. October 2025","externalUrl":null,"permalink":"/de/blogs/wie-man-eine-zukunftsfaehige-organisation-aufbaut/","section":"Blogs","summary":"In dieser Folge des LeanPub-Podcasts führe ich mit Moderator Len Epp ein ausführliches Gespräch über mein Buch «The Cybernetic Enterprise: How to Build a Future-Ready Organization». Wir sprechen über meinen Werdegang bei Zühlke, darüber, warum die Zukunft kybernetisch ist und nicht einfach nur KI, und über die praktischen Schritte der Unternehmenstransformation. Wenn Sie sich jemals gefragt haben, was es braucht, um eine Organisation aufzubauen, die sich kontinuierlich anpassen kann, deckt dieses Gespräch die wesentlichen Ideen ab.\n","title":"Wie man eine zukunftsfähige Organisation aufbaut","type":"blogs"},{"content":"Original publication: DIGITAL MANUFACTURING\nThe industrial success story is opening its next chapter. Some call it Industry 5.0, although it\u0026rsquo;s more than just an upgrade of Industry 4.0: Here, people, sustainability, and resilience are moving to the center of operations. Artificial intelligence is transforming production facilities, roles, and decision-making processes. Human intuition meets machine precision, merging into hybrid value creation. The entrepreneurial operating model of the future, the \u0026ldquo;Cybernetic Enterprise,\u0026rdquo; shows how this collaboration can work.\nAfter the steam engine, the assembly line, electronics, and digital networking: AI is now making a powerful entry, and industry is taking the next evolutionary step. The drivers that make the reorientation of production and value creation more urgent than ever are obvious. In particular, efficiency and cost pressures, as well as the increasingly difficult differentiation in the market, are forcing a rethink. Demographics and the shortage of skilled workers are also forcing companies to act, because by 2036, around 30 percent of the available workforce in Germany will have reached retirement age.\nAt the same time, geopolitical tensions and increasing supply chain risk are reinforcing the need to position themselves resiliently and thus for the future. Global disruptions already cost industrial companies an average of eight percent of their annual revenue. Stricter ESG regulations require large companies to provide comprehensive sustainability transparency. Combined with rising energy prices, this is increasing the pressure to develop circular production models.\nIt\u0026rsquo;s no coincidence that the EU Commission defines this new industrial phase as \u0026ldquo;human-centric, sustainable, and resilient.\u0026rdquo; The term Industry 5.0 explicitly defines it as an extension of Industry 4.0 logic, not a replacement. This shifts the focus beyond connectivity and automation to the question of how technology can strengthen human creativity, conserve resources, and mitigate disruptions more quickly. Industry 5.0 thus represents the step from smart to adaptive and conscious.\nThe organizational model of the “cybernetic enterprise” connects sensors, OT data, AI agents, and business rules in feedback loops.\nDigital becomes “cybernetic” # Industry in the AI age is based on three technological pillars: AI-supported decision-making, collaborative robotics, and platform-based production models. However, these can only fully realize their potential when they are consistently linked by the principles of a \u0026ldquo;cybernetic enterprise.\u0026rdquo; These include self-organization and learning capability, value stream, feedback and platform orientation, and customer centricity.\nThis means that the organizational model of a \u0026ldquo;Cybernetic Enterprise\u0026rdquo; connects sensors, OT data, AI agents, and business rules in closed feedback loops. Every machine operation generates data, AI interprets it, and the insights flow immediately back into control, scheduling, and even development. This is how digital transformation becomes \u0026ldquo;cybernetic transformation.\u0026rdquo; Why \u0026ldquo;cybernetic\u0026rdquo;? The term cybernetics is derived from the Greek word for \u0026ldquo;helmsman\u0026rdquo; and refers to control, regulation, and communication in complex systems. This makes it ideal for describing models for collaboration between humans and AI.\nMaturity levels of human-machine collaboration # How can humans and artificial intelligence interact in practice? We are in the midst of a development that is gradually taking collaboration to a new level. It starts with assistance. Here, AI supports humans by providing context-based optimization recommendations, for example, in the automatic correction of torque during an assembly process.\nIn the next stage, co-creation, solutions emerge through close interaction between humans and machines, for example, in variant planning, where AI handles analysis and simulations, while humans contribute domain knowledge and experience. The third stage of development is facilitation. Here, AI orchestrates teams, assigns tasks, and prioritizes orders based on production and personnel data. A typical example is shift planning.\nHigh autonomy represents the highest level of maturity. In this scenario, production processes largely regulate themselves, with humans becoming supervisors. For example, self-healing production lines that independently detect and resolve disruptions before downtime occurs.\nOn the way to the self-learning factory # The \u0026ldquo;Cybernetic Transformation\u0026rdquo; toward Industry 5.0 is a journey. In practice, decision-makers should focus on three stages in particular. It begins with a systematic analysis of existing processes to visualize value streams and identify bottlenecks early on. This transparency lays the foundation for targeted AI-based improvements, and their true value contribution.\nIt is also advisable to establish specialized platform teams that automatically provide key technical services, tools, and infrastructure elements. This makes it easier for other teams to work independently, quickly, securely, and scalably with AI products. Only those who work with the appropriate experimentation, testing, and operationalization methods will be able to deploy AI agents robustly and productively. The goal must be the cyclical, continuous feedback that forms the heart of the self-learning organization.\nHow the industry can overcome the challenges # For the AI transformation to succeed, industrial companies must keep a close eye on several technological, organizational and cultural challenges and address them systematically:\nTechnological integration: Brownfield factories, in particular, require pragmatic modernization approaches. Iterative retrofits with sensor kits and Edge AI, which deploy AI models on local devices, gradually make existing plants smarter, prioritized according to the automation backlog and KPIs. Skill gap: Data literacy, prompt engineering, and robot coaching are the new key skills. Extended learning paths and cross-skilling are transforming traditional roles. Mechatronics engineers are becoming cobot supervisors and AI behavioral trainers. Governance and regulation: The EU AI Act and the EU Machinery Regulation, which will come into force in 2027, set the framework for the use of high-risk AI systems. Guardrails as code automate rule enforcement and facilitate audits. Interdisciplinary AI boards are well advised to define internal company guidelines. Cultural change: Leadership shifts from control to empowerment. Teams assume concrete responsibility for key performance indicators, while platform teams support them in the areas of security and compliance. Learning circles and safe-to-fail zones provide psychological security for collaboration. Industry 5.0 as the next stage of industrial value creation # Industry 5.0 is far more than a buzzword. It marks the next logical development stage of industrial value creation. It complements Industry 4.0 with human-centered AI, circular sustainability, and organizational resilience. At its core is the concept of the \u0026ldquo;Cybernetic Enterprise,\u0026rdquo; in which data, algorithms, and people merge into a learning value stream.\nThose who invest early in transparency, platform teams, and closed AI loops create resilient, customer-centric factories that continuously improve themselves, with demonstrable effects: double-digit increases in efficiency, significantly shorter downtimes, and a reduction in the carbon footprint of every manufactured component.\nOriginal article: DIGITAL MANUFACTURING: https://p7f.vogel.de/wcms/68/db/68dba3b16cdf0/digital-manufacturing-magazin-issue-6-2025.pdf\n","date":"8 October 2025","externalUrl":null,"permalink":"/en/blogs/human-machine-cooperation-in-industry-5-0/","section":"Blogs","summary":"Original publication: DIGITAL MANUFACTURING\nThe industrial success story is opening its next chapter. Some call it Industry 5.0, although it’s more than just an upgrade of Industry 4.0: Here, people, sustainability, and resilience are moving to the center of operations. Artificial intelligence is transforming production facilities, roles, and decision-making processes. Human intuition meets machine precision, merging into hybrid value creation. The entrepreneurial operating model of the future, the “Cybernetic Enterprise,” shows how this collaboration can work.\n","title":"Human-machine cooperation in Industry 5.0","type":"blogs"},{"content":"","date":"8. October 2025","externalUrl":null,"permalink":"/de/tags/industrie/","section":"Tags","summary":"","title":"Industrie","type":"tags"},{"content":"Die industrielle Erfolgsgeschichte schlägt das nächste Kapitel auf. Manche nennen es Industrie 5.0, wenngleich es um mehr als ein Upgrade von Industrie 4.0 geht: Hier rücken Mensch, Nachhaltigkeit und Resilienz ins Zentrum des Handelns. Künstliche Intelligenz verändert dabei Produktionsanlagen, Rollen und Entscheidungswege. Menschliche Intuition trifft auf maschinelle Präzision, und verschmilzt zu hybrider Wertschöpfung. Wie diese Zusammenarbeit funktionieren kann, zeigt das unternehmerische Betriebsmodell der Zukunft, das „Cybernetic Enterprise\u0026quot;.\nNach Dampfmaschine, Fließband, Elektronik und digitale Vernetzung: Nun hält die KI mit Macht Einzug und die Industrie geht den nächsten Evolutionsschritt. Die Treiber, die die Neuausrichtung von Produktion und Wertschöpfung dringender denn je machen, liegen dabei auf der Hand. Insbesondere Effizienz- und Kostendruck sowie die immer schwierigere Differenzierung am Markt sorgen für ein Umdenken. Auch Demografie und Fachkräftemangel zwingen Unternehmen zum Handeln, denn bis 2036 werden in Deutschland rund 30 Prozent der verfügbaren Erwerbspersonen das Rentenalter erreicht haben.\nParallel verstärken geopolitische Spannungen und das zunehmende Lieferkettenrisiko die Notwendigkeit, sich resilient und damit zukunftsfähig aufzustellen. Schon heute kosten globale Störungen Industrieunternehmen im Durchschnitt acht Prozent ihres Jahresumsatzes. Eine verschärfte ESG-Regulierung verpflichtet große Unternehmen zu umfassender Nachhaltigkeitstransparenz. In Kombination mit steigenden Energiepreisen wächst so der Druck, kreislauffähige Produktionsmodelle zu gestalten.\nDie EU-Kommission definiert diese neue industrielle Phase also nicht umsonst als „humancentric, sustainable and resilient\u0026quot;. Die Überschrift Industrie 5.0 versteht sie dabei ausdrücklich als Erweiterung der Industrie-4.0-Logik, nicht als Ablösung. Damit rückt neben Vernetzung und Automatisierung die Frage ins Zentrum, wie Technologie menschliche Kreativität stärkt, Ressourcen spart und Störungen schneller abfedert. Industrie 5.0 ist somit der Schritt von smart zu adaptiv und bewusst.\nDas Organisationsmodell des „Cybernetic Enterprise\u0026quot; verbindet Sensorik, OT-Daten, KI-Agenten und Geschäftsregeln in Feedback-Schleifen.\nAus digital wird „cybernetic\u0026quot; # Industrie im KI-Zeitalter basiert auf drei technischen Säulen: KI-gestützte Entscheidungsfindung, kollaborative Robotik und plattformbasierte Produktionsmodelle. Diese können ihr Potenzial allerdings erst dann vollständig entfalten, wenn sie konsequent durch die Prinzipien eines „Cybernetic Enterprise\u0026quot; verknüpft sind. Dazu gehören Selbstorganisation und Lernfähigkeit, Wertstrom-, Feedback- und Plattformorientierung sowie Kundenzentrierung.\nDas heißt: Das Organisationsmodell eines „Cybernetic Enterprise\u0026quot; verbindet Sensorik, OT-Daten, KI-Agenten und Geschäftsregeln in geschlossenen Feedback-Schleifen. Jede Maschinenoperation erzeugt Daten, KI interpretiert sie und die Erkenntnisse fließen sofort zurück in Steuerung, Disposition und sogar Entwicklung. So wird aus der digitalen Transformation die „Cybernetic Transformation\u0026quot;. Warum „cybernetic\u0026quot;? Der Kybernetik-Begriff leitet sich vom griechischen Wort für „Steuermann\u0026quot; ab und bezieht sich auf Steuerung, Regelung und Kommunikation in komplexen Systemen. Damit eignet er sich hervorragend, um Modelle für die Zusammenarbeit zwischen Menschen und KI zu beschreiben.\nReifegrade der Mensch-Maschine-Kollaboration # Wie können Mensch und künstliche Intelligenz in der Praxis interagieren? Wir befinden uns mittendrin in einer Entwicklung, die die Zusammenarbeit Schritt für Schritt auf ein neues Level hebt. Es beginnt mit der Assistenz. Hier unterstützt die KI den Menschen, indem sie kontextbasierte Optimierungsempfehlungen liefert, so zum Beispiel bei der automatischen Korrektur des Drehmoments während eines Montageprozesses.\nIn der nächsten Stufe, der Ko-Kreation, entstehen Lösungen im engen Zusammenspiel von Menschen und Maschine, etwa bei der Variantenplanung, wo die KI Analyse und Simulationen übernimmt und der Mensch Domänenwissen und Erfahrung einbringt. Auf der dritten Entwicklungsstufe steht die Moderation. Die KI orchestriert hier Teams, verteilt Aufgaben und priorisiert Aufträge auf Basis von Produktions- und Personaldaten. Ein typisches Beispiel ist die Schichtplanung.\nDen höchsten Reifegrad hat die Hochautonomie. In diesem Szenario regulieren sich Produktionsprozesse weitgehend selbst, der Mensch wird zum Supervisor. Beispiel: Self-Healing-Produktionslinien, die Störungen eigenständig erkennen und beheben, bevor es zu Stillständen kommt.\nAuf dem Weg zur selbstlernenden Fabrik # Die „Cybernetic Transformation\u0026quot; hin zur Industrie 5.0 ist eine Reise. In der Praxis sollten Entscheider ihr Augenmerk insbesondere auf drei Etappen legen. Am Anfang steht eine systematische Analyse der bestehenden Prozesse, um Wertströme sichtbar zu machen und Engpässe frühzeitig zu identifizieren. Diese Transparenz schafft die Grundlage für gezielte KI-basierte Verbesserungen, und ihren tatsächlichen Wertbeitrag.\nEs empfiehlt sich zudem, spezialisierte Plattformteams aufzubauen, die zentrale technische Services, Tools und Infrastrukturelemente automatisiert bereitstellen. Das erleichtert anderen Teams das eigenständige, schnelle, sichere und skalierbare Arbeiten mit KI-Produkten. Nur wer mit den passenden Experimentier-, Test- und Operationalisierungs-Methoden arbeitet, wird KI-Agenten robust produktiv setzen können. Ziel muss dabei die zyklische, kontinuierliche Rückkopplung sein, die das Herzstück der selbstlernenden Organisation bildet.\nWie die Industrie die Herausforderungen meistern kann # Damit die KI-Transformation gelingt, müssen Industriebetriebe einige technologische, organisatorische und kulturelle Herausforderungen im Blick haben und diese systematisch adressieren:\nTechnologische Integration: Gerade „Brownfield\u0026quot;-Fabriken benötigen pragmatische Modernisierungsansätze. Iterative Retrofits mit Sensor-Kits und Edge-KI, die KI-Modelle auf lokalen Endgeräten bereitstellen, machen die Bestandsanlagen schrittweise smart, priorisiert nach Automatisierungs-Backlog und entlang von KPIs.\nSkill-Gap: Datenkompetenz, Prompt-Engineering und Roboter-Coaching sind die neuen Schlüsselqualifikationen. Erweiterte Lernpfade und Cross-Skilling verändern klassische Rollen. Hierbei werden Mechatroniker zu Cobot-Supervisoren und KI-Verhaltenstrainern.\nGovernance und Regulierung: Der EU AI Act und die ab 2027 geltende EU-Maschinenverordnung setzen den Rahmen für den Einsatz von „High Risk AI Systems\u0026quot;. Guardrails as Code automatisieren die Regeldurchsetzung und erleichtern Audits. Interdisziplinäre AI Boards tun gut daran, unternehmensinterne Leitplanken zu definieren.\nKulturwandel: Führung verschiebt sich von der Kontrolle zum Empowerment. Teams übernehmen konkret Verantwortung für Kennzahlen, während Plattform-Teams ihnen in den Bereichen Security und Compliance den Rücken freihalten. Learning Circles und Safe-to-Fail-Zonen sichern die Zusammenarbeit psychologisch ab.\nIndustrie 5.0 als nächste Stufe industrieller Wertschöpfung # Industrie 5.0 ist weit mehr als ein Buzzword. Sie markiert die nächste logische Entwicklungsstufe industrieller Wertschöpfung. Dabei ergänzt sie Industrie 4.0 um menschzentrierte KI, zirkuläre Nachhaltigkeit und organisatorische Resilienz. Im Mittelpunkt steht das Konzept des „Cybernetic Enterprise\u0026quot;, in dem Daten, Algorithmen und Menschen zu einem lernenden Wertstrom verschmelzen.\nWer frühzeitig in Transparenz, Plattform-Teams und geschlossene KI-Schleifen investiert, schafft resiliente, kundenzentrierte Fabriken, die sich kontinuierlich selbst verbessern, mit nachweisbaren Effekten: zweistellige Effektivitätszuwächse, signifikant kürzere Stillstandszeiten und eine Reduktion des CO2-Fußabdrucks bei jedem gefertigtem Bauteil.\nOriginal Artikel: DIGITAL MANUFACTURING: https://p7f.vogel.de/wcms/68/db/68dba3b16cdf0/digital-manufacturing-magazin-ausgabe-6-2025.pdf\n","date":"8. October 2025","externalUrl":null,"permalink":"/de/blogs/mensch-maschine-kooperation-in-industrie-5-0/","section":"Blogs","summary":"Die industrielle Erfolgsgeschichte schlägt das nächste Kapitel auf. Manche nennen es Industrie 5.0, wenngleich es um mehr als ein Upgrade von Industrie 4.0 geht: Hier rücken Mensch, Nachhaltigkeit und Resilienz ins Zentrum des Handelns. Künstliche Intelligenz verändert dabei Produktionsanlagen, Rollen und Entscheidungswege. Menschliche Intuition trifft auf maschinelle Präzision, und verschmilzt zu hybrider Wertschöpfung. Wie diese Zusammenarbeit funktionieren kann, zeigt das unternehmerische Betriebsmodell der Zukunft, das „Cybernetic Enterprise\".\n","title":"Kooperation von Mensch und Maschine in der Industrie 5.0","type":"blogs"},{"content":"Original Publikation: DIGITAL MANUFACTURING\nDie industrielle Erfolgsgeschichte schlägt das nächste Kapitel auf. Manche nennen es Industrie 5.0, wenngleich es um mehr als ein Upgrade von Industrie 4.0 geht: Hier rücken Mensch, Nachhaltigkeit und Resilienz ins Zentrum des Handelns. Künstliche Intelligenz verändert dabei Produktionsanlagen, Rollen und Entscheidungswege. Menschliche Intuition trifft auf maschinelle Präzision, und verschmilzt zu hybrider Wertschöpfung. Wie diese Zusammenarbeit funktionieren kann, zeigt das unternehmerische Betriebsmodell der Zukunft, das „Cybernetic Enterprise”.\nNach Dampfmaschine, Fließband, Elektronik und digitale Vernetzung: Nun hält die KI mit Macht Einzug und die Industrie geht den nächsten Evolutionsschritt. Die Treiber, die die Neuausrichtung von Produktion und Wertschöpfung dringender denn je machen, liegen dabei auf der Hand. Insbesondere Effizienz- und Kostendruck sowie die immer schwierigere Differenzierung am Markt sorgen für ein Umdenken. Auch Demografie und Fachkräftemangel zwingen Unternehmen zum Handeln, denn bis 2036 werden in Deutschland rund 30 Prozent der verfügbaren Erwerbspersonen das Rentenalter erreicht haben.\nParallel verstärken geopolitische Spannungen und das zunehmende Lieferkettenrisiko die Notwendigkeit, sich resilient und damit zukunftsfähig aufzustellen. Schon heute kosten globale Störungen Industrieunternehmen im Durchschnitt acht Prozent ihres Jahresumsatzes. Eine verschärfte ESG-Regulierung verpflichtet große Unternehmen zu umfassender Nachhaltigkeitstransparenz. In Kombination mit steigenden Energiepreisen wächst so der Druck, kreislauffähige Produktionsmodelle zu gestalten.\nDie EU-Kommission definiert diese neue industrielle Phase also nicht umsonst als „humancentric, sustainable and resilient“. Die Überschrift Industrie 5.0 versteht sie dabei ausdrücklich als Erweiterung der Industrie-4.0-Logik, nicht als Ablösung. Damit rückt neben Vernetzung und Automatisierung die Frage ins Zentrum, wie Technologie menschliche Kreativität stärkt, Ressourcen spart und Störungen schneller abfedert. Industrie 5.0 ist somit der Schritt von smart zu adaptiv und bewusst.\nDAS ORGANISATIONSMODELL DES „CYBERNETIC ENTERPRISE“ VERBINDET SENSORIK, OT-DATEN, KI-AGENTEN UND GESCHÄFTSREGELN IN FEEDBACK-SCHLEIFEN.\nAus digital wird „cybernetic“ # Industrie im KI-Zeitalter basiert auf drei technischen Säulen: KI-gestützte Entscheidungsfindung, kollaborative Robotik und plattformbasierte Produktionsmodelle. Diese können ihr Potenzial allerdings erst dann vollständig entfalten, wenn sie konsequent durch die Prinzipien eines „Cybernetic Enterprise“ verknüpft sind. Dazu gehören Selbstorganisation und Lernfähigkeit, Wertstrom-, Feedback- und Plattformorientierung sowie Kundenzentrierung.\nDas heißt: Das Organisationsmodell eines „Cybernetic Enterprise“ verbindet Sensorik, OT-Daten, KI-Agenten und Geschäftsregeln in geschlossenen FeedbackSchleifen. Jede Maschinenoperation erzeugt Daten, KI interpretiert sie und die Erkenntnisse fließen sofort zurück in Steuerung, Disposition und sogar Entwicklung. So wird aus der digitalen Transformation die „Cybernetic Transformation“. Warum „cybernetic“? Der Kybernetik-Begriff leitet sich vom griechischen Wort für „Steuermann“ ab und bezieht sich auf Steuerung, Regelung und Kommunikation in komplexen Systemen. Damit eignet er sich hervorragend, um Modelle für die Zusammenarbeit zwischen Menschen und KI zu beschreiben.\nReifegrade der Mensch-Maschine-Kollaboration # Wie können Mensch und künstliche Intelligenz in der Praxis interagieren? Wir befinden uns mittendrin in einer Entwicklung, die die Zusammenarbeit Schritt für Schritt auf ein neues Level hebt. Es beginnt mit der Assistenz. Hier unterstützt die KI den Menschen, indem sie kontextbasierte Optimierungsempfehlungen liefert, so zum Beispiel bei der automatischen Korrektur des Drehmoments während eines Montageprozesses.\nIn der nächsten Stufe, der Ko-Kreation, entstehen Lösungen im engen Zusammenspiel von Menschen und Maschine, etwa bei der Variantenplanung, wo die KI Analyse und Simulationen übernimmt und der Mensch Domänenwissen und Erfahrung einbringt. Auf der dritten Entwicklungsstufe steht die Moderation. Die KI orchestriert hier Teams, verteilt Aufgaben und priorisiert Aufträge auf Basis von Produktions- und Personaldaten. Ein typisches Beispiel ist die Schichtplanung.\nDen höchsten Reifegrad hat die Hochautonomie. In diesem Szenario regulieren sich Produktionsprozesse weitgehend selbst, der Mensch wird zum Supervisor. Beispiel: Self-Healing-Produktionslinien, die Störungen eigenständig erkennen und beheben, bevor es zu Stillständen kommt\nAuf dem Weg zur selbstlernenden Fabrik # Die „Cybernetic Transformation“ hin zur Industrie 5.0 ist eine Reise. In der Praxis sollten Entscheider ihr Augenmerk insbesondere auf drei Etappen legen. Am Anfang steht eine systematische Analyse der bestehenden Prozesse, um Wertströme sichtbar zu machen und Engpässe frühzeitig zu identifizieren. Diese Transparenz schafft die Grundlage für gezielte KI-basierte Verbesserungen, und ihren tatsächlichen Wertbeitrag.\nEs empfiehlt sich zudem, spezialisierte Plattformteams aufzubauen, die zentrale technische Services, Tools und Infrastrukturelemente automatisiert bereitstellen. Das erleichtert anderen Teams das eigenständige, schnelle, sichere und skalierbare Arbeiten mit KI-Produkten. Nur wer mit den passenden Experimentier-, Test- und Operationalisierungs-Methoden arbeitet, wird KI-Agenten robust produktiv setzen können. Ziel muss dabei die zyklische, kontinuierliche Rückkopplung sein, die das Herzstück der selbstlernenden Organisation bildet.\nWie die Industrie die Herausforderungen meistern kann # Damit die KI-Transformation gelingt, müssen Industriebetriebe einige technologische, organisatorische und kulturelle Herausforderungen im Blick haben und diese systematisch adressieren:\nTechnologische Integration: Gerade „Brownfield“-Fabriken benötigen pragmatische Modernisierungsansätze. Iterative Retrofits mit Sensor-Kits und EdgeKI, die KI-Modelle auf lokalen Endgeräten bereitstellen, machen die Bestandsanlagen schrittweise smart, priorisiert nach Automatisierungs-Backlog und entlang von KPIs. Skill-Gap: Datenkompetenz, PromptEngineering und Roboter-Coaching sind die neuen Schlüsselqualifikationen. Erweiterte Lernpfade und Cross-Skilling verändern klassische Rollen. Hierbei werden Mechatroniker zu Cobot-Supervisoren und KI-Verhaltenstrainern. Governance und Regulierung: Der EU AI Act und die ab 2027 geltende EU-Maschinenverordnung setzen den Rahmen für den Einsatz von „High Risk AI Systems“. Guardrails as Code automatisieren die Regeldurchsetzung und erleichtern Audits. Interdisziplinäre AI Boards tun gut daran, unternehmensinterne Leitplanken zu definieren. Kulturwandel: Führung verschiebt sich von der Kontrolle zum Empowerment. Teams übernehmen konkret Verantwortung für Kennzahlen, während Plattform-Teams ihnen in den Bereichen Security und Compliance den Rücken freihalten. Learning Circles und Safe-to-Fail-Zonen sichern die Zusammenarbeit psychologisch ab. Industrie 5.0 als nächste Stufe industrieller Wertschöpfung # Industrie 5.0 ist weit mehr als ein Buzzword. Sie markiert die nächste logische Entwicklungsstufe industrieller Wertschöpfung. Dabei ergänzt sie Industrie 4.0 um menschzentrierte KI, zirkuläre Nachhaltigkeit und organisatorische Resilienz. Im Mittelpunkt steht das Konzept des „Cybernetic Enterprise“, in dem Daten, Algorithmen und Menschen zu einem lernenden Wertstrom verschmelzen.\nWer frühzeitig in Transparenz, PlattformTeams und geschlossene KI-Schleifen investiert, schafft resiliente, kundenzentrierte Fabriken, die sich kontinuierlich selbst verbessern, mit nachweisbaren Effekten: zweistellige Effektivitätszuwächse, signifikant kürzere Stillstandszeiten und eine Reduktion des CO2-Fußabdrucks bei jedem gefertigtem Bauteil.\nOriginal Artikel: DIGITAL MANUFACTURING: https://p7f.vogel.de/wcms/68/db/68dba3b16cdf0/digital-manufacturing-magazin-ausgabe-6-2025.pdf\n","date":"8. October 2025","externalUrl":null,"permalink":"/de/blogs/kooperation-vonmensch-und-maschinein-der-industrie-5-0/","section":"Blogs","summary":"Original Publikation: DIGITAL MANUFACTURING\nDie industrielle Erfolgsgeschichte schlägt das nächste Kapitel auf. Manche nennen es Industrie 5.0, wenngleich es um mehr als ein Upgrade von Industrie 4.0 geht: Hier rücken Mensch, Nachhaltigkeit und Resilienz ins Zentrum des Handelns. Künstliche Intelligenz verändert dabei Produktionsanlagen, Rollen und Entscheidungswege. Menschliche Intuition trifft auf maschinelle Präzision, und verschmilzt zu hybrider Wertschöpfung. Wie diese Zusammenarbeit funktionieren kann, zeigt das unternehmerische Betriebsmodell der Zukunft, das „Cybernetic Enterprise”.\n","title":"Kooperation vonMensch und Maschinein der Industrie 5.0","type":"blogs"},{"content":"","date":"7 September 2025","externalUrl":null,"permalink":"/en/tags/future-of-work/","section":"Tags","summary":"","title":"Future of Work","type":"tags"},{"content":"I recently joined the Digital Analog Podcast to talk about what it really means when humans and machines work together. As the Chief of Cybernetic Transformation and Partner at Zühlke, I deal with these questions every day. In this conversation, we covered everything from the biggest obstacles in digital transformation to why AI agents could change the way we collaborate, and why simplicity should be every organization\u0026rsquo;s guiding principle.\nWhat is Cybernetic Transformation? # The term \u0026ldquo;cybernetic\u0026rdquo; was coined in the 1940s, long before AI became a buzzword. At its core, cybernetics describes how humans and machines collaborate in a constant feedback loop, learning and improving continuously. This is exactly what I see as the future of organizations.\nMy role at Zühlke is to help companies design their processes, organization, and technology foundations so they can continuously deliver value. That is cybernetic transformation in practice. The term is not widely known, which has its downsides, but also an advantage: it sparks curiosity and invites good conversations.\nThe Biggest Obstacles Are Not Technical # When I am asked about the biggest challenges in digital transformation, my answer surprises many people: the problems are rarely technical. Yes, there are legacy applications and outdated technology landscapes, but these can be solved with the right resources and investment.\nProcess challenges are also solvable. Over time, processes get ingrained and need to be adapted to new technical possibilities. That is manageable.\nThe really tough problems are organizational. Companies have built hierarchies and silos that made perfect sense in the past. Each business unit focused on its specialty and did it well. But now, as organizations need to accelerate, these silos block the flow of value across unit boundaries. The value stream runs through multiple business units but keeps getting interrupted.\nThe biggest obstacle is middle management. Not because they are doing something wrong, but because they are in an identity crisis. There is real fear of job loss, loss of purpose, and loss of the organization they built and were proud of. With that fear comes resistance, and overcoming that resistance is the toughest challenge in most organizations.\nValue Stream Mapping: A 1940s Tool for Today\u0026rsquo;s AI Challenges # One of the most effective techniques I use with clients comes from the Toyota Production System of the 1940s: value stream mapping. You analyze the entire stream from start to finish, identify each step, measure it, and suddenly the whole team, including management, can see exactly where the problems are.\nVisualization is a powerful instrument. Instead of having a diffuse feeling that something is not working, you have a concrete map that shows where the bottlenecks, handoffs, and waiting times are.\nThis becomes especially interesting with AI. When companies come to me saying \u0026ldquo;we want to use AI,\u0026rdquo; I always say: let us first analyze your value stream. Based on that analysis, we can see where AI actually adds value. And here is the critical insight: AI is not deterministic. Every time you run it, you get a slightly different result. So if you need exact, repeatable outcomes, classical automation is the better tool. AI is the right choice where you can tolerate some variance and where the creative, pattern-matching capabilities shine.\nAI Accuracy: The 60-95% Rule # From our project experience, a consistent pattern emerges. Without any optimization, AI output is correct about 60% of the time. With proper prompt engineering and testing, you can push that to about 95%. But getting beyond 95% becomes extremely expensive and time-consuming.\nI shared a concrete example from a project with an insurance company. They had many insurance policies and support staff who could not memorize them all. We built a RAG system (Retrieval Augmented Generation) as a chatbot on top of all policies. The interesting benchmark was that their own employees were wrong about 5% of the time. That became our target, and we reached it. But pushing beyond that proved very difficult.\nIt is fascinating: we often talk about AI accuracy, but we forget that humans are not 100% accurate either.\nAI Agents: The Next Frontier # One topic that truly excites me is AI agents. I compare them to having a personal assistant who is specialized in specific tasks. In the future, your Outlook assistant might negotiate meeting times with my Outlook assistant. They will find a slot, book it, and we will simply meet in Zürich without even knowing exactly how it happened.\nThis is where the collaboration between humans and machines becomes very real. As a manager, you might no longer have human employees for certain tasks. Instead, you might orchestrate 100 agents, checking in on their progress and providing feedback. The roles will change, but the work will not disappear.\nWe Keep Getting More Efficient, But Where Does the Time Go? # I always find it fascinating to look back. When I studied, researching a topic meant going to the library, working through the card catalog, spending hours finding the right books. Today we can search online, read papers instantly, even have AI summarize entire books for us.\nAnd yet, nobody seems to have more time. That is the paradox. We can now build more complex programs with less code, but instead of needing fewer programmers, we need more, because we tackle ever more complex problems. The same pattern repeats with every technology leap, from assembly to C++, from Java to AI-assisted coding.\nWe have always gotten more efficient, but we use that efficiency to tackle ever more complex challenges. The time savings never arrive.\nSimplicity Wins # One of my strongest convictions is that we need to simplify. We can build increasingly complex things, but truly mastering that complexity is extremely hard. I see more and more organizations that need to go back to basics: simpler processes, simpler organizational structures, simpler solutions.\nApple internalized this perfectly: if something is simple, make it even simpler. The breakthrough comes from simple solutions, not complex ones. The same applies to AI business cases. If the use case is too complex, people will not understand it, the market will not adopt it, and it will fail.\nWhen I give talks, I always ask the audience: \u0026ldquo;Has it gotten simpler?\u0026rdquo; Most people say no. But I argue it has gotten simpler for the user. Behind the scenes, the complexity is enormous. The key is to make things as simple as possible for the people who use them, and do it with enthusiasm.\nThe Technology Behind AI: Not Magic, Just Science # AI often feels like magic, but when you understand how neural networks work, how data is collected and used for training, how reinforcement learning functions, and how parameters are tuned, you realize there is not that much magic involved. The fascinating part is what it can do with those foundations.\nI can confirm from my own teaching at the Lucerne University of Applied Sciences that I have been programming neural networks for years. What changed is not the fundamental technology. It is the amount of data available and the processing power to work with it. That is what made the current breakthroughs possible.\nKey Takeaways # Cybernetic transformation is about humans and machines working together in constant feedback loops, a concept from the 1940s that is more relevant than ever. The biggest obstacles to digital transformation are organizational, not technical. Middle management resistance, driven by real fears, is the toughest challenge. Value stream mapping is a simple, decades-old technique that helps organizations see where AI and automation actually create value. AI accuracy typically starts at 60% and can be pushed to 95% with good engineering. Getting beyond that is extremely expensive. AI agents will change how we collaborate, acting as specialized assistants that negotiate and coordinate on our behalf. Simplicity wins. The organizations that succeed will be the ones that simplify their processes, structures, and solutions instead of adding more complexity. Do it with enthusiasm. As I always say, whatever you do, do it with passion and excitement. ","date":"7 September 2025","externalUrl":null,"permalink":"/en/blogs/humans-machines-future-of-work-ai/","section":"Blogs","summary":"I recently joined the Digital Analog Podcast to talk about what it really means when humans and machines work together. As the Chief of Cybernetic Transformation and Partner at Zühlke, I deal with these questions every day. In this conversation, we covered everything from the biggest obstacles in digital transformation to why AI agents could change the way we collaborate, and why simplicity should be every organization’s guiding principle.\n","title":"Humans + Machines: The Future of Work \u0026 AI","type":"blogs"},{"content":"Kürzlich war ich zu Gast beim Digital Analog Podcast, um darüber zu sprechen, was es wirklich bedeutet, wenn Mensch und Maschine zusammenarbeiten. Als Chief of Cybernetic Transformation und Partner bei Zühlke beschäftige ich mich täglich mit diesen Fragen. Im Gespräch haben wir alles abgedeckt: von den grössten Hindernissen bei der digitalen Transformation über die Frage, wie KI-Agenten die Zusammenarbeit verändern könnten, bis hin zur Erkenntnis, warum Einfachheit das Leitprinzip jeder Organisation sein sollte.\nWas ist Cybernetic Transformation? # Der Begriff «Cybernetic» wurde in den 1940er-Jahren geprägt, lange bevor KI zum Modewort wurde. Im Kern beschreibt Kybernetik, wie Menschen und Maschinen in einer ständigen Feedback-Schleife zusammenarbeiten, kontinuierlich lernen und sich verbessern. Genau das sehe ich als die Zukunft von Organisationen.\nMeine Aufgabe bei Zühlke ist es, Unternehmen dabei zu begleiten, ihre Prozesse, Organisation und technologischen Fundamente so zu gestalten, dass sie kontinuierlich Wert liefern können. Das ist Cybernetic Transformation in der Praxis. Der Begriff ist nicht weit verbreitet, was Nachteile hat, aber auch einen Vorteil: Er weckt Neugier und führt zu guten Gesprächen.\nDie grössten Hindernisse sind nicht technischer Natur # Wenn ich nach den grössten Herausforderungen bei der digitalen Transformation gefragt werde, überrascht meine Antwort viele: Die Probleme sind selten technisch. Ja, es gibt Legacy-Applikationen und veraltete Technologielandschaften, aber diese lassen sich mit den richtigen Ressourcen und Investitionen lösen.\nAuch Prozessproblem sind lösbar. Im Laufe der Zeit haben sich Prozesse eingeschliffen und müssen an neue technische Möglichkeiten angepasst werden. Das ist machbar.\nDie wirklich schwierigen Probleme sind organisatorischer Natur. Unternehmen haben Hierarchien und Silos aufgebaut, die in der Vergangenheit absolut Sinn ergeben haben. Jede Business Unit hat sich auf ihre Spezialität fokussiert und diese gut beherrscht. Aber jetzt, da Organisationen beschleunigen müssen, blockieren diese Silos den Wertfluss über die Grenzen der Business Units hinweg. Der Wertstrom verläuft durch mehrere Units, wird aber immer wieder unterbrochen.\nDas grösste Hindernis ist das Mittelmanagement. Nicht weil sie etwas falsch machen, sondern weil sie in einer Identitätskrise stecken. Es gibt echte Ängste vor Jobverlust, vor dem Verlust der Aufgabe und der Organisation, die man aufgebaut hat und auf die man stolz war. Mit dieser Angst kommt Widerstand, und diesen Widerstand zu überwinden ist die härteste Herausforderung in den meisten Organisationen.\nValue Stream Mapping: Ein Werkzeug aus den 1940ern für heutige KI-Herausforderungen # Eine der wirksamsten Techniken, die ich bei Kunden einsetze, stammt aus dem Toyota Production System der 1940er-Jahre: das Value Stream Mapping. Man analysiert den gesamten Strom von Anfang bis Ende, identifiziert jeden Schritt, misst ihn, und plötzlich kann das gesamte Team, einschliesslich des Managements, genau sehen, wo die Probleme liegen.\nVisualisierung ist ein kraftvolles Instrument. Statt eines diffusen Gefühls, dass etwas nicht funktioniert, hat man eine konkrete Landkarte, die zeigt, wo die Engpässe, Übergaben und Wartezeiten sind.\nDas wird besonders interessant mit KI. Wenn Unternehmen zu mir kommen und sagen «wir möchten KI einsetzen», sage ich immer: Lasst uns zuerst den Wertstrom analysieren. Auf Basis dieser Analyse können wir sehen, wo KI tatsächlich Wert schafft. Und hier kommt die entscheidende Erkenntnis: KI ist nicht deterministisch. Jedes Mal, wenn man sie ausführt, erhält man ein leicht anderes Ergebnis. Wenn man also exakte, wiederholbare Ergebnisse braucht, ist klassische Automatisierung das bessere Werkzeug. KI ist die richtige Wahl, wo Varianz tolerierbar ist und die kreativen Pattern-Matching-Fähigkeiten glänzen.\nKI-Genauigkeit: Die 60-95%-Regel # Aus unserer Projekterfahrung zeigt sich ein konsistentes Muster. Ohne Optimierung ist der KI-Output zu etwa 60% korrekt. Mit gutem Prompt Engineering und Testing lässt sich das auf etwa 95% steigern. Jenseits von 95% wird es extrem teuer und zeitaufwändig.\nIch habe ein konkretes Beispiel aus einem Projekt mit einer Versicherung geteilt. Die hatten viele Versicherungspolicen und Supportmitarbeiter, die nicht alles im Kopf haben konnten. Wir haben ein RAG-System (Retrieval Augmented Generation) als Chatbot über alle Policen gebaut. Die interessante Benchmark war, dass die eigenen Mitarbeiter in 5% der Fälle falsch lagen. Das wurde unser Zielwert, den wir auch erreicht haben. Darüber hinauszukommen erwies sich jedoch als sehr schwierig.\nEs ist faszinierend: Wir sprechen oft über die Genauigkeit von KI, vergessen aber, dass auch Menschen nicht zu 100% genau sind.\nKI-Agenten: Die nächste Stufe # Ein Thema, das mich wirklich begeistert, sind KI-Agenten. Ich vergleiche sie mit einem persönlichen Assistenten, der auf bestimmte Aufgaben spezialisiert ist. In Zukunft wird vielleicht mein Outlook-Assistent Terminzeiten mit deinem Outlook-Assistenten aushandeln. Sie finden einen Slot, buchen ihn, und wir treffen uns einfach in Zürich, ohne genau zu wissen, wie das zustande gekommen ist.\nHier wird die Zusammenarbeit zwischen Mensch und Maschine sehr real. Als Führungskraft hat man vielleicht für bestimmte Aufgaben keine menschlichen Mitarbeitenden mehr. Stattdessen orchestriert man 100 Agenten, prüft deren Fortschritt und gibt Feedback. Die Rollen werden sich ändern, aber die Arbeit wird nicht verschwinden.\nWir werden immer effizienter, aber wo bleibt die Zeit? # Ich finde es immer faszinierend, zurückzublicken. Als ich studiert habe, bedeutete ein Thema zu recherchieren, in die Bibliothek zu gehen, den Kartenkatalog durchzuarbeiten und Stunden mit der Suche nach den richtigen Büchern zu verbringen. Heute können wir online suchen, Aufsätze sofort lesen, sogar ganze Bücher von KI zusammenfassen lassen.\nUnd trotzdem hat niemand mehr Zeit. Das ist das Paradox. Wir können jetzt komplexere Programme mit weniger Code schreiben, aber statt weniger Programmierer zu brauchen, brauchen wir mehr, weil wir immer komplexere Probleme angehen. Das gleiche Muster wiederholt sich mit jedem Technologiesprung: von Assembler zu C++, von Java zu KI-gestützter Programmierung.\nWir sind immer effizienter geworden, aber wir nutzen diese Effizienz, um immer komplexere Herausforderungen anzugehen. Die Zeitersparnis kommt nie an.\nEinfachheit gewinnt # Eine meiner stärksten Überzeugungen ist, dass wir vereinfachen müssen. Wir können immer komplexere Dinge bauen, aber diese Komplexität wirklich zu beherrschen ist extrem schwierig. Ich sehe immer mehr Organisationen, die zurück zu den Grundlagen müssen: einfachere Prozesse, einfachere Organisationsstrukturen, einfachere Lösungen.\nApple hat das perfekt verinnerlicht: Wenn etwas einfach ist, mach es noch einfacher. Der Durchbruch kommt von einfachen Lösungen, nicht von komplexen. Das gilt auch für KI-Business-Cases. Wenn der Anwendungsfall zu komplex ist, werden ihn die Menschen nicht verstehen, der Markt wird ihn nicht annehmen, und er wird scheitern.\nWenn ich Vorträge halte, frage ich das Publikum immer: «Ist es einfacher geworden?» Die meisten sagen nein. Aber ich argumentiere, dass es für den Nutzer einfacher geworden ist. Im Hintergrund ist die Komplexität enorm. Der Schlüssel ist, die Dinge so einfach wie möglich zu machen für die Menschen, die sie nutzen, und das mit Begeisterung zu tun.\nDie Technologie hinter KI: Keine Magie, sondern Wissenschaft # KI fühlt sich oft wie Magie an. Aber wenn man versteht, wie neuronale Netzwerke funktionieren, wie Daten gesammelt und für das Training verwendet werden, wie Reinforcement Learning funktioniert und wie Parameter angepasst werden, merkt man, dass gar nicht so viel Magie im Spiel ist. Das Faszinierende ist, was damit möglich wird.\nIch kann aus meiner eigenen Lehrtätigkeit an der Hochschule Luzern bestätigen, dass ich schon seit Jahren neuronale Netze programmiere. Was sich geändert hat, ist nicht die grundlegende Technologie. Es sind die verfügbare Datenmenge und die Rechenleistung. Das hat die aktuellen Durchbrüche ermöglicht.\nKernaussagen # Cybernetic Transformation bedeutet, dass Menschen und Maschinen in ständigen Feedback-Schleifen zusammenarbeiten. Ein Konzept aus den 1940er-Jahren, das relevanter ist denn je. Die grössten Hindernisse der digitalen Transformation sind organisatorischer, nicht technischer Natur. Der Widerstand im Mittelmanagement, getrieben von realen Ängsten, ist die härteste Herausforderung. Value Stream Mapping ist eine einfache, jahrzehntealte Technik, die Organisationen hilft zu sehen, wo KI und Automatisierung wirklich Wert schaffen. Die KI-Genauigkeit startet typisch bei 60% und kann mit gutem Engineering auf 95% gesteigert werden. Darüber hinauszukommen ist extrem teuer. KI-Agenten werden die Art unserer Zusammenarbeit verändern, als spezialisierte Assistenten, die in unserem Auftrag verhandeln und koordinieren. Einfachheit gewinnt. Die Organisationen, die erfolgreich sein werden, sind jene, die ihre Prozesse, Strukturen und Lösungen vereinfachen, statt noch mehr Komplexität hinzuzufügen. Mit Begeisterung machen. Was immer man tut, mit Leidenschaft und Begeisterung tun. ","date":"7. September 2025","externalUrl":null,"permalink":"/de/blogs/mensch-maschine-zukunft-der-arbeit-ki/","section":"Blogs","summary":"Kürzlich war ich zu Gast beim Digital Analog Podcast, um darüber zu sprechen, was es wirklich bedeutet, wenn Mensch und Maschine zusammenarbeiten. Als Chief of Cybernetic Transformation und Partner bei Zühlke beschäftige ich mich täglich mit diesen Fragen. Im Gespräch haben wir alles abgedeckt: von den grössten Hindernissen bei der digitalen Transformation über die Frage, wie KI-Agenten die Zusammenarbeit verändern könnten, bis hin zur Erkenntnis, warum Einfachheit das Leitprinzip jeder Organisation sein sollte.\n","title":"Mensch + Maschine: Die Zukunft der Arbeit \u0026 KI","type":"blogs"},{"content":"","date":"7 September 2025","externalUrl":null,"permalink":"/en/tags/podcast/","section":"Tags","summary":"","title":"Podcast","type":"tags"},{"content":"","date":"7. September 2025","externalUrl":null,"permalink":"/de/tags/zukunft-der-arbeit/","section":"Tags","summary":"","title":"Zukunft Der Arbeit","type":"tags"},{"content":"Kennen Sie das Gefühl, wenn das eigene Unternehmen einfach langsam wirkt? Immer hinterher, immer am Stocken, nicht gebaut für die moderne Welt? Was, wenn das nicht nur ein Gefühl ist? Was, wenn Ihre Organisation buchstäblich auf einem veralteten Betriebssystem läuft? In diesem Video erkunden wir das Konzept des Cybernetic Enterprise und warum es ein fundamentales Upgrade für die Funktionsweise von Unternehmen darstellt.\nDie Transformationsfalle # Fast jedes Unternehmen hat irgendeine Form der digitalen Transformation durchlaufen. Es werden Millionen ausgegeben, Berater eingeflogen und die neuesten Buzzwords ausgerollt. Aber bei vielen verschwinden die tiefgreifenden, fundamentalen Probleme nie wirklich. Sie stecken fest in der sogenannten Transformationsfalle.\nDie Zahlen sind ernüchternd. Rund 70% dieser teuren Transformationsprojekte liefern nicht, was sie versprochen haben. Billionen werden ausgegeben, doch die realen Ergebnisse bleiben oft aus. Was läuft schief?\nDas Kernproblem: Seit Jahren kleben wir Pflaster auf das Problem. Wir behandeln Symptome. Agile, DevOps, SAFe. Das sind gute Werkzeuge, aber sie wurden oft auf ein System aufgesetzt, das von Grund auf kaputt war. Das Ergebnis? Backlogs, die nur grösser werden. Umständliche \u0026ldquo;Water-Scrumfall\u0026rdquo;-Hybridprozesse. Klassische Silos zwischen Business und IT. Langsame Top-Down-Entscheidungen und zerbrochene Feedback Loops.\nIhre Organisation läuft auf einem Betriebssystem # Hier die zentrale Erkenntnis: Genau wie Ihr Laptop läuft Ihre gesamte Organisation auf einem Betriebssystem. Es ist das zugrundeliegende Set an Regeln, Strukturen und Protokollen, das bestimmt, wie alles zusammenwirkt. Das Problem: Bei den meisten Unternehmen wurde dieses Betriebssystem für ein Industriezeitalter entworfen, das nicht mehr existiert. Es ist überholt. Es ist Zeit für ein grundlegendes Upgrade.\nDieses Upgrade ist das Cybernetic Enterprise. Im Kern ist es ein Bauplan für eine Organisation, die von Grund auf darauf ausgelegt ist, zu lernen und sich anzupassen. Das Wort \u0026ldquo;kybernetisch\u0026rdquo; dreht sich um Feedback Loops: ein System, das darauf ausgelegt ist, ständig wahrzunehmen, was passiert, diese Informationen zu verarbeiten und den Kurs in Echtzeit anzupassen.\nDer Wandel ist in jeder Kategorie dramatisch. Von starren, isolierten Abteilungen zu kleinen, autonomen, crossfunktionalen Teams. Von starren Top-Down-Fünfjahresplänen zu adaptiver, feedbackgetriebener Navigation. Vom Produzieren vorhersagbarer Outputs hin zu kontinuierlichem Lernen.\nPrinzip 1: Outcomes statt Output # Das erste Kernprinzip ist ein massiver Fokuswechsel. Hören Sie auf zu messen, wie beschäftigt Sie sind, und fangen Sie an zu messen, welchen Impact Sie tatsächlich haben. Wechseln Sie von Output (Features ausliefern, Tickets schliessen) zu Outcomes (echter, greifbarer Wert für Kunden und das Unternehmen).\nEs ist so einfach, Aktivität mit Fortschritt zu verwechseln. Aber hundert neue Features auszuliefern, die niemand nutzt, ist kein Erfolg. Das ist teurer Lärm. Echter Wert wird vom Nutzer definiert, nicht vom Velocity Chart des Teams.\nPrinzip 2: Vertrauen statt Command and Control # Das zweite Prinzip betrifft die Kultur. Weg vom altmodischen Command and Control, hin zu einem Modell, das auf Vertrauen aufgebaut ist. Ermächtigen Sie Ihre Leute. Geben Sie ihnen den Kontext und die Autonomie, die sie brauchen, um Probleme zu lösen, statt jedes Detail zu mikromanagen.\n\u0026ldquo;Good process serves you so you can serve customers. But if you\u0026rsquo;re not watchful, the process can become the thing.\u0026rdquo; (Jeff Bezos)\nWir alle kennen das. Wenn das Ausfüllen des Formulars wichtiger wird als dem Kunden zu helfen. Eine Kultur, die auf Vertrauen aufgebaut ist, versteht, dass die Menschen, die der Arbeit am nächsten sind, meist am besten wissen, wie man es löst, und räumt ihnen den Weg frei.\nPrinzip 3: KI-augmentiert, nicht KI-gesteuert # Das dritte Prinzip bringt Technologie ins Spiel, aber die Formulierung ist entscheidend: KI-augmentiert, nicht KI-gesteuert. Das Ziel ist nicht, Menschen zu ersetzen. Es geht darum, Menschen klüger, schneller und effektiver zu machen, indem KI in die Art und Weise verwoben wird, wie Arbeit erledigt wird.\nStellen Sie sich KI als Co-Piloten für alle in der Organisation vor. Sie hilft, Muster zu erkennen, die wir vielleicht übersehen, automatisiert mühsame Analysen und beschleunigt Feedback Loops. Es geht nicht darum, ein separates AI Center of Excellence im Elfenbeinturm aufzubauen. Es geht darum, KI zu einer Kernfähigkeit für alle zu machen, damit die gesamte Organisation schneller lernt.\nDie Cybernetic Platform # Prinzipien brauchen einen Motor, um real zu werden. Dieser Motor ist die Cybernetic Platform: das technische und prozessuale Rückgrat, das alle diese Ideen zum Leben erweckt. Es ist ein integriertes Set aus Tools und automatisierten Pfaden, das es Teams einfach macht, das Richtige zu tun, und schwer, das Falsche zu tun.\nDie Plattform bietet Paved Paths für Teams. Statt dass jedes Team Security, Deployment oder Monitoring von Grund auf neu erfindet, stellt die Plattform standardisierte, automatisierte Self-Service-Lösungen bereit. Das reduziert die kognitive Last dramatisch, verankert Best Practices von Anfang an und ermöglicht es autonomen Teams, extrem schnell zu arbeiten, ohne versehentlich Dinge kaputt zu machen.\nDie Organisation als lernender Organismus # Wenn man diese Prinzipien mit dem Plattform-Motor kombiniert, passiert etwas Bemerkenswertes. Die Organisation hört auf, wie eine starre, langsame Maschine zu agieren, und beginnt sich wie ein lebendiger, lernender Organismus zu verhalten.\nIn einer Welt des ständigen Wandels und der Disruption werden die Gewinner nicht die grössten Unternehmen sein oder die mit den meisten Ressourcen. Die Gewinner werden jene Organisationen sein, die schneller lernen und sich anpassen können, als sich die Welt um sie herum verändert. Das Cybernetic Enterprise ist ein Betriebssystem, das genau dafür designt ist.\nKernaussagen # Das Betriebssystem Ihrer Organisation ist veraltet. Die meisten Unternehmen laufen auf Strukturen, die für ein Industriezeitalter entworfen wurden. Pflaster wie isolierte Agile- oder DevOps-Einführungen können ein fundamental kaputtes System nicht reparieren. 70% der digitalen Transformationen scheitern. Symptome zu behandeln statt das zugrundeliegende Betriebsmodell zu upgraden, führt zu verschwendeten Ressourcen und anhaltenden Dysfunktionen. Outcomes statt Output. Hören Sie auf, ausgelieferte Features zu zählen, und beginnen Sie, echten Kundenwert zu messen. Vertrauen statt Command and Control. Ermächtigen Sie die Menschen, die der Arbeit am nächsten sind. Prozesse sollten den Zielen dienen, nicht zum Selbstzweck werden. KI-augmentierte Intelligenz. KI ist ein Co-Pilot, der alle klüger macht, kein Ersatz für menschliches Urteilsvermögen. Die Cybernetic Platform ist der Motor. Paved Paths, Self-Service-Tools und automatisierte Best Practices machen es Teams einfach, schnell das Richtige zu tun. Die Zukunft gehört lernenden Organisationen. Die Gewinner werden jene sein, die schneller lernen und sich anpassen, als sich ihr Umfeld verändert. ","date":"30. August 2025","externalUrl":null,"permalink":"/de/blogs/das-betriebssystem-ihres-unternehmens-ist-veraltet-cybernetic-enterprise/","section":"Blogs","summary":"Kennen Sie das Gefühl, wenn das eigene Unternehmen einfach langsam wirkt? Immer hinterher, immer am Stocken, nicht gebaut für die moderne Welt? Was, wenn das nicht nur ein Gefühl ist? Was, wenn Ihre Organisation buchstäblich auf einem veralteten Betriebssystem läuft? In diesem Video erkunden wir das Konzept des Cybernetic Enterprise und warum es ein fundamentales Upgrade für die Funktionsweise von Unternehmen darstellt.\n","title":"Das Betriebssystem Ihres Unternehmens ist veraltet: Das Upgrade zum Cybernetic Enterprise","type":"blogs"},{"content":"","date":"30. August 2025","externalUrl":null,"permalink":"/de/tags/organisationsdesign/","section":"Tags","summary":"","title":"Organisationsdesign","type":"tags"},{"content":"","date":"30 August 2025","externalUrl":null,"permalink":"/en/tags/organizational-design/","section":"Tags","summary":"","title":"Organizational Design","type":"tags"},{"content":"Die digitale Landschaft fühlt sich heute weniger wie ein stabiler Weg an und mehr wie Wildwasser-Stromschnellen. Ständiger Wandel, neue Technologien und unerbittlicher Anpassungsdruck. In diesem Deep Dive erkunden zwei Hosts mein Buch \u0026ldquo;Cybernetic Enterprise V1.0.0\u0026rdquo; und packen aus, warum traditionelle digitale Transformationen immer wieder scheitern, und wie die Alternative aussieht: ein ganzheitliches neues Betriebsmodell, bei dem Anpassungsfähigkeit zum Standardzustand der Organisation wird.\nWarum traditionelle Ansätze immer wieder scheitern # Die Zahlen sind ernüchternd. Rund 70% der digitalen Transformationen liefern nicht die erwarteten Ergebnisse. Noch erschreckender: Ein Hackeroon-Report von 2018 stellte fest, dass 96% der agilen Einführungen die organisatorische Anpassungsfähigkeit nicht tatsächlich verbessert haben. Das sind fast alle.\nWas läuft also schief? Viele vergangene Bemühungen haben einfach versucht, veraltete Strukturen zu digitalisieren. Sie replizieren bestehende Silos, falsch ausgerichtete Anreize, starre Hierarchien und zerbrochene Feedback Loops, nur mit neuen Tools. Diese traditionellen Ansätze heilen nicht die systemischen Dysfunktionen. Sie legen nur eine digitale Fassade über alte analoge Probleme.\nDer grösste Fehler, den Organisationen machen: Transformation als Projekt zu behandeln, etwas mit Start- und Enddatum. Statt sie als fortlaufende Evolution des gesamten Betriebsmodells zu begreifen.\nDas Cybernetic Enterprise: Eine lebendige Organisation # Was unterscheidet das Cybernetic Enterprise von anderen Modellen? Es wird nicht nur als Sammlung von Praktiken definiert, sondern als lebendige, kontinuierlich adaptive Organisation. Es operiert durch geschlossene Feedback Loops, in denen Informationen ständig zurückfliessen, um Handlungen zu informieren. Es wird augmentiert durch KI und angetrieben von autonomen, crossfunktionalen Teams.\nDer Name selbst stammt von der Kybernetik, der Wissenschaft der Systemsteuerung und Rückkopplung, erstmals eingeführt von Norbert Wiener in den 1940er Jahren. Die Anwendung fühlt sich also hochmodern an, aber die zugrundeliegenden Prinzipien haben eine reiche Geschichte.\nDie Schlüsselmerkmale: Es fördert aktiv Innovation gegenüber vorhersagbaren, starren Plänen, bevorzugt Experimentieren als primäre Entdeckungsmethode und behandelt Feedback nicht als etwas, das gefürchtet werden muss, sondern als essenziellen Treibstoff für kontinuierliches Wachstum.\nPrinzipien statt starre Prozesse # Ein tiefgreifender Wandel im kybernetischen Ansatz ist die Betonung von Prinzipien gegenüber starren Prozessen. Das bedeutet nicht, Best Practices aufzugeben, sondern anzuerkennen, dass in einer sich schnell verändernden Welt die heutige Best Practice schnell zur veralteten Praxis von morgen werden kann. Die eigentliche Erkenntnis: Lernen ist die ultimative Best Practice.\n\u0026ldquo;Good process serves you so you can serve customers. But if you\u0026rsquo;re not watchful, the process can become the thing.\u0026rdquo; (Jeff Bezos)\n\u0026ldquo;The system is that there is no system. That doesn\u0026rsquo;t mean we don\u0026rsquo;t have process, but that\u0026rsquo;s not what it\u0026rsquo;s about.\u0026rdquo; (Steve Jobs)\nPraktisch bedeutet das: eine Coaching-Kultur kultivieren, Individuen ermächtigen, Entscheidungen näher am Kunden zu treffen, und sicherstellen, dass Prozesse immer den Zielen dienen.\nKI-augmentiert, nicht KI-ersetzt # Das Buch macht eine sehr bewusste Unterscheidung: KI-augmentierte Intelligenz, nicht KI-ersetzt oder KI-gesteuert. Menschen und KI arbeiten zusammen, jeder macht das, was er am besten kann. KI verbessert die Qualität und Geschwindigkeit von Entscheidungen. Man denke an Supply Chains, die Inventar optimieren, Softwareteams, die Code und Testfälle automatisch generieren, oder HR-Teams, die KI nutzen, um Mitarbeiterentwicklungspfade zu personalisieren. Aber Menschen behalten die Kontrolle über die kritischen Beurteilungen, die ethischen Abwägungen, die finalen kreativen Sprünge.\nIm Cybernetic Enterprise ist KI kein Zusatz, der in einem Center of Excellence abgelegt wird. Sie ist ein zentraler, allgegenwärtiger Teil der organisatorischen DNA, eingebettet in Plattform und Prozesse, um Lernen und Handeln für alle zu beschleunigen. Man kann es sich als internes \u0026ldquo;AI as a Service\u0026rdquo; vorstellen, das Teams ermöglicht, KI-Capabilities einfach in ihre Produkte und Workflows einzubinden.\nOutcomes statt Output # Statt zu feiern, wie viele Features ausgeliefert wurden, lautet die Frage: Haben diese Features tatsächlich die Kundenzufriedenheit verbessert? Haben sie die Abwanderung reduziert? Es ist ein Wechsel vom Abhaken einer Liste zur Überprüfung, ob sich das Leben des Kunden tatsächlich verbessert hat.\nDer schwierigste Teil dieses Wandels ist die eingeschliffene Gewohnheit, Aktivität mit Fortschritt gleichzusetzen, und der Komfort leicht quantifizierbarer Output-Metriken.\n\u0026ldquo;Wenn Ihre Entscheidungen nicht auf Erkenntnissen basieren, basieren sie auf Ego.\u0026rdquo;\nErfolg bedeutet nicht, eine hohe Anzahl von Features auszuliefern. Es bedeutet, echten Wert zu liefern: bedeutungsvolle Outcomes, die Kundenprobleme adressieren und Geschäftswert schaffen.\nLernen statt Scheitern # Das Buch rahmt Scheitern nicht als negatives Ende, sondern als Chance für Entdeckung und Lernen. Das setzt Geschwindigkeit und Innovation frei, weil Teams nicht von der Angst gelähmt werden, etwas falsch zu machen. Sie können kalkulierte Risiken eingehen durch Experimente wie Minimum Viable Products (MVPs), die gezielt darauf ausgelegt sind, Klarheit über Nutzerbedürfnisse und Verhaltensweisen zu schaffen.\nNehmen wir Minecraft: Das ursprüngliche MVP entstand nach nur sechs Tagen Programmierung und entwickelte sich dann massiv basierend auf frühem Nutzerfeedback. Oder Lego, bekannt für schnelles Prototyping mit Kindern, bei dem neue Ideen schnell in Kinderhände gelegt werden, um zu sehen, was Anklang findet. Das Ziel ist nicht Perfektion beim ersten Versuch. Es ist, schnell und kostengünstig handlungsfähiges Wissen zu gewinnen.\nDie Cybernetic Platform: Paved Paths # Das praktische Fundament, das dieses neue Betriebssystem antreibt, ist die Cybernetic Platform. Sie bietet \u0026ldquo;Paved Paths\u0026rdquo; für die Entwicklung: vorab genehmigte Infrastruktur-Templates, standardisierte CI/CD-Pipelines und Referenzarchitekturen, denen Teams einfach folgen können.\nDiese Paved Paths gehen über Geschwindigkeit hinaus. Sie reduzieren die kognitive Last radikal, indem sie Routineaufgaben standardisieren und Entwickler für kreatives Problemlösen freistellen. Sie verankern Compliance und Security von Anfang an. Spotifys \u0026ldquo;Golden Paths\u0026rdquo; sind ein bekanntes Beispiel dieses Ansatzes.\nEine globale Bank, die im Buch erwähnt wird, erstellte \u0026ldquo;Compliance as Code\u0026rdquo;-Regeln und kodifizierte komplexe regulatorische Richtlinien in Template-Umgebungen. Das befreite Entwickler von Bergen manueller Papierarbeit. Die Plattform wirkt als Coach und Sicherheitsnetz zugleich: Sie führt Teams, bewahrt ihre Autonomie, fängt aber potenzielle Probleme früh ab.\nDer CEO als Chief Evangelist # Die Transformation verlangt unerschütterliches Commitment von ganz oben. Die Rolle des CEO ist entscheidend: Er oder sie muss der primäre Fürsprecher sein, der Chief Evangelist für die neue Vision, der aktiv Widerstände adressiert und Anreize über die gesamte Organisation hinweg ausrichtet. Ohne Buy-in von der Spitze und konsistente Kommunikation ist es extrem schwierig, eingefahrene Praktiken zu durchbrechen.\nDiese Reise verlangt echten unternehmerischen Mut. Führungskräfte müssen bereit sein, tief verankerte Praktiken in Frage zu stellen, Unsicherheit zu akzeptieren und mutige, manchmal unbequeme, kalkulierte Risiken einzugehen.\nKernaussagen # 70% der digitalen Transformationen scheitern, weil sie Transformation als Projekt statt als fortlaufende Evolution des Betriebsmodells behandeln. 96% der agilen Einführungen verbesserten die Anpassungsfähigkeit nicht. Veraltete Strukturen zu digitalisieren, legt nur eine digitale Fassade über analoge Probleme. Das Cybernetic Enterprise ist eine lebendige, adaptive Organisation, die durch geschlossene Feedback Loops operiert, augmentiert durch KI und angetrieben von autonomen Teams. Prinzipien statt Prozesse. Lernen ist die ultimative Best Practice. Die heutige Best Practice kann zur Einschränkung von morgen werden. KI-augmentiert, nicht KI-gesteuert. Menschen und KI arbeiten zusammen, wobei KI als Kernfähigkeit eingebettet ist, nicht als isolierter Zusatz. Outcomes statt Output. Echten Kundenwert messen, nicht Features zählen. Entscheidungen basierend auf Erkenntnissen, nicht auf Ego. Lernen statt Scheitern. Experimente und MVPs setzen Geschwindigkeit und Innovation frei, indem Scheitern als Entdeckung gerahmt wird. Die Cybernetic Platform bietet Paved Paths, die kognitive Last reduzieren, Compliance verankern und Teams ermöglichen, schnell und sicher zu arbeiten. CEO-Commitment ist nicht verhandelbar. Die Transformation muss von der Spitze mit Mut und Konsequenz geführt werden. ","date":"30. August 2025","externalUrl":null,"permalink":"/de/blogs/warum-digitale-transformationen-scheitern-cybernetic-enterprise-buch/","section":"Blogs","summary":"Die digitale Landschaft fühlt sich heute weniger wie ein stabiler Weg an und mehr wie Wildwasser-Stromschnellen. Ständiger Wandel, neue Technologien und unerbittlicher Anpassungsdruck. In diesem Deep Dive erkunden zwei Hosts mein Buch “Cybernetic Enterprise V1.0.0” und packen aus, warum traditionelle digitale Transformationen immer wieder scheitern, und wie die Alternative aussieht: ein ganzheitliches neues Betriebsmodell, bei dem Anpassungsfähigkeit zum Standardzustand der Organisation wird.\n","title":"Warum 70% der digitalen Transformationen scheitern: Ein Blick ins Buch Cybernetic Enterprise","type":"blogs"},{"content":"The digital landscape today feels less like a steady path and more like white water rapids. Constant change, new technologies, and relentless pressure to adapt. In this deep dive, two hosts explore my book \u0026ldquo;Cybernetic Enterprise V1.0.0\u0026rdquo; and unpack why traditional digital transformations keep failing, and what the alternative looks like: a holistic new operating model where adaptability becomes the organization\u0026rsquo;s default state.\nWhy Traditional Approaches Keep Failing # The statistics are sobering. Around 70% of digital transformations fail to deliver their expected results. Even more startling: a 2018 Hackeroon report found that 96% of agile adoptions did not actually improve organizational adaptability. That is almost all of them.\nSo what is going wrong? Many past efforts have simply tried to digitize outdated structures. They replicate existing silos, misaligned incentives, rigid hierarchies, and broken feedback loops, just using new tools. As the hosts put it: putting lipstick on a pig. These traditional approaches fail to cure the systemic dysfunctions. They just put a digital veneer on old analog problems.\nThe biggest mistake organizations make is treating transformation like a project: something with a start and an end date. Instead of seeing it as an ongoing evolution of the entire operating model.\nThe Cybernetic Enterprise: A Living Organization # What sets the Cybernetic Enterprise apart from other models? It is defined not just as a set of practices, but as a living, continuously adaptive organization. It operates through closed feedback loops, where information constantly cycles back to inform action. It is augmented by AI and powered by autonomous cross-functional teams.\nThe name itself comes from cybernetics, the science of systems control and feedback, first introduced by Norbert Wiener in the 1940s. So while the application feels very cutting-edge, the underlying principles have a rich history.\nThe key characteristics: it actively champions innovation over predictable rigid plans, favors experimentation as its primary way of discovery, and treats feedback not as something to be feared but as the essential fuel for continuous growth.\nPrinciples Over Rigid Processes # A profound shift in the cybernetic approach is the emphasis on principles over rigid processes. This does not mean abandoning best practices, but recognizing that in a rapidly changing world, today\u0026rsquo;s best practice can quickly become tomorrow\u0026rsquo;s outdated practice. The real insight: learning is the ultimate best practice.\n\u0026ldquo;Good process serves you so you can serve customers. But if you\u0026rsquo;re not watchful, the process can become the thing.\u0026rdquo; (Jeff Bezos)\n\u0026ldquo;The system is that there is no system. That doesn\u0026rsquo;t mean we don\u0026rsquo;t have process, but that\u0026rsquo;s not what it\u0026rsquo;s about.\u0026rdquo; (Steve Jobs)\nPractically, this means cultivating a culture of coaching, empowering individuals to make decisions closer to the customer, and making sure processes always serve the goals.\nAI-Augmented, Not AI-Replaced # The book makes a very deliberate distinction: AI-augmented intelligence, not AI-replaced or AI-driven. Humans and AI work together, each doing what they do best. AI enhances the quality and speed of decisions. Think about supply chains optimizing inventory, software teams generating code and test cases automatically, or HR teams using it to help personalize employee growth paths. But humans remain in control of the critical judgments, the ethical considerations, the final creative leaps.\nIn a Cybernetic Enterprise, AI is not an add-on stuck in some center of excellence. It is a core ambient part of the organizational DNA, embedded in the platform and processes to accelerate learning and action for everyone. Think of it as internal AI as a service, letting teams easily plug AI capabilities into their products and workflows.\nOutcomes Over Output # Instead of celebrating how many features you shipped, the question becomes: did those features actually move the needle on customer satisfaction? Did they reduce churn? It is a shift from checking items off a list to verifying that the customer\u0026rsquo;s life genuinely improved.\nThe hardest part of this shift is the ingrained habit of equating activity with progress and the comfort of easily quantifiable output metrics.\n\u0026ldquo;If your decisions aren\u0026rsquo;t powered by insights, they\u0026rsquo;re powered by ego.\u0026rdquo;\nSuccess is not about shipping a high volume of features. It is about delivering real value, meaningful outcomes that address customer problems and drive business value.\nLearning Over Failure # The book reframes failure not as a negative endpoint but as an opportunity for discovery and learning. This unlocks speed and innovation because teams are not paralyzed by the fear of getting it wrong. They can take calculated risks through experiments like minimum viable products (MVPs), designed specifically to provide clarity about user needs and behaviors.\nConsider Minecraft: its original MVP emerged after just six days of coding, then evolved massively based on early user feedback. Or Lego, known for rapid prototyping with children, quickly putting new ideas into kids\u0026rsquo; hands to see what resonates. The goal is not perfection the first time. It is gaining actionable knowledge quickly and affordably.\nThe Cybernetic Platform: Paved Paths # The practical foundation that powers this new operating system is the cybernetic platform. It provides what I call \u0026ldquo;paved paths\u0026rdquo; for development: pre-approved infrastructure templates, standardized CI/CD pipelines, and reference architectures that teams can easily follow.\nThese paved paths go beyond speed. They radically reduce cognitive load by standardizing routine tasks, freeing developers to focus on creative problem-solving. They bake in compliance and security by default. Spotify\u0026rsquo;s \u0026ldquo;golden paths\u0026rdquo; are a well-known example of this approach.\nA global bank mentioned in the book created \u0026ldquo;compliance as code\u0026rdquo; rules, codifying complex regulatory guidelines into template environments. This freed developers from mountains of manual paperwork. The platform acts as both a coach and a safety net: it guides teams, maintains their autonomy, but catches potential issues early.\nCEO as Chief Evangelist # The transformation demands unwavering commitment from the very top. The CEO\u0026rsquo;s role is pivotal: they must be the primary advocate, the chief evangelist for the new vision, actively addressing resistance and aligning incentives across the entire organization. Without top-level buy-in and consistent messaging, it is incredibly difficult to break through entrenched practices.\nThis journey demands real corporate courage. Leaders have to be willing to challenge deeply embedded practices, embrace uncertainty, and make bold, sometimes uncomfortable, calculated risks.\nKey Takeaways # 70% of digital transformations fail because they treat transformation as a project rather than an ongoing evolution of the operating model. 96% of agile adoptions did not improve adaptability. Digitizing outdated structures just puts a digital veneer on analog problems. The Cybernetic Enterprise is a living, adaptive organization that operates through closed feedback loops, augmented by AI and powered by autonomous teams. Principles over processes. Learning is the ultimate best practice. Today\u0026rsquo;s best practice can become tomorrow\u0026rsquo;s constraint. AI-augmented, not AI-driven. Humans and AI work together, with AI embedded as a core capability, not an isolated add-on. Outcomes over output. Measure real customer value, not feature count. Decisions powered by insights, not ego. Learning over failure. Experiments and MVPs unlock speed and innovation by reframing failure as discovery. The cybernetic platform provides paved paths that reduce cognitive load, bake in compliance, and enable teams to move fast and safely. CEO commitment is non-negotiable. The transformation must be led from the top with courage and consistency. ","date":"30 August 2025","externalUrl":null,"permalink":"/en/blogs/why-digital-transformations-fail-cybernetic-enterprise-book/","section":"Blogs","summary":"The digital landscape today feels less like a steady path and more like white water rapids. Constant change, new technologies, and relentless pressure to adapt. In this deep dive, two hosts explore my book “Cybernetic Enterprise V1.0.0” and unpack why traditional digital transformations keep failing, and what the alternative looks like: a holistic new operating model where adaptability becomes the organization’s default state.\n","title":"Why 70% of Digital Transformations Fail: Inside the Cybernetic Enterprise Book","type":"blogs"},{"content":"You know that feeling when your company just feels slow? Always lagging, always crashing, not built for the modern world? What if that is not just a feeling? What if your organization is literally running on an outdated operating system? In this video, we explore the concept of the Cybernetic Enterprise and why it represents a fundamental upgrade for how businesses operate.\nThe Transformation Trap # Almost every company has gone through some kind of digital transformation. They spend millions, bring in consultants, and roll out the latest buzzwords. But for many, the deep fundamental problems never really go away. They get stuck in what you might call the transformation trap.\nThe numbers are brutal. Around 70% of these massive, expensive transformation projects fail to deliver what they promised. Trillions of dollars spent, yet the real-world results are often nowhere to be found. What is going on?\nThe core problem: for years, we have been putting band-aids on the issue. We have been treating symptoms. Agile, DevOps, SAFe. These are great tools, but they have often been applied on top of a system that was fundamentally broken to begin with. The result? Backlogs that only ever get bigger. Clunky \u0026ldquo;water-scrumfall\u0026rdquo; hybrid processes. Classic silos between business and IT. Slow top-down decisions and shattered feedback loops.\nYour Organization Runs on an OS # Here is the key insight: just like your laptop, your entire organization runs on an operating system. It is the underlying set of rules, structures, and protocols that dictates how everything works together. The problem is that for most companies, that OS was designed for an industrial age that no longer exists. It is obsolete. It is time for a major upgrade.\nThat upgrade is the Cybernetic Enterprise. At its heart, it is a blueprint for an organization that is built from the ground up to learn and adapt. The word \u0026ldquo;cybernetic\u0026rdquo; is all about feedback loops: a system designed to constantly sense what is happening, process that information, and adjust its course in real time.\nThe shift is dramatic in every category. From rigid siloed departments to small autonomous cross-functional teams. From rigid top-down five-year plans to adaptive feedback-driven navigation. From cranking out predictable output to achieving continuous learning.\nPrinciple 1: Outcomes Over Output # The first core principle is a massive shift in focus. Stop measuring how busy you are and start measuring the impact you are actually having. Move from output (shipping features, closing tickets) to outcomes (real tangible value delivered to customers and the business).\nIt is so easy to confuse activity with progress. But shipping a hundred new features that nobody uses is not success. It is expensive noise. Real value is defined by the user, not by your team\u0026rsquo;s velocity chart.\nPrinciple 2: Trust Over Command and Control # The second principle is about culture. Move away from old-school command and control to a model built on trust. Empower your people. Give them the context and the autonomy they need to solve problems instead of trying to micromanage every detail.\n\u0026ldquo;Good process serves you so you can serve customers. But if you\u0026rsquo;re not watchful, the process can become the thing.\u0026rdquo; (Jeff Bezos)\nWe have all been there. When filling out the form becomes more important than helping the customer. A culture built on trust understands that the people closest to the work usually know how to solve it best, and it gets out of their way.\nPrinciple 3: AI-Augmented, Not AI-Driven # The third principle brings in technology, but the wording matters: AI-augmented, not AI-driven. The goal is not to replace humans. It is to make humans smarter, faster, and more effective by weaving AI into the fabric of how work gets done.\nThink of AI as a co-pilot for everyone in the organization. It helps spot patterns we might miss, automates tedious analysis, and accelerates feedback loops. This is not about setting up a separate AI center of excellence in an ivory tower. It is about making AI a core capability for everyone, helping the whole organization learn faster.\nThe Cybernetic Platform # Principles need an engine to make them real. That engine is the cybernetic platform: the technical and process backbone that brings all these ideas to life. It is an integrated set of tools and automated pathways that makes it easy for teams to do the right thing and hard to do the wrong thing.\nThe platform provides paved paths for teams. Instead of every team figuring out security, deployment, or monitoring from scratch, the platform gives them standardized, automated, self-service solutions. This dramatically reduces cognitive load, bakes in best practices from the start, and lets autonomous teams move incredibly fast without accidentally breaking things.\nThe Organization as a Learning Organism # When you combine these principles with the platform engine, something remarkable happens. Your organization stops acting like a rigid, slow-moving machine and starts to behave more like a living, learning organism.\nIn a world of constant change and disruption, the winners will not be the biggest companies or even the ones with the most resources. The winners will be the organizations that can learn and adapt faster than the world is changing around them. The Cybernetic Enterprise is an operating system designed to do exactly that.\nKey Takeaways # Your organization\u0026rsquo;s operating system is outdated. Most companies run on structures designed for an industrial age. Band-aids like isolated agile or DevOps adoptions cannot fix a fundamentally broken system. 70% of digital transformations fail. Treating symptoms instead of upgrading the underlying operating model leads to wasted resources and persistent dysfunction. Outcomes over output. Stop measuring features shipped and start measuring real customer value delivered. Trust over command and control. Empower people closest to the work. Process should serve the goals, not become the goal. AI-augmented intelligence. AI is a co-pilot that makes everyone smarter, not a replacement for human judgment. The cybernetic platform is the engine. Paved paths, self-service tools, and automated best practices make it easy for teams to do the right thing at speed. The future belongs to learning organizations. The winners will be those who learn and adapt faster than their environment changes. ","date":"30 August 2025","externalUrl":null,"permalink":"/en/blogs/your-companys-operating-system-is-broken-cybernetic-enterprise/","section":"Blogs","summary":"You know that feeling when your company just feels slow? Always lagging, always crashing, not built for the modern world? What if that is not just a feeling? What if your organization is literally running on an outdated operating system? In this video, we explore the concept of the Cybernetic Enterprise and why it represents a fundamental upgrade for how businesses operate.\n","title":"Your Company's Operating System Is Broken: The Cybernetic Enterprise Upgrade","type":"blogs"},{"content":"Sie hat Prozesse automatisiert, Technologie optimiert und in den letzten zwei Jahrzehnten für viel Veränderungsdynamik gesorgt: die Digitalisierung. Doch in einer Welt, in der künstliche Intelligenz (KI) zum permanenten Sparringspartner avanciert, stößt sie an ihre Grenzen. Denn sie bleibt oft bei Einzeloptimierungen stehen und adressiert nicht die systemischen Herausforderungen. Was Unternehmen nun brauchen, ist ein gedankliches Upgrade auf ein neues „Betriebssystem\u0026quot;. Kontinuierlich lernend, konsequent von Daten getrieben und kompromisslos kundenzentriert muss die Organisation der Zukunft sein. Der Weg dorthin ist eine strategische Reise. Die „Cybernetic Transformation\u0026quot; beginnt jetzt.\n„More of the same\u0026quot;: führt direkt ins Aus # Unternehmen stehen heute mehr denn je unter Druck. Veraltete IT-Landschaften, unkoordinierte Technologieinitiativen, zunehmender Mangel an Fachkräften sowie wachsende Kundenerwartungen und viele weitere externe Anforderungen machen ihnen das Leben schwer. Die klassische Reaktion: Es wird dort weiter digital optimiert, wo es gerade wehtut, seien es Systeme, Prozesse, Teams, Tools oder Kennzahlen. Doch diese isolierten Bemühungen wirken oft wie ein Schmerzmittel: Sie lindern oder beseitigen bestenfalls Symptome und können manches Mal nicht den Kollaps verhindern.\nEs wird Zeit, Transformation so zu gestalten, dass sie die systemischen Ursachen heilt. Der Kybernetik-Begriff, der sich vom griechischen Wort für „Steuermann\u0026quot; ableitet und Rückkopplung sowie zirkuläre Prozesse beschreibt, führt hier auf eine neue Spur. Die KI ist der Beschleuniger, der die digitale Transformation zur „Cybernetic Transformation\u0026quot; macht. Diese nächste Evolutionsstufe begreift das Innerste eines Unternehmens als lebendiges System, das sich selbst weiterentwickeln kann, auf Basis von Daten, Feedbackschleifen und Lernkurven. Dabei steht nicht länger die Effizienz im Zentrum. Es geht vielmehr darum, eine lern- und anpassungsfähige Organisation zu etablieren, in der Technologie, Prozesse und Struktur in einem intelligenten Dreiklang nahtlos zusammenspielen.\nWie tickt die „Cybernetic Enterprise\u0026quot;? # Das neue Zielbild heißt „Cybernetic Enterprise\u0026quot;. Die KI-Funktionalitäten ähneln in dieser Organisationsform nicht umsonst dem menschlichen Nervensystem: Sensorik in Produkten, Telemetrie in Prozessen und Sentiment-Analysen bei Kunden erspüren, was passiert, und speisen Daten kontinuierlich in Feedbackschleifen ein. KI-Agenten treffen auf dieser Basis Routineentscheidungen. Menschen kuratieren Signale und bewerten Kontexte.\nIm Ergebnis entsteht so eine Organisation, in der die KI nicht länger Tool ist, sondern zum „Kollegen der anderen Art\u0026quot; wird. Das macht es unabdingbar, gemischte Mensch-Maschine-Teams für neue Formen der Zusammenarbeit zu befähigen. Plattformen ersetzen Tool-Wildwuchs. Und Outcome kommt vor Output. Das heißt: Die tatsächliche Wirkung oder Veränderung zählt.\nVier Kernelemente # Wertstromorientiert, feedbackgetrieben, plattformbasiert, kundenzentriert: Die „Cybernetic Enterprise\u0026quot; basiert auf nachvollziehbaren Prinzipien, die Organisationen im KI-Zeitalter ganzheitlich transformieren.\nIntelligente Automatisierung entlang des gesamten Wertstroms: Statt einzelne Abläufe zu digitalisieren, verfolgt das Wertstromkonzept eine Automatisierung über alle Phasen eines Geschäftsprozesses hinweg, End-to-End, von der Idee bis zur Auslieferung an den Kunden.\nSelbstlernende Systeme mit Closed-Loop-Feedback: KI-Systeme lernen nicht nur einmal, sondern fortlaufend, basierend auf Echtzeitdaten und dynamischen Rückkopplungsschleifen. So entsteht ein kontinuierlicher Verbesserungsprozess, der sich selbst reguliert und weiterentwickelt.\nPlatform Engineering als „Enabler\u0026quot; für Selfservice und Governance as Code: Moderne Plattformen ermöglichen es Teams, schnell, sicher und eigenverantwortlich zu arbeiten. Eine automatisierte Richtlinienprüfung sorgt dafür, dass Compliance und Governance nicht bremsen, sondern integrierter Bestandteil des Entwicklungsprozesses sind.\nKundenzentrierte Innovation durch Rapid Prototyping und Experimentation Frameworks: Wer neue Ideen frühzeitig von echten Usern testen lässt und kontrollierte Experimente durchführt, validiert Entscheidungen, minimiert Risiken, beschleunigt Lernprozesse und erhöht die Wahrscheinlichkeit, Innovationen erfolgreich am Markt zu skalieren.\nWas bringt\u0026rsquo;s konkret? # Die „Cybernetic Enterprise\u0026quot; erzielt messbare Vorteile. Erfahrungswerte aus zahlreichen Transformationsprojekten zeigen: Die wichtigsten strategischen Hebel sind Kundenzufriedenheit, Innovationsgeschwindigkeit, Systemstabilität und -resilienz sowie Skalierbarkeit. Die erzielten Verbesserungen können sich sehen lassen.\nDer Bauplan für die lernende Organisation # Was gehört ins Fundament einer „Cybernetic Enterprise\u0026quot;?\nDas sind die wichtigsten Bausteine:\nDaten- und Feedbackarchitektur: Lernen funktioniert nicht ohne Echtzeitbeobachtung. Es gilt, ein unternehmensweites Datennetzwerk aufzubauen, das alle relevanten Datenquellen zugänglich macht und intelligent verknüpft. Außerdem lautet die Maßgabe: „Telemetrie everywhere\u0026quot;. Datenströme sollten durchgängig fließen, von der Maschine bis ins Management Dashboard. So wird die Organisation „datenfühlig\u0026quot;: sie erkennt Muster, reagiert situativ und optimiert kontinuierlich.\nStrategische Einbettung der KI: Künstliche Intelligenz entfaltet ihr volles Potenzial nur dort, wo sie gezielt eingesetzt wird, entlang klarer Geschäftsziele. Deshalb braucht es die Priorisierung strategisch relevanter Use Cases mit klarem Business Outcome, die interne Akzeptanz schaffen. Darüber hinaus ist ein systematisches Model Lifecycle Management erforderlich, idealerweise auf Basis von Machine Learning Operations (MLOps), um KI-Modelle kontinuierlich zu überwachen, zu aktualisieren und regulatorisch abzusichern. Damit KI nicht zum Innovationsstrohfeuer wird. Ein KI-Modell ist ja kein Einmalprodukt. Es verändert sich mit Daten, Umfeld und Anforderungen.\nPlatform Engineering und DevOps: Platform Engineering ist ein moderner IT-Ansatz, bei dem ein zentrales Team eine interne Entwicklungsplattform bereitstellt. DevOps wiederum steht für die enge Zusammenarbeit aller Beteiligten eines Wertstroms. Eine „Cybernetic Delivery Platform\u0026quot; liefert die Schlüsselwerkzeuge (Self-Service, Policy as Code und Observability by Default etc.), damit Entwicklerinnen und Entwickler schnell, sicher und autonom arbeiten können. Das Plattformteam wird so vom „Ticket-Abarbeiter\u0026quot; zum „Enabler\u0026quot;.\nKultur und Leadership: Führungskräften kommt bei einer Transformation stets eine tragende Rolle zu. Sie sollen verändertes Verhalten vorleben und gestalten den kulturellen Wandel an vorderster Front. In der „Cybernetic Enterprise\u0026quot; sind sie nicht mehr als Kommandogeber gefragt, sondern sorgen dafür, dass Mitarbeitende die Fähigkeiten, Mittel und Freiräume erhalten, um sich bestmöglich einzubringen. Technisch eingebettete Leitplanken (Guardrails as Code) geben Orientierung und minimieren Risiken, ohne zu blockieren. Ein Paradigmenwechsel: weg von strikter Kontrolle hin zu vertrauensbasierter Selbststeuerung.\nSechs Etappen auf dem Weg in die Zukunft # Klar ist: Eine „Cybernetic Transformation\u0026quot; passiert nicht über Nacht. Sie ist eine strategische Reise. Damit das Vorhaben nicht in punktuellem Aktionismus verpufft, braucht es einen strukturierten Fahrplan. Sechs Etappen können dem Management bei der Orientierung helfen:\n1. Wertströme transparent machen\nNur wer weiß, wo er steht, kann gezielt vorankommen. Daher führt der erste Schritt zur Wertstromlandkarte der Organisation: Prozesse, Datenflüsse und Verantwortlichkeiten werden hier systematisch abgebildet und analysiert, in Form von Ist- und Zielzuständen (Current/Future Value Stream).\n2. Plattformteam etablieren\nSo entstehen Räume für Innovation: Ein zentrales Plattformteam kümmert sich um die technologische Infrastruktur (Continuous Integration/Delivery, Observability by Default, Policy as Code etc.). Die Entwicklerinnen und Entwickler erhalten eine stabile Basis für schnelles, sicheres, selbstständiges und skalierbares Arbeiten im KI-Umfeld. Übrigens: Interne Selfserviceplattformen bündeln die einzigartigen Fähigkeiten eines Unternehmens und entwickeln sich vermehrt zum Markenkern und externen Differenziator.\n3. KI-Pilot wählen\nNicht gleich alles, sondern das Richtige zuerst: Ein konkreter Use Case mit hoher Datenreife und klarem Business Impact kann als Katalysator dienen. Er macht das Potenzial von KI sichtbar und legt den Grundstein für organisationales Lernen.\n4. Führungskräfte befähigen\nDas Leadership-Team ist jetzt umso mehr gefragt: als Moderator, Navigator und Bindeglied in neu entstehenden Mensch-Maschine-Teams. Führungskräfte sollten daher gezielt in AI Literacy, Coaching und neuen Rollenbildern geschult werden.\n5. Metriken neu ausrichten\nWeg von outputgetriebenen Zahlen, hin zu Flow \u0026amp; Impact Key Performance Indicators (KPIs): Was zählt, ist nicht nur das Ergebnis, sondern wie schnell, wie wertschöpfend und wie kundenzentriert es entsteht. Neue Steuerungsgrößen machen Fortschritt sichtbar.\n6. Erfolgreiche Ansätze skalieren\nZuletzt: Was in der Umsetzung bereits gut funktioniert hat, lohnt sich zu wiederholen. Bewährte Prinzipien werden in Mustermodule bzw. -teams übersetzt und anschließend „geklont\u0026quot;. So entsteht kein starrer Standard, sondern eine autonome Einheit mit Tool-Box.\nTypische Risiken, und wie man sie entschärft # Jede Transformation birgt Risiken, insbesondere, wenn Technologie schneller voranschreitet als interne Strukturen und Unternehmenskultur. Oder wenn es einfach zu komplex wird. Wo lauern typische Stolperfallen und wie begegnet man ihnen?\nTransformation endet nie, sie lernt mit # Alles hat ein Ende, nur die Transformation nicht. Sie ist kein Projekt, das irgendwann ausläuft. Spätestens durch den „Cybernetic-Ansatz\u0026quot; wird das noch deutlicher. Stattdessen wird Transformation zum permanenten Lernprozess, der sich selbst antreibt. Regelmäßige Assessments alle drei Monate messen den Fortschritt, zum Beispiel durch Coverage × Automatisierungsgrad, und helfen, Fokusfelder zu justieren. So bleibt die Organisation offen und flexibel und damit anpassungsfähig gegenüber äußeren Einflüssen.\nIm Überblick: Zehn Tipps für die „Cybernetic Transformation\u0026quot; # Mit dem Wertstrom beginnen, nicht mit der Technologie. In Produkten denken, nicht in Projekten. Entscheidungen automatisieren, nicht nur Prozesse. Feedback in Echtzeit verankern, vom Kunden bis zum Code. Mit Guardrails as Code und Outcome-KPIs führen. Teams befähigen, durch eine Self-Service-Infrastruktur. Skalieren durch eigenverantwortliche, replizierbare Wertstromteams, die mit klaren Schnittstellen autonom agieren. KI auditierbar und erklärbar machen. In Skills der Mitarbeitenden investieren, insbesondere Daten-Storytelling und System-Thinking. Inkrementell experimentieren: Safe-to-Fail statt Big Bang. Die digitale Transformation hat Effizienzpotenziale gehoben, aber auch neue Komplexitäten geschaffen. Wer den nächsten Schritt gehen will, braucht mehr als neue Tools. Die „Cybernetic Transformation\u0026quot; bringt Menschen, Technologie, Prozesse und KI zu einer intelligenten neuen Organisationsform zusammen. Unternehmen, die sich jetzt auf den Weg machen, stärken nicht nur ihre operative Widerstandskraft, sondern sichern sich auch strategische Beweglichkeit für die nächsten Jahre und das Potenzial, mit jeder Lernkurve besser zu werden.\nOriginal Artikel: Springer Professional: https://rdcu.be/eB55w\n","date":"24. August 2025","externalUrl":null,"permalink":"/de/blogs/digitalisierung-war-gestern-kybernetische-transformation/","section":"Blogs","summary":"Sie hat Prozesse automatisiert, Technologie optimiert und in den letzten zwei Jahrzehnten für viel Veränderungsdynamik gesorgt: die Digitalisierung. Doch in einer Welt, in der künstliche Intelligenz (KI) zum permanenten Sparringspartner avanciert, stößt sie an ihre Grenzen. Denn sie bleibt oft bei Einzeloptimierungen stehen und adressiert nicht die systemischen Herausforderungen. Was Unternehmen nun brauchen, ist ein gedankliches Upgrade auf ein neues „Betriebssystem\". Kontinuierlich lernend, konsequent von Daten getrieben und kompromisslos kundenzentriert muss die Organisation der Zukunft sein. Der Weg dorthin ist eine strategische Reise. Die „Cybernetic Transformation\" beginnt jetzt.\n","title":"Digitalisierung war gestern: So gelingt die «Cybernetic Transformation»","type":"blogs"},{"content":"You automated processes, optimized technology, and drove massive change dynamics over the past two decades: digitalization. But in a world where artificial intelligence (AI) is becoming a constant sparring partner, it is reaching its limits. Too often, it stops at isolated optimizations and fails to address systemic challenges. What companies now need is a mental upgrade to a new “operating system.” The organization of the future must be continuously learning, relentlessly data-driven, and uncompromisingly customer-centric. The journey there is strategic. The “Cybernetic Transformation” starts now.\n“More of the same”: straight into a dead end # Companies are under more pressure than ever. Outdated IT landscapes, uncoordinated technology initiatives, an increasing shortage of skilled workers, rising customer expectations, and many other external demands make life difficult. The classic reaction: more digital optimization where the pain is greatest, whether in systems, processes, teams, tools, or metrics. But these isolated efforts often act like painkillers: at best they relieve symptoms, but sometimes they can’t prevent collapse.\nIt’s time to design transformation in a way that heals systemic root causes. The term cybernetics, derived from the Greek word for “helmsman,” describing feedback and circular processes, provides a new direction. AI is the accelerator that turns digital transformation into “Cybernetic Transformation.” This next stage of evolution views the core of a company as a living system capable of evolving itself, based on data, feedback loops, and learning curves. Efficiency is no longer the focus. Instead, the goal is to build a learning, adaptive organization where technology, processes, and structure work seamlessly together in an intelligent triad.\nHow does the “Cybernetic Enterprise” work? # The new target model is the “Cybernetic Enterprise.” AI functions in this form of organization resemble the human nervous system: product sensors, process telemetry, and customer sentiment analysis detect what is happening and feed data continuously into feedback loops. AI agents make routine decisions on this basis. Humans curate signals and evaluate context.\nThe result is an organization in which AI is no longer just a tool but becomes a “colleague of a different kind.” This makes it essential to empower mixed human-machine teams for new forms of collaboration. Platforms replace tool sprawl. And outcome comes before output, meaning actual impact or change is what counts.\nFour Core Elements # Value-stream oriented, feedback-driven, platform-based, customer-centric: the “Cybernetic Enterprise” builds on clear principles to transform organizations holistically in the AI era.\nIntelligent automation along the entire value stream: Instead of digitizing individual steps, the value stream concept automates across all phases of a business process, end-to-end, from idea to customer delivery. Self-learning systems with closed-loop feedback: AI systems don’t just learn once; they learn continuously, based on real-time data and dynamic feedback loops. This creates an ongoing improvement process that regulates and evolves itself. Platform engineering as enabler for self-service and governance as code: Modern platforms enable teams to work quickly, securely, and autonomously. Automated policy checks ensure compliance and governance are integrated into development rather than slowing it down. Customer-centric innovation through rapid prototyping and experimentation frameworks: Testing new ideas early with real users and running controlled experiments validates decisions, minimizes risks, accelerates learning, and increases the chance of successfully scaling innovations. What are the specific benefits? # The “Cybernetic Enterprise” delivers measurable advantages. Experience from numerous transformation projects* shows that the main levers are customer satisfaction, innovation speed, system stability and resilience, and scalability. The improvements achieved are impressive (Fig. 1).\nBlueprint for the learning organization # What belongs in the foundation of a “Cybernetic Enterprise”?\nKey building blocks include:\nData and feedback architecture: Learning requires real-time observation. Companies need a data network that makes all relevant sources accessible and interconnected. The guiding principle: “telemetry everywhere.” Data flows should be continuous, from machine to management dashboard. This makes the organization “data-sensitive,” able to recognize patterns, react situationally, and optimize continuously. Strategic embedding of AI: AI only unfolds its full potential when applied purposefully to clear business goals. This requires prioritizing use cases with high business impact and internal acceptance. It also requires systematic model lifecycle management, ideally with MLOps, to monitor, update, and secure AI models continuously. An AI model is not a one-off product. It evolves with data, environment, and requirements. Platform engineering and DevOps: Platform engineering provides an internal development platform as a stable foundation. DevOps ensures collaboration across the value stream. A “Cybernetic Delivery Platform” provides key tools (self-service, policy as code, observability by default, etc.), enabling developers to work quickly, safely, and autonomously. The platform team evolves from “ticket processor” to “enabler.” Culture and leadership: Leaders play a central role in transformation. They must model new behaviors and drive cultural change. In a “Cybernetic Enterprise,” they are less commanders and more enablers, ensuring employees have the skills, tools, and freedom to contribute fully. Guardrails as code give direction and minimize risks without blocking progress. It’s a paradigm shift, from strict control to trust-based self-management. Six stages on the path to the future # A “Cybernetic Transformation” is not an overnight process. It’s a strategic journey. To prevent efforts from fizzling into ad hoc actions, a structured roadmap is needed. Six stages can guide management:\nMake value streams transparent: You can only move forward deliberately if you know where you stand. The first step is to map the organization’s value streams: processes, data flows, and responsibilities are systematically captured and analyzed, in the form of current and future state value stream maps. Establish a platform team: This creates space for innovation: a central platform team manages the technological infrastructure (Continuous Integration/Delivery, Observability by Default, Policy as Code, etc.), giving developers a stable foundation for fast, secure, autonomous, and scalable work in an AI-driven environment. Internal self-service platforms increasingly bundle a company’s unique capabilities, evolving into both the core of the brand and an external differentiator.\nSelect an AI pilot: Don’t try to do everything at once. Start with the right thing. Select a specific use case with high data maturity and clear business impact. This acts as a catalyst: it demonstrates AI’s potential and lays the groundwork for organizational learning. Empower leadership: The leadership team is now more critical than ever: acting as moderator, navigator, and bridge between human and machine teams. Leaders should be trained in AI literacy, coaching, and new role models to guide the transformation effectively. Realign metrics: Move away from output-driven metrics and toward flow- and impact-based KPIs. What matters is not just the result, but how fast, how value-driven, and how customer-centric it is achieved. New control metrics make real progress visible. Scale successful approaches: Finally: replicate success. Practices that work well should be translated into reusable modules or teams and then “cloned.” The goal is not to enforce rigid standards, but to create autonomous, high-performing units equipped with their own toolbox. Typical Risks, and How to Mitigate Them # Every transformation carries risks, especially when technology advances faster than internal structures or company culture, or when things simply become too complex. Figure 2 illustrates common pitfalls and countermeasures.\nTransformation Never Ends. It Learns # Everything has an end, except transformation. It’s not a project that eventually concludes. The cybernetic approach makes this even clearer: transformation becomes a perpetual learning process that drives itself forward.\nRegular assessments every three months, for example, measuring coverage × automation level, help track progress and realign focus areas. This keeps the organization open, flexible, and adaptable to external influences.\nAt a Glance: Ten Tips for Cybernetic Transformation # Start with value streams, not technology. Think in products, not projects. Automate decisions, not just processes. Embed real-time feedback, from customer to code. Lead with guardrails as code and outcome-oriented KPIs. Empower teams with self-service infrastructure. Scale via autonomous, replicable value-stream teams with clear interfaces. Make AI auditable and explainable. Invest in workforce skills, especially data storytelling and systems thinking. Experiment incrementally: safe-to-fail instead of big bang. Digital transformation unlocked efficiency gains but also introduced new complexities. To take the next step, organizations need more than new tools.\nCybernetic Transformation brings people, technology, processes, and AI together into a smarter, adaptive organizational model.\nCompanies that begin the journey now will not only strengthen their operational resilience but also secure long-term strategic agility, and gain the ability to improve with every learning cycle.\nOriginal Article: Springer Professional: https://rdcu.be/eB55w\n","date":"24 August 2025","externalUrl":null,"permalink":"/en/blogs/digitalization-was-yesterday-how-to-achieve-cybernetic-transformation/","section":"Blogs","summary":"You automated processes, optimized technology, and drove massive change dynamics over the past two decades: digitalization. But in a world where artificial intelligence (AI) is becoming a constant sparring partner, it is reaching its limits. Too often, it stops at isolated optimizations and fails to address systemic challenges. What companies now need is a mental upgrade to a new “operating system.” The organization of the future must be continuously learning, relentlessly data-driven, and uncompromisingly customer-centric. The journey there is strategic. The “Cybernetic Transformation” starts now.\n","title":"Digitalization was Yesterday: How to Achieve “Cybernetic Transformation”","type":"blogs"},{"content":"Sie hat Prozesse automatisiert, Technologie optimiert und in den letzten zwei Jahrzehnten\nfür viel Veränderungsdynamik gesorgt: die Digitalisierung. Doch in einer Welt, in der künstliche Intelligenz (KI) zum permanenten Sparringspartner avanciert, stößt sie an ihre Grenzen. Denn sie bleibt oft bei Einzeloptimierungen stehen und adressiert nicht die systemischen Herausforderungen. Was Unternehmen nun brauchen, ist ein gedankliches Upgrade auf ein neues „Betriebssystem“. Kontinuierlich lernend, konsequent von Daten getrieben und kompromisslos kundenzentriert muss die Organisation der Zukunft sein. Der Weg dorthin ist eine strategische Reise. Die „Cybernetic Transformation“ beginnt jetzt.\n„More of the same“- führt direkt ins Aus # Unternehmen stehen heute mehr denn je unter Druck. Veraltete IT-Landschaften, unkoordinierte Technologieinitiativen, zunehmender Mangel an Fachkräften sowie wachsende Kundenerwartungen und viele weitere externe Anforderungen machen ihnen das Leben schwer. Die klassische Reaktion: Es wird dort weiter digital optimiert, wo es gerade wehtut- seien es Systeme, Prozesse, Teams, Tools oder Kennzahlen. Doch diese isolierten Bemühungen wirken oft wie ein Schmerzmittel: Sie lindern oder beseitigen bestenfalls Symptome und können manches Mal nicht den Kollaps verhindern.\nEs wird Zeit, Transformation so zu gestalten, dass sie die systemischen Ursachen heilt. Der Kybernetik-Begriff, der sich vom griechischen Wort für „Steuermann“ ableitet und Rückkopplung sowie zirkuläre Prozesse beschreibt, führt hier auf eine neue Spur. Die KI ist der Beschleuniger, der die digitale Transformation zur „Cybernetic Transformation“ macht. Diese nächste Evolutionsstufe begreift das Innerste eines Unternehmens als lebendiges System, das sich selbst weiterentwickeln kann- auf Basis von Daten, Feedbackschleifen und Lernkurven. Dabei steht nicht länger die Effizienz im Zentrum. Es geht vielmehr darum, eine lern- und anpassungsfähige Organisation zu etablieren, in der Technologie, Prozesse und Struktur in einem intelligenten Dreiklang nahtlos zusammenspielen.\nWie tickt die „Cybernetic Enterprise“? # Das neue Zielbild heißt „Cybernetic Enterprise“. Die KI-Funktionalitäten ähneln in dieser Organisationsform nicht umsonst dem menschlichen Nervensystem: Sensorik in Produkten, Telemetrie in Prozessen und Sentiment-Analysen bei Kunden erspüren, was passiert, und speisen Daten kontinuierlich in Feedbackschleifen ein. KI-Agenten treffen auf dieser Basis Routineentscheidungen. Menschen kuratieren Signale und bewerten Kontexte.\nIm Ergebnis entsteht so eine Organisation, in der die KI nicht länger Tool ist, sondern zum „Kollegen der anderen Art“ wird. Das macht es unabdingbar, gemischte Mensch-Maschine-Teams für neue Formen der Zusammenarbeit zu befähigen. Plattformen ersetzen Tool-Wildwuchs. Und Outcome kommt vor Output. Das heißt: Die tatsächliche Wirkung oder Veränderung zählt.\nVier Kernelemente # Wertstromorientiert, feedbackgetrieben, plattformbasiert, kundenzentriert: Die „Cybernetic Enterprise“ basiert auf nachvollziehbaren Prinzipien, die Organisationen im KI-Zeitalter ganzheitlich transformieren.\nIntelligente Automatisierung entlang des gesamten Wertstroms: Statt einzelne Abläufe zu digitalisieren, verfolgt das Wertstromkonzept eine Automatisierung über alle Phasen eines Geschäftsprozesses hinweg- End-to-End, von der Idee bis zur Auslieferung an den Kunden. Selbstlernende Systeme mit Closed-Loop-Feedback: KI-Systeme lernen nicht nur einmal, sondern fortlaufend- basierend auf Echtzeitdaten und dynamischen Rückkopplungsschleifen. So entsteht ein kontinuierlicher Verbesserungsprozess, der sich selbst reguliert und weiterentwickelt. Platform Engineering als „Enabler“ für Selfservice und Governance as Code: Moderne Plattformen ermöglichen es Teams, schnell, sicher und eigenverantwortlich zu arbeiten. Eine automatisierte Richtlinienprüfung sorgt dafür, dass Compliance und Governance nicht bremsen, sondern integrierter Bestandteil des Entwicklungsprozesses sind. Kundenzentrierte Innovation durch Rapid Prototyping und Experimentation Frameworks: Wer neue Ideen frühzeitig von echten Usern testen lässt und kontrollierte Experimente durchführt, validiert Entscheidungen, minimiert Risiken, beschleunigt Lernprozesse und erhöht die Wahrscheinlichkeit, Innovationen erfolgreich am Markt zu skalieren. Was bringt’s konkret? # Die „Cybernetic Enterprise“ erzielt messbare Vorteile. Erfahrungswerte aus zahlreichen Transformationsprojekten* zeigen: Die wichtigsten strategischen Hebel sind Kundenzufriedenheit, Innovationsgeschwindigkeit, Systemstabilität und -resilienz sowie Skalierbarkeit. Die erzielten Verbesserungen können sich sehen lassen (Abb.1)\nDer Bauplan für die lernende Organisation # Was gehört ins Fundament einer „Cybernetic Enterprise“?\nDas sind die wichtigsten Bausteine:\nDaten- und Feedbackarchitektur: Lernen funktioniert nicht ohne Echtzeitbeobachtung. Es gilt, ein unternehmensweites Datennetzwerk aufzubauen, das alle relevanten Datenquellen zugänglich macht und intelligent verknüpft. Außerdem lautet die Maßgabe: „Telemetrie everywhere“. Datenströme sollten durchgängig fließen -von der Maschine bis ins Management Dashboard. So wird die Organisation „datenfühlig“- sie erkennt Muster, reagiert situativ und optimiert kontinuierlich. Strategische Einbettung der KI: Künstliche Intelligenz entfaltet ihr volles Potenzial nur dort, wo sie gezielt eingesetzt wird- entlang klarer Geschäftsziele. Deshalb braucht es die Priorisierung strategisch relevanter Use Cases mit klarem Business Outcome, die interne Akzeptanz schaffen. Darüber hinaus ist ein systematisches Model Lifecycle Management erforderlich, idealerweise auf Basis von Machine Learning Operations (MLOps), um KI-Modelle kontinuierlich zu überwachen, zu aktualisieren und regulatorisch ab zusichern. Damit KI nicht zum Innovationsstrohfeuer wird. Ein KI-Modell ist ja kein Einmalprodukt. Es verändert sich mit Daten, Umfeld und Anforderungen. Platform Engineering und DevOps: Platform Engineering ist ein moderner IT-Ansatz, bei dem ein zentrales Team eine interne Entwicklungsplattform bereitstellt. DevOps wiederum steht für die enge Zusammenarbeit aller Beteiligten eines Wertstroms. Eine „Cybernetic Delivery Platform“ liefert die Schlüsselwerkzeuge (Self-Service, Policy as Code und Observability by Default etc.), damit Entwicklerinnen und Entwickler schnell, sicher und autonom arbeiten können. Das Plattformteam wird so vom „Ticket-Abarbeiter“ zum „Enabler“. Kultur und Leadership: Führungskräften kommt bei einer Transformation stets eine tragende Rolle zu. Sie sollen verändertes Verhalten vorleben und gestalten den kulturellen Wandel an vorderster Front. In der „Cybernetic Enterprise“ sind sie nicht mehr als Kommandogeber gefragt, sondern sorgen dafür, dass Mitarbeitende die Fähigkeiten, Mittel und Freiräume erhalten, um sich bestmöglich einzubringen. Technisch eingebettete Leitplanken (Guardrails as Code) geben Orientierung und minimieren Risiken, ohne zu blockieren. Ein Paradigmenwechsel- weg von strikter Kontrolle hin zu vertrauensbasierter Selbststeuerung. Sechs Etappen auf dem Weg in die Zukunft # Klar ist: Eine „Cybernetic Transformation“ passiert nicht über Nacht. Sie ist eine strategische Reise. Damit das Vorhaben nicht in punktuellem Aktionismus verpufft, braucht es einen strukturierten Fahrplan. Sechs Etappen können dem Management bei der Orientierung helfen:\nWertströme transparent machen Nur wer weiß, wo er steht, kann gezielt vorankommen. Daher führt der erste Schritt zur Wertstromlandkarte der Organisation: Prozesse, Datenflüsse und Verantwortlichkeiten werden hier systematisch abgebildet und analysiert- in Form von Ist- und Zielzuständen (Current/Future Value Stream). Plattformteam etablieren So entstehen Räume für Innovation: Ein zentrales Plattformteam kümmert sich um die technologische Infrastruktur (Continuous Integration/Delivery, Observability by Default, Policy as Code etc.)- die Entwicklerinnen und Entwickler erhalten eine stabile Basis für schnelles, sicheres, selbstständiges und skalierbares Arbeiten im KI-Umfeld. Übrigens: Interne Selfserviceplattformen bündeln die einzigartigen Fähigkeiten eines Unternehmens und entwickeln sich vermehrt zum Markenkern und externen Differenziator.\nKI-Pilot wählen Nicht gleich alles, sondern das Richtige zuerst: Ein konkreter Use Case mit hoher Datenreife und klarem Business Impact kann als Katalysator dienen. Er macht das Potenzial von KI sichtbar und legt den Grundstein für organisationales Lernen.\nFührungskräfte befähigen Das Leadership-Team ist jetzt umso mehr gefragt: als Moderator, Navigator und Bindeglied in neu entstehenden Mensch-Maschine-Teams. Führungskräfte sollten daher gezielt in AI Literacy, Coaching und neuen Rollenbildern geschult werden.\nMetriken neu ausrichten Weg von outputgetriebenen Zahlen, hin zu Flow \u0026amp; Impact Key Performance Indicators (KPIs): Was zählt, ist nicht nur das Ergebnis, sondern wie schnell, wie wertschöpfend und wie kundenzentriert es entsteht. Neue Steuerungsgrößen machen Fortschritt sichtbar.\nErfolgreiche Ansätze skalieren Zuletzt: Was in der Umsetzung bereits gut funktioniert hat, lohnt sich zu wiederholen. Bewährte Prinzipien werden in Mustermodule bzw. -teams übersetzt und anschließend „geklont“. So entsteht kein starrer Standard, sondern eine autonome Einheit mit Tool-Box.\nTypische Risiken- und wie man sie entschärft # Jede Transformation birgt Risiken - insbesondere, wenn Technologie schneller voranschreitet als interne Strukturen und Unternehmenskultur. Oder wenn es einfach zu komplex wird. Wo lauern typische Stolperfallen und wie begegnet man ihnen? Hier kommen die Gegenmittel (Abb.2).\nTransformation endet nie- sie lernt mit # Alles hat ein Ende- nur die Transformation nicht. Sie ist kein Projekt, das irgendwann ausläuft. Spätestens durch den „Cybernetic-Ansatz“ wird das noch deutlicher. Stattdessen wird Transformation zum permanenten Lernprozess, der sich selbst antreibt. Regelmäßige Assessments alle drei Monate messen den Fortschritt- zum Beispiel durch Coverage × Au-\ntomatisierungsgrad- und helfen, Fokusfelder zu justieren. So bleibt die Organisation offen und flexibel und damit anpassungsfähig gegenüber äußeren Einflüssen.\nIm Überblick: Zehn Tipps für die „Cybernetic Transformation“ # Mit dem Wertstrom beginnen, nicht mit der Technologie. In Produkten denken, nicht in Projekten. Entscheidungen automatisieren, nicht nur Prozesse. Feedback in Echtzeit verankern- vom Kunden bis zum Code. Mit Guardrails as Code und Outcome-KPIs führen. Teams befähigen- durch eine Self-Service-Infrastruktur. Skalieren durch eigenverantwortliche, replizierbare Wertstromteams, die mit klaren Schnittstellen autonom agieren. KI auditierbar und erklärbar machen. In Skills der Mitarbeitenden investieren- insbesondere Daten-Storytelling und System-Thinking. Inkrementell experimentieren: Safe-to-Fail statt Big Bang. Die digitale Transformation hat Effizienzpotenziale gehoben, aber auch neue Komplexitäten geschaffen. Wer den nächsten Schritt gehen will, braucht mehr als neue Tools. Die „Cybernetic Transformation“ bringt Menschen, Technologie, Prozesse und KI zu einer intelligenten neuen Organisationsform zusammen. Unternehmen, die sich jetzt auf den Weg machen, stärken nicht nur ihre operative Widerstandskraft, sondern sichern sich auch strategische Beweglichkeit für die nächsten Jahre und das Potenzial, mit jeder Lernkurve besser zu werden.\nOriginal Artikel: Springer Professional: https://rdcu.be/eB55w\n","date":"24. August 2025","externalUrl":null,"permalink":"/de/blogs/digitalisierung-war-gestern-so-gelingt-die-cybernetic-transformation/","section":"Blogs","summary":"Sie hat Prozesse automatisiert, Technologie optimiert und in den letzten zwei Jahrzehnten\nfür viel Veränderungsdynamik gesorgt: die Digitalisierung. Doch in einer Welt, in der künstliche Intelligenz (KI) zum permanenten Sparringspartner avanciert, stößt sie an ihre Grenzen. Denn sie bleibt oft bei Einzeloptimierungen stehen und adressiert nicht die systemischen Herausforderungen. Was Unternehmen nun brauchen, ist ein gedankliches Upgrade auf ein neues „Betriebssystem“. Kontinuierlich lernend, konsequent von Daten getrieben und kompromisslos kundenzentriert muss die Organisation der Zukunft sein. Der Weg dorthin ist eine strategische Reise. Die „Cybernetic Transformation“ beginnt jetzt.\n","title":"Digitalisierung war gestern: So gelingt die „Cybernetic Transformation“","type":"blogs"},{"content":"„Hey Kollege!\u0026quot; Schon bald könnten wir so die Person am Nachbarschreibtisch begrüßen und gleichzeitig ein KI-System ansprechen. Denn künftig wird Künstliche Intelligenz (KI) nicht länger ein technisches Tool sein, sondern vielmehr ein aktives Teammitglied. In vier Integrationsphasen, von Assistenz über Co-Kreation und Moderation bis hin zur Hochautonomie unter menschlicher Aufsicht, wächst sie stetig und immer selbstverständlicher in Wertströme, Besprechungen und Entscheidungsprozesse hinein. Die Organisation der Zukunft versteht KI als Teil ihres Nervensystems: kontinuierlich lernend und permanent rückgekoppelt. Willkommen in der Ära der „Cybernetic Transformation\u0026quot;.\nDas andere Teammitglied # Die Künstliche Intelligenz zieht in die Unternehmenswelt ein und verändert ihr Innenleben gerade mit Macht. Wichtig ist, sich im KI-Kontext zunächst von der Fixierung auf Daten zu lösen. Echte Transformation beginnt erst dann, wenn KI nicht nur Informationen aggregiert, sondern Teil der operativen Kernprozesse wird. Neben der Echtzeitanalyse von Daten kann sie Entscheidungen unterstützen und autonom ausführen, Feedbackschleifen fahren und kontinuierlich dazulernen. Prozessorientierung ist also das Stichwort, nicht Datenorientierung. Dies erfordert eine neue Sichtweise. Wer KI bislang als Zusatz-Tool oder sogar Fremdkörper wahrgenommen hat, muss realisieren: Sie entwickelt sich mehr und mehr zum handlungsfähigen, aktiv gestaltenden Mitglied mensch-maschineller Teams, und wird daher künftig mitverantwortlich für Wertschöpfung, Effizienz und Innovationskraft sein.\nVertrauen statt Kontrolle # Das bedeutet insbesondere auch: Die Zusammenarbeit von morgen funktioniert anders und bekommt einen neuen Stellenwert. Wie Menschen und KI-Systeme interagieren, wird den Erfolg des Unternehmens bestimmen. Gefordert sind Arbeitsmodelle, die Verantwortung auf KI-Instanzen ausdehnen und gleichzeitig Menschen in die Lage versetzen, diese Maschinen-Verantwortung bewusst zu steuern. An die Stelle von Kontrolle tritt Empowerment: Transparente Entscheidungen, kontinuierliche Feedbackschleifen und datenbasierte Steuerung stärken das Vertrauen in die „maschinelle Mitarbeiterin\u0026quot;.\nZudem kann implizites Erfahrungswissen, das bisher schwer greifbar war, sogenanntes Tribal Knowledge, über generative KI erschlossen werden. Sie hilft dabei, menschliche Entscheidungsprozesse zu dokumentieren, Zusammenhänge zu verstehen und daraus wiederverwendbare Wissensbausteine zu schaffen. So entsteht ein hybrides Wissenssystem, das Mensch und Maschine gemeinsam weiterentwickeln.\nWarum sich die KI-Reise lohnt # Wie viel Künstliche Intelligenz kann, soll, muss es sein? Und wie setzen wir sie bestmöglich ein? Diese Fragen stellen sich derzeit fast alle Unternehmen. Viele testen einzelne Tools, automatisieren isolierte Aufgaben, und treten auf der Stelle. Dabei liegen die Vorteile einer KI-gestützten Organisation auf der Hand:\nSchnellere Innovationszyklen durch automatisierte Analyse, Simulation und Ideengenerierung, Höhere Effizienz durch adaptive Prozesse und vorausschauende Steuerung, Bessere Kundenerlebnisse durch hyperpersonalisierte Services, Größere Resilienz durch kontinuierliche Anpassung an externe Veränderungen. Diese vielfältigen Potenziale erschließen sich jedoch nur, wenn sich Unternehmen „richtig\u0026quot; auf KI einlassen und einen systemischen Ansatz verfolgen. Wie funktioniert das?\nNext Stop „Cybernetic Transformation\u0026quot; # Die Digitalisierung war in den letzten 15 bis 20 Jahren der zentrale Topos, wenn es um die Zukunftsfähigkeit eines Unternehmens ging. Sie fokussierte meist auf Technologieimplementierung und Prozessoptimierung. Doch im KI-Zeitalter reicht das nicht mehr aus, inhaltlich wie begrifflich. Jetzt braucht es den konsequenten Schritt auf die nächste Evolutionsstufe: Aus der digitalen Transformation wird die „Cybernetic Transformation\u0026quot;, die für einen Paradigmenwechsel steht. Sie denkt die Organisation nicht technisch, sondern als lebendiges System, das sich selbst weiterentwickeln kann, auf Basis von Daten, Feedback und gemeinsamen Werten.\nWarum „cybernetic\u0026quot;? Der Kybernetik-Begriff leitet sich vom griechischen Wort für „Steuermann\u0026quot; ab und bezieht sich hier insbesondere auf Rückkopplung und zirkuläre Prozesse. Damit eignet er sich hervorragend, um Modelle für die Zusammenarbeit zwischen Mensch und KI zu beschreiben.\nDas Zielbild dieser weitergedachten Transformation ist nicht mehr und nicht weniger als ein neues unternehmerisches Betriebsmodell: die „Cybernetic Enterprise\u0026quot;. In einer lern- und anpassungsfähigen Organisation spielen Technologie, Prozesse und Struktur in einem intelligenten Dreiklang nahtlos zusammen. Das ist dem menschlichen Nervensystem sehr ähnlich. In beiden Kontexten geht es darum, permanent Informationen zu verarbeiten und sie in Handlung zu übersetzen, Signale zu interpretieren und Entscheidungen zu treffen.\nSo entsteht eine Organisation, die nicht nur reagiert, sondern sich proaktiv weiterentwickelt: wertstromorientiert, feedbackgetrieben, plattformbasiert, kundenzentriert.\nÜbrigens: Der Weg zur „Cybernetic Enterprise\u0026quot; ist kein Sprung, sondern eine Entwicklung. Ein Reifegradmodell kann sichtbar machen, wie Unternehmen Prozesse Schritt für Schritt auf ein neues Level heben und systematisch in Richtung Autonomie wachsen, von der Digitalisierung einzelner Workflows bis hin zur Selbstregulation auf Systemebene. Dem Management gibt das einen Hebel, die Evolution aktiv zu gestalten und mit Feedbackschleifen abzusichern. Dies erfolgt inkrementell, über gezielte Experimente in geschützten Rahmenbedingungen, ganz im Sinne eines Safe-to-Fail-Ansatzes.\nErfolgsfaktoren im Überblick # Damit Künstliche Intelligenz im Unternehmen echten Mehrwert schaffen kann, müssen darüber hinaus mehrere Faktoren zusammenwirken:\nKlare Rahmenbedingungen: Es braucht verbindliche ethische Leitlinien, rechtliche Sicherheit und Governance-Mechanismen, idealerweise operationalisiert als maschinenlesbare Regeln und Guardrails as Code.\nNeue Rollen: AI Product Owners, Data Ethicists oder Prompt Engineers besetzen künftig Schlüsselpositionen und übernehmen Verantwortung für die Entwicklung und den Betrieb KI-basierter Lösungen.\nNeue Skills: Es gilt, die Mitarbeitenden auf dem Weg mitzunehmen und für den Wandel zu befähigen, dazu gehören Datenkompetenz, die kritische Reflexion von KI-Modellen sowie systemisches Denken.\nFührung unter veränderten Vorzeichen: Wenn Maschinen Entscheidungen vorbereiten oder treffen, beinhaltet Leadership verstärkt die Moderation von Mensch-Maschine-Dialogen.\nPlattformarchitektur statt Tool-Wildwuchs: Eine „Cybernetic Delivery Platform\u0026quot; sorgt dafür, dass alle relevanten Komponenten durchgängig zur Verfügung stehen und als modulare Bausteine einsetzbar sind, egal ob Infrastruktur, Datenintegration, Steuerungsregeln oder Handlungen von KI-Agenten. Interne Self-Service-Plattformen für Entwicklerinnen und Entwickler bündeln die einzigartigen Fähigkeiten eines Unternehmens und werden zunehmend zum strategischen „Enabler\u0026quot;.\nSechs Schritte zur „Cybernetic Enterprise\u0026quot; # Auf dem Weg Richtung „Cybernetic Enterprise\u0026quot; haben sich verschiedene Handlungsfelder in der Praxis als besonders relevant erwiesen. Entscheiderinnen und Entscheider sollten darauf verstärkt ihr Augenmerk legen.\n1. Wertströme sichtbar machen\nDer erste Schritt umfasst die systematische Analyse bestehender Abläufe. Mit Methoden wie Value Stream Mapping lassen sich Ist- und Zielzustände von Wertschöpfungsprozessen transparent machen. Engpässe oder überflüssige Schleifen werden so frühzeitig identifiziert. Diese Klarheit schafft die Grundlage, um gezielt Verbesserungen umzusetzen, immer mit Blick auf den tatsächlichen Wertbeitrag.\n2. Plattformteams aufbauen\nEs empfiehlt sich, ein zentrales Plattformteam aufzubauen, das die technologische Infrastruktur automatisiert bereitstellt, für Praktiken und Prinzipien wie Continuous Integration (CI) / Continuous Delivery (CD), Observability by Default und Policy as Code. Damit entsteht eine stabile Basis für schnelles, sicheres und skalierbares Arbeiten, das gleichzeitig die Produktteams entlastet.\n3. KI-Pilotprojekte starten\nDer Einstieg in die Nutzung Künstlicher Intelligenz sollte pragmatisch und ergebnisorientiert erfolgen. Dafür eignen sich datenstarke Anwendungsfälle mit hohem Automatisierungspotenzial, wie etwa Predictive Maintenance, intelligente Nachfrageprognosen oder Anomalieerkennung. Entscheidend ist, dass diese Projekte einen klar messbaren Outcome liefern, und damit Vertrauen in die Technologie schaffen.\n4. Leadership weiterentwickeln\nDie Einführung autonomer Instanzen verlangt nach einem neuen Führungsstil und -verständnis. Gefragt ist die Fähigkeit zur Moderation. Führungskräfte sollten gezielt Kompetenzen in AI Literacy, Coaching und interaktiver Kommunikation aufbauen, um wirksam als Brücke zwischen Menschen und KI agieren zu können.\n5. Kennzahlen neu denken\nTraditionelle output-orientierte Key Perfomance Indicators (KPIs) greifen in einer dynamischen, rückkopplungsgesteuerten Organisation zu kurz. Stattdessen rücken neue Metriken in den Fokus, die Prozessfluss, Anpassungsfähigkeit und Wirkung messen. Dazu zählen zum Beispiel Durchlaufzeiten entlang des Wertstroms, Time to Learn oder der tatsächliche Impact auf den Geschäftserfolg. Weniger ist hier mehr, Fokussierung schafft Orientierung.\n6. Erfolge nach „Muster\u0026quot; skalieren\nNach ersten Erfolgen gilt es, wirksame Strukturen zu verstetigen. Statt großflächiger Rollouts haben sich dabei Mustermodule bzw. -teams bewährt: kleine, funktionsübergreifende Einheiten, in denen neue Technologien erfolgreich umgesetzt wurden. Diese lassen sich gezielt „klonen\u0026quot;, ohne die dahinterliegenden Prinzipien zu verwässern. Skalierung erfolgt so organisch, und bleibt anschlussfähig an die Kultur des Unternehmens.\nDie Zukunft ist jetzt # Die Organisation der Zukunft denkt nicht mehr im Antagonismus zwischen Mensch und Maschine, sie tickt „cybernetic\u0026quot;. Dabei kombiniert sie menschliche Kreativität und Urteilskraft mit der Präzision und Skalierbarkeit maschineller Intelligenz, dockt jede Entscheidung an Daten und Feedback an und erneuert sich kontinuierlich. Wer diesen Wandel heute gestaltet, fährt morgen die Ernte ein: die strategische Agilität und operative Resilienz, die es im Wettbewerb braucht.\nOriginal Artikel in DIGITALE WELT: https://digitaleweltmagazin.de/von-menschen-und-maschinen-die-organisation-der-zukunft/\n","date":"18. August 2025","externalUrl":null,"permalink":"/de/blogs/von-menschen-und-maschinen-die-organisation-der-zukunft/","section":"Blogs","summary":"„Hey Kollege!\" Schon bald könnten wir so die Person am Nachbarschreibtisch begrüßen und gleichzeitig ein KI-System ansprechen. Denn künftig wird Künstliche Intelligenz (KI) nicht länger ein technisches Tool sein, sondern vielmehr ein aktives Teammitglied. In vier Integrationsphasen, von Assistenz über Co-Kreation und Moderation bis hin zur Hochautonomie unter menschlicher Aufsicht, wächst sie stetig und immer selbstverständlicher in Wertströme, Besprechungen und Entscheidungsprozesse hinein. Die Organisation der Zukunft versteht KI als Teil ihres Nervensystems: kontinuierlich lernend und permanent rückgekoppelt. Willkommen in der Ära der „Cybernetic Transformation\".\n","title":"Von Menschen und Maschinen: Die Organisation der Zukunft","type":"blogs"},{"content":"\u0026ldquo;Hey colleague!\u0026rdquo; Soon, this could be how we greet the person at the next desk, while at the same time addressing an AI system. In the future, Artificial Intelligence (AI) will no longer be just a technical tool, but an active team member. In four integration phases, ranging from assistance to co-creation, moderation, and ultimately high autonomy under human oversight, it will grow steadily and naturally into value streams, meetings, and decision-making processes. The organization of the future understands AI as part of its nervous system: continuously learning and permanently feedback-driven. Welcome to the era of Cybernetic Transformation.\nThe Other Team Member # Artificial Intelligence is entering the corporate world and is transforming its inner workings with force. The first important step in the AI context is to break free from the fixation on data. True transformation only begins when AI not only aggregates information but becomes part of the operational core processes. Beyond real-time data analysis, it can support and autonomously execute decisions, drive feedback loops, and continuously learn. The key is process orientation, not data orientation. This requires a new perspective. Anyone who has so far perceived AI as an add-on tool or even as a foreign body must realize: it is increasingly becoming an actionable, actively shaping member of human-machine teams, and will therefore share responsibility for value creation, efficiency, and innovation power.\nTrust Instead of Control # This also means that collaboration will work differently tomorrow and gain a new importance. How humans and AI systems interact will determine a company’s success. Work models are needed that extend responsibility to AI instances while enabling humans to consciously steer this machine responsibility. Control gives way to empowerment: transparent decisions, continuous feedback loops, and data-driven governance build trust in the “machine colleague.”\nFurthermore, implicit experiential knowledge, previously difficult to capture, known as tribal knowledge, can be unlocked through generative AI. It helps document human decision-making processes, understand interconnections, and create reusable knowledge modules. In this way, a hybrid knowledge system emerges, which humans and machines jointly evolve.\nWhy the AI Journey Is Worth It # How much Artificial Intelligence can, should, and must there be? And how do we best use it? Almost all companies are asking themselves these questions today. Many test individual tools, automate isolated tasks, and stagnate. Yet the advantages of an AI-supported organization are obvious:\nFaster innovation cycles through automated analysis, simulation, and idea generation Higher efficiency through adaptive processes and predictive steering Better customer experiences through hyper-personalized services Greater resilience through continuous adaptation to external changes These diverse potentials, however, only unfold if companies commit to AI the “right way” and pursue a systemic approach. How does that work?\nNext Stop: Cybernetic Transformation # For the past 15 to 20 years, digitalization was the central focus when it came to a company’s future viability. It mostly centered on technology implementation and process optimization. But in the age of AI, that is no longer sufficient, conceptually or practically. Now it takes a consistent step to the next stage of evolution: digital transformation becomes Cybernetic Transformation, representing a paradigm shift. It does not view the organization as technical machinery but as a living system that can evolve itself, based on data, feedback, and shared values.\nWhy “cybernetic”? The term cybernetics comes from the Greek word for “steersman” and here refers especially to feedback and circular processes. This makes it ideally suited to describe models of collaboration between humans and AI.\nThe vision of this evolved transformation is nothing less than a new business operating model: the Cybernetic Enterprise. In a learning and adaptive organization, technology, processes, and structure interact seamlessly in an intelligent triad. This strongly resembles the human nervous system. In both contexts, it is about continuously processing information, translating it into action, interpreting signals, and making decisions.\nThus emerges an organization that not only reacts but develops itself proactively: value-stream-oriented, feedback-driven, platform-based, customer-centered.\nBy the way: the path to the Cybernetic Enterprise is not a leap but a development. A maturity model can show how companies can raise processes step by step to a new level and systematically grow toward autonomy, from digitizing individual workflows to self-regulation at the system level. For management, this offers a lever to actively shape evolution and secure it with feedback loops. This happens incrementally, through targeted experiments in safe-to-fail environments.\nSuccess Factors at a Glance # For AI to create real value in companies, several factors must come together:\nClear frameworks: binding ethical guidelines, legal certainty, and governance mechanisms, ideally operationalized as machine-readable rules and Guardrails as Code. New roles: AI Product Owners, Data Ethicists, or Prompt Engineers will occupy key positions and assume responsibility for the development and operation of AI-based solutions. New skills: employees must be empowered for the change. This includes data literacy, critical reflection on AI models, and systems thinking. Leadership under new conditions: when machines prepare or make decisions, leadership increasingly involves moderating human-machine dialogues. Platform architecture instead of tool chaos: a Cybernetic Delivery Platform ensures that all relevant components are consistently available and deployable as modular building blocks, whether infrastructure, data integration, governance rules, or AI agent actions. Internal self-service platforms for developers consolidate a company’s unique capabilities and increasingly become a strategic enabler. Six Steps to the Cybernetic Enterprise # Make value streams visibleStart with a systematic analysis of existing workflows. Methods such as value stream mapping make current and target states of value creation transparent. Bottlenecks and redundancies are identified early, creating clarity for targeted improvements, always focused on value contribution. Build platform teamsEstablish a central platform team that automates the provision of technological infrastructure, for practices and principles such as Continuous Integration/Continuous Delivery (CI/CD), Observability by Default, and Policy as Code. This forms a stable foundation for fast, safe, and scalable work while relieving product teams. Launch AI pilot projectsEntry into AI use should be pragmatic and outcome-driven. Data-rich use cases with high automation potential, such as predictive maintenance, intelligent demand forecasting, or anomaly detection, are particularly suitable. The decisive factor is that these projects deliver a clearly measurable outcome and build trust in the technology. Evolve leadershipThe introduction of autonomous instances requires a new style and understanding of leadership. Moderation skills are essential. Leaders should deliberately build competencies in AI literacy, coaching, and interactive communication to effectively act as a bridge between humans and AI. Rethink metricsTraditional output-focused KPIs fall short in a dynamic, feedback-driven organization. Instead, new metrics gain importance that measure process flow, adaptability, and impact, for example, lead times along the value stream, time to learn, or actual business impact. Less is more here. Focus provides orientation. Scale successes by patternsAfter initial successes, effective structures need to be institutionalized. Instead of large-scale rollouts, pattern modules or pattern teams, small cross-functional units where new technologies have been successfully implemented, have proven effective. These can be deliberately cloned without diluting the underlying principles. Scaling thus occurs organically and remains compatible with company culture. The Future Is Now # The organization of the future no longer thinks in terms of a human-versus-machine antagonism; it thinks cybernetically. It combines human creativity and judgment with the precision and scalability of machine intelligence, anchors every decision in data and feedback, and continuously renews itself. Those who shape this transformation today will reap the benefits tomorrow: the strategic agility and operational resilience required to stay competitive.\nOrigianl article on DIGITALE WELT: https://digitaleweltmagazin.de/von-menschen-und-maschinen-die-organisation-der-zukunft/\n","date":"18 August 2025","externalUrl":null,"permalink":"/en/blogs/from-humans-and-machines-the-organization-of-the-future/","section":"Blogs","summary":"“Hey colleague!” Soon, this could be how we greet the person at the next desk, while at the same time addressing an AI system. In the future, Artificial Intelligence (AI) will no longer be just a technical tool, but an active team member. In four integration phases, ranging from assistance to co-creation, moderation, and ultimately high autonomy under human oversight, it will grow steadily and naturally into value streams, meetings, and decision-making processes. The organization of the future understands AI as part of its nervous system: continuously learning and permanently feedback-driven. Welcome to the era of Cybernetic Transformation.\n","title":"From Humans and Machines: The Organization of the Future","type":"blogs"},{"content":"„Hey Kollege!\u0026quot; Schon bald könnten wir die Person am Nachbarschreibtisch genau so begrüssen und gleichzeitig ein KI-System ansprechen. In Zukunft wird Künstliche Intelligenz (KI) nicht mehr nur ein technisches Werkzeug sein, sondern ein aktives Teammitglied. In vier Integrationsphasen, von Assistenz über Co-Kreation und Moderation bis hin zu hoher Autonomie unter menschlicher Aufsicht, wächst sie stetig und ganz natürlich in Wertströme, Besprechungen und Entscheidungsprozesse hinein. Die Organisation der Zukunft versteht KI als Teil ihres Nervensystems: kontinuierlich lernend und permanent feedbackgetrieben. Willkommen in der Ära der Cybernetic Transformation.\nDas andere Teammitglied # Künstliche Intelligenz hält Einzug in die Unternehmenswelt und verändert ihr Innenleben mit Wucht. Der erste wichtige Schritt im KI-Kontext besteht darin, sich von der Fixierung auf Daten zu lösen. Echte Transformation beginnt erst dann, wenn KI nicht nur Informationen aggregiert, sondern Teil der operativen Kernprozesse wird. Über die Echtzeit-Datenanalyse hinaus kann sie Entscheidungen unterstützen und autonom treffen, Feedbackschleifen antreiben und kontinuierlich lernen. Entscheidend ist die Prozessorientierung, nicht die Datenorientierung. Das erfordert eine neue Sichtweise. Wer KI bisher als Zusatzwerkzeug oder gar als Fremdkörper wahrgenommen hat, muss erkennen: Sie wird zunehmend zu einem handlungsfähigen, aktiv gestaltenden Mitglied von Mensch-Maschine-Teams und übernimmt damit Mitverantwortung für Wertschöpfung, Effizienz und Innovationskraft.\nVertrauen statt Kontrolle # Das bedeutet auch, dass die Zusammenarbeit von morgen anders funktionieren und einen neuen Stellenwert erhalten wird. Wie Menschen und KI-Systeme zusammenwirken, wird über den Erfolg eines Unternehmens entscheiden. Es braucht Arbeitsmodelle, die Verantwortung auf KI-Instanzen ausdehnen und es zugleich Menschen ermöglichen, diese maschinelle Verantwortung bewusst zu steuern. An die Stelle von Kontrolle tritt Empowerment: Transparente Entscheidungen, kontinuierliche Feedbackschleifen und datengetriebene Governance schaffen Vertrauen in die „maschinelle Kollegin\u0026quot;.\nDarüber hinaus lässt sich implizites Erfahrungswissen, das bisher schwer fassbar war, das sogenannte Tribal Knowledge, durch generative KI erschliessen. Sie hilft, menschliche Entscheidungsprozesse zu dokumentieren, Zusammenhänge zu verstehen und wiederverwendbare Wissensbausteine zu schaffen. So entsteht ein hybrides Wissenssystem, das Mensch und Maschine gemeinsam weiterentwickeln.\nWarum sich die KI-Reise lohnt # Wie viel Künstliche Intelligenz darf, soll und muss es sein? Und wie setzen wir sie am besten ein? Diese Fragen stellen sich heute fast alle Unternehmen. Viele testen einzelne Tools, automatisieren isolierte Aufgaben und treten auf der Stelle. Dabei liegen die Vorteile einer KI-gestützten Organisation auf der Hand:\nSchnellere Innovationszyklen durch automatisierte Analyse, Simulation und Ideengenerierung Höhere Effizienz durch adaptive Prozesse und vorausschauende Steuerung Bessere Kundenerlebnisse durch hyperpersonalisierte Services Grössere Resilienz durch kontinuierliche Anpassung an externe Veränderungen Diese vielfältigen Potenziale entfalten sich allerdings nur, wenn sich Unternehmen „richtig\u0026quot; auf KI einlassen und einen systemischen Ansatz verfolgen. Wie funktioniert das?\nNext Stop: Cybernetic Transformation # In den letzten 15 bis 20 Jahren stand die Digitalisierung im Zentrum, wenn es um die Zukunftsfähigkeit eines Unternehmens ging. Sie konzentrierte sich vor allem auf Technologieimplementierung und Prozessoptimierung. Im KI-Zeitalter reicht das jedoch nicht mehr aus, weder konzeptionell noch praktisch. Jetzt braucht es den konsequenten Schritt auf die nächste Evolutionsstufe: Aus der digitalen Transformation wird die Cybernetic Transformation, die für einen Paradigmenwechsel steht. Sie sieht die Organisation nicht als technisches Räderwerk, sondern als lebendiges System, das sich selbst weiterentwickeln kann, auf Basis von Daten, Feedback und gemeinsamen Werten.\nWarum „cybernetic\u0026quot;? Der Begriff Kybernetik leitet sich vom griechischen Wort für „Steuermann\u0026quot; ab und bezieht sich hier insbesondere auf Rückkopplung und zirkuläre Prozesse. Damit eignet er sich hervorragend, um Modelle der Zusammenarbeit zwischen Mensch und KI zu beschreiben.\nDas Zielbild dieser weitergedachten Transformation ist nichts Geringeres als ein neues unternehmerisches Betriebsmodell: die Cybernetic Enterprise. In einer lern- und anpassungsfähigen Organisation greifen Technologie, Prozesse und Struktur in einem intelligenten Dreiklang nahtlos ineinander. Das ähnelt stark dem menschlichen Nervensystem. In beiden Kontexten geht es darum, kontinuierlich Informationen zu verarbeiten, sie in Handlungen zu übersetzen, Signale zu interpretieren und Entscheidungen zu treffen.\nSo entsteht eine Organisation, die nicht nur reagiert, sondern sich proaktiv weiterentwickelt: wertstromorientiert, feedbackgetrieben, plattformbasiert, kundenzentriert.\nÜbrigens: Der Weg zur Cybernetic Enterprise ist kein Sprung, sondern eine Entwicklung. Ein Reifegradmodell kann zeigen, wie Unternehmen Prozesse Schritt für Schritt auf ein neues Niveau heben und systematisch in Richtung Autonomie wachsen können, von der Digitalisierung einzelner Workflows bis zur Selbstregulation auf Systemebene. Dem Management bietet das einen Hebel, die Evolution aktiv zu gestalten und mit Feedbackschleifen abzusichern. Dies geschieht inkrementell, durch gezielte Experimente in geschützten, „safe-to-fail\u0026quot;-Umgebungen.\nErfolgsfaktoren im Überblick # Damit KI in Unternehmen echten Mehrwert schaffen kann, müssen mehrere Faktoren zusammenwirken:\nKlare Rahmenbedingungen: verbindliche ethische Leitlinien, rechtliche Sicherheit und Governance-Mechanismen, idealerweise operationalisiert als maschinenlesbare Regeln und Guardrails as Code. Neue Rollen: AI Product Owners, Data Ethicists oder Prompt Engineers werden Schlüsselpositionen einnehmen und Verantwortung für Entwicklung und Betrieb KI-basierter Lösungen übernehmen. Neue Skills: Mitarbeitende müssen für den Wandel befähigt werden. Dazu gehören Datenkompetenz, kritische Reflexion von KI-Modellen und systemisches Denken. Führung unter neuen Vorzeichen: Wenn Maschinen Entscheidungen vorbereiten oder treffen, beinhaltet Leadership zunehmend die Moderation von Mensch-Maschine-Dialogen. Plattformarchitektur statt Tool-Wildwuchs: Eine Cybernetic Delivery Platform sorgt dafür, dass alle relevanten Komponenten durchgängig verfügbar und als modulare Bausteine einsetzbar sind, sei es Infrastruktur, Datenintegration, Governance-Regeln oder Aktionen von KI-Agenten. Interne Self-Service-Plattformen für Entwicklerinnen und Entwickler bündeln die einzigartigen Fähigkeiten eines Unternehmens und werden zunehmend zu einem strategischen Enabler. Sechs Schritte zur Cybernetic Enterprise # Wertströme sichtbar machen: Beginnen Sie mit einer systematischen Analyse bestehender Abläufe. Methoden wie Value Stream Mapping machen Ist- und Zielzustände der Wertschöpfung transparent. Engpässe und Redundanzen werden frühzeitig erkannt und schaffen Klarheit für gezielte Verbesserungen, immer mit Fokus auf den Wertbeitrag. Plattformteams aufbauen: Etablieren Sie ein zentrales Plattformteam, das die Bereitstellung der technologischen Infrastruktur automatisiert, für Praktiken und Prinzipien wie Continuous Integration/Continuous Delivery (CI/CD), Observability by Default und Policy as Code. So entsteht eine stabile Grundlage für schnelles, sicheres und skalierbares Arbeiten, während die Produktteams entlastet werden. KI-Pilotprojekte starten: Der Einstieg in den KI-Einsatz sollte pragmatisch und ergebnisorientiert erfolgen. Besonders geeignet sind datenstarke Anwendungsfälle mit hohem Automatisierungspotenzial wie Predictive Maintenance, intelligente Bedarfsprognosen oder Anomalieerkennung. Entscheidend ist, dass diese Projekte einen klar messbaren Outcome liefern und Vertrauen in die Technologie aufbauen. Leadership weiterentwickeln: Die Einführung autonomer Instanzen erfordert einen neuen Führungsstil und ein neues Führungsverständnis. Moderationsfähigkeiten sind essenziell. Führungskräfte sollten gezielt Kompetenzen in AI Literacy, Coaching und interaktiver Kommunikation aufbauen, um wirksam als Brücke zwischen Mensch und KI zu agieren. Kennzahlen neu denken: Klassische output-orientierte KPIs greifen in einer dynamischen, feedbackgetriebenen Organisation zu kurz. Stattdessen gewinnen neue Metriken an Bedeutung, die Prozessfluss, Anpassungsfähigkeit und Wirkung messen, etwa Durchlaufzeiten entlang des Wertstroms, Time to Learn oder der tatsächliche Geschäftsimpact. Hier gilt: weniger ist mehr. Fokussierung schafft Orientierung. Erfolge nach Mustern skalieren: Nach ersten Erfolgen müssen wirksame Strukturen institutionalisiert werden. Statt grossflächiger Rollouts haben sich Mustermodule oder Musterteams bewährt: kleine, funktionsübergreifende Einheiten, in denen neue Technologien erfolgreich umgesetzt wurden. Diese lassen sich gezielt klonen, ohne die zugrunde liegenden Prinzipien zu verwässern. Skalierung erfolgt so organisch und bleibt anschlussfähig an die Unternehmenskultur. Die Zukunft ist jetzt # Die Organisation der Zukunft denkt nicht mehr in einem Antagonismus zwischen Mensch und Maschine, sie denkt cybernetic. Sie kombiniert menschliche Kreativität und Urteilskraft mit der Präzision und Skalierbarkeit maschineller Intelligenz, verankert jede Entscheidung in Daten und Feedback und erneuert sich kontinuierlich. Wer diese Transformation heute gestaltet, fährt morgen die Ernte ein: die strategische Agilität und operative Resilienz, die für die Wettbewerbsfähigkeit nötig sind.\nOriginalartikel auf DIGITALE WELT: https://digitaleweltmagazin.de/von-menschen-und-maschinen-die-organisation-der-zukunft/\n","date":"18. August 2025","externalUrl":null,"permalink":"/de/blogs/von-menschen-und-maschinen-organisation-der-zukunft/","section":"Blogs","summary":"„Hey Kollege!\" Schon bald könnten wir die Person am Nachbarschreibtisch genau so begrüssen und gleichzeitig ein KI-System ansprechen. In Zukunft wird Künstliche Intelligenz (KI) nicht mehr nur ein technisches Werkzeug sein, sondern ein aktives Teammitglied. In vier Integrationsphasen, von Assistenz über Co-Kreation und Moderation bis hin zu hoher Autonomie unter menschlicher Aufsicht, wächst sie stetig und ganz natürlich in Wertströme, Besprechungen und Entscheidungsprozesse hinein. Die Organisation der Zukunft versteht KI als Teil ihres Nervensystems: kontinuierlich lernend und permanent feedbackgetrieben. Willkommen in der Ära der Cybernetic Transformation.\n","title":"Von Menschen und Maschinen: Organisation der Zukunft","type":"blogs"},{"content":"Explore the fusion of AI with DevOps and platform engineering to automate workflows, enhance efficiency, and drive innovation.\nWhat This Talk Covers # The convergence of AI, DevOps, and Platform Engineering is reshaping how we build and operate software. AI is no longer just a feature we ship, it is becoming part of how we ship. From intelligent CI/CD pipelines to AI-assisted incident response, the developer experience is changing fundamentally.\nKey Topics # 1. AI in the Development Workflow How AI-powered tools are transforming code review, testing, and deployment. Beyond code completion: using AI to detect patterns, predict failures, and optimize pipelines.\n2. Platform Engineering Meets AI Building internal developer platforms that leverage AI for self-service, automated provisioning, and intelligent routing. How platform teams can use AI to scale without scaling headcount.\n3. Intelligent Operations From reactive monitoring to proactive AI-driven observability. How AI agents can detect anomalies, correlate events, and even remediate issues before they impact users.\nPractical Takeaways # This is not a theoretical talk. You will see real tools, real workflows, and real results from organizations that have started integrating AI into their DevOps and platform engineering practices. You leave with concrete ideas you can apply in your own organization.\n","date":"17 July 2025","externalUrl":null,"permalink":"/en/speaking/ai-augmented-devops-with-platform-engineering/","section":"Speaking","summary":"Explore the fusion of AI with DevOps and platform engineering to automate workflows, enhance efficiency, and drive innovation.\nWhat This Talk Covers # The convergence of AI, DevOps, and Platform Engineering is reshaping how we build and operate software. AI is no longer just a feature we ship, it is becoming part of how we ship. From intelligent CI/CD pipelines to AI-assisted incident response, the developer experience is changing fundamentally.\n","title":"AI-Augmented DevOps with Platform Engineering","type":"speaking"},{"content":"","date":"17 July 2025","externalUrl":null,"permalink":"/en/tags/automation/","section":"Tags","summary":"","title":"Automation","type":"tags"},{"content":"","date":"17 July 2025","externalUrl":null,"permalink":"/en/tags/developer-experience/","section":"Tags","summary":"","title":"Developer Experience","type":"tags"},{"content":"In today\u0026rsquo;s rapidly evolving landscape, businesses are constantly confronted with changing customer needs, increased competition, and a significant shortage of skilled workers. Agility and speed are no longer optional, they are critical to survival.\nWhy Platform Engineering Matters # In this talk, I demonstrate how Platform Engineering can act as the cornerstone for addressing these challenges, providing the scalability and flexibility necessary to adapt swiftly, innovate faster, and bridge the skills gap by automating complex workflows.\nWhat You Will See # This session offers in-depth insights into how platform-centric strategies transform the development process, driving productivity and enabling the rapid delivery of high-quality software.\nReal-World Examples and Live Demo Through real-world examples, a live demo of a platform, and case studies, I illustrate how companies can overcome common scaling hurdles, improve developer experience, and streamline operations by leveraging DevOps practices within a well-designed platform.\nKey Topics # 1. The Developer Experience Challenge Why developer experience is the key differentiator in attracting and retaining talent. How friction in the development process slows down innovation and what to do about it.\n2. Platform Engineering in Practice How to build internal developer platforms that provide self-service capabilities, reduce cognitive load, and enable teams to move fast without breaking things.\n3. Bridging the Skills Gap How platform engineering and automation help organizations do more with existing teams by abstracting complexity and providing golden paths.\n","date":"17 July 2025","externalUrl":null,"permalink":"/en/speaking/developer-experience-and-platform-engineering/","section":"Speaking","summary":"In today’s rapidly evolving landscape, businesses are constantly confronted with changing customer needs, increased competition, and a significant shortage of skilled workers. Agility and speed are no longer optional, they are critical to survival.\n","title":"Developer Experience and Platform Engineering","type":"speaking"},{"content":"DevOps in der Schweiz hat einen Wendepunkt erreicht. Was einst als Graswurzelbewegung begann, ist heute ein strategischer Hebel für digitale Resilienz, Effizienz und Innovation. Der Report «DevOps in der Schweiz 2025», gemeinsam erstellt von Zühlke und VSHN, zeigt klare Signale dieser Transformation. Basierend auf 184 Umfrageantworten zeigt die sechste Ausgabe des Reports, wie Schweizer Organisationen DevOps nicht nur einführen, sondern durch Platform Engineering skalieren und mit KI ergänzen.\n1. DevOps: Ein strategischer Standard # Der Report bestätigt, was viele Praktizierende täglich erleben: DevOps ist der operative Standard in der Schweiz. Agile Zusammenarbeit, funktionsübergreifende Verantwortung und Continuous Delivery sind mittlerweile branchenübergreifend verankert, von der IT über das Bankwesen bis zum öffentlichen Sektor. Der Erfolg wird jedoch nicht mehr allein durch die Einführung von Tools bestimmt. Organisationskultur, Führungsausrichtung und die Fähigkeit, im großen Maßstab zu liefern, sind entscheidend geworden.\n2. Platform Engineering: DevOps im großen Maßstab # Über die Hälfte der Schweizer Organisationen (54%) haben mittlerweile dedizierte Platform-Engineering-Teams. Diese Teams bauen Internal Developer Platforms (IDPs), um Komplexität zu reduzieren und die Lieferung zu beschleunigen. Die wichtigsten Treiber?\nAutonomie und Developer Experience Schnellere Innovationszyklen Operative Konsistenz durch Self-Service-Plattformen Während Tools wie Backstage an Bedeutung gewinnen, fehlt bei 40% der Organisationen noch eine IDP. Die Praxis reift, ist aber noch nicht universell verbreitet. Interessanterweise priorisieren viele Anwender Befähigung vor Governance, was die Notwendigkeit unterstreicht, Plattformen von technischen Systemen zu strategischen Produkten weiterzuentwickeln.\n«Platform Engineering ist nicht mehr optional, es ist grundlegend.»\n3. Künstliche Intelligenz: Vom Hype zum Copilot # KI wird leise zum DevOps-Copilot. Ein Drittel der Schweizer DevOps-Teams nutzt bereits KI, insbesondere in den Bereichen:\nCode Review und Qualitätssicherung Unterstützung beim Architekturdesign CI/CD-Automatisierung Die KI-Einführung bleibt jedoch ungleichmäßig. Spätphasige Lifecycle-Bereiche wie Testing, Compliance und Sicherheit sind noch wenig erschlossen. Auch die Messung ist inkonsistent: Nur wenige Teams haben klare KPIs für KI-gestützte Initiativen definiert. Dennoch ist die Stimmung unter Entwicklern überwältigend positiv: 79% fühlen sich im Umgang mit KI-Tools wohl.\n4. Tooling: Dominant, aber diversifizierend # Der Schweizer DevOps-Stack konsolidiert sich weiterhin um Schlüsseltechnologien:\nGitLab, Kubernetes und Terraform bleiben dominant. Linux festigt seine Stellung als bevorzugtes Produktions-Betriebssystem. Argo CD und GitHub sind im Aufwind, was auf eine wachsende Verbreitung von Cloud-Native- und GitOps-Praktiken hindeutet. FinOps und MLOps befinden sich noch in einer frühen Phase. Observability bleibt ein Eckpfeiler, angeführt von Grafana und Prometheus.\n5. Die Kulturlücke bleibt bestehen # Trotz technologischer Reife bleiben kulturelle Herausforderungen bestehen. Die größten Blocker sind:\nAltsysteme und technische Schulden Widerstand gegen Veränderung Fachkräftemangel und unklare Verantwortlichkeiten Wie der Report deutlich macht, geht es beim DevOps-Erfolg 2025 weniger um Tools und mehr um Vertrauen, Führung und Organisationsdesign.\nAusblick: Wohin die Reise geht # Der Report identifiziert drei aufkommende Schwerpunkte:\nPlattformen als Produkte, nicht nur als technische Enabler KI-gestütztes Engineering über den gesamten Software-Lebenszyklus Ergebnisbasierte Messung: weg von reiner Geschwindigkeit, hin zu Wertschöpfung Angesichts wachsender Komplexität und wirtschaftlicher Unsicherheit wird DevOps der adaptive Kern moderner Softwarelieferung bleiben.\nDie Zukunft von DevOps ist plattformgestützt, KI-unterstützt und ergebnisorientiert, aber immer noch von Menschen angetrieben.\nDen vollständigen Report mit detaillierten Einblicken, Datenvisualisierungen und praktischen Empfehlungen können Sie hier herunterladen: https://www.vshn.ch/blog/jetzt-verfuegbar-devops-in-der-schweiz-report-2025/\n🎥 Und verpassen Sie nicht das Release-Video mit Highlights, Kontext und Hintergrundinformationen der Autoren.\n","date":"13. July 2025","externalUrl":null,"permalink":"/de/blogs/devops-in-der-schweiz-2025-devops-skalieren-mit-plattformen-und-ki/","section":"Blogs","summary":"DevOps in der Schweiz hat einen Wendepunkt erreicht. Was einst als Graswurzelbewegung begann, ist heute ein strategischer Hebel für digitale Resilienz, Effizienz und Innovation. Der Report «DevOps in der Schweiz 2025», gemeinsam erstellt von Zühlke und VSHN, zeigt klare Signale dieser Transformation. Basierend auf 184 Umfrageantworten zeigt die sechste Ausgabe des Reports, wie Schweizer Organisationen DevOps nicht nur einführen, sondern durch Platform Engineering skalieren und mit KI ergänzen.\n","title":"DevOps in der Schweiz 2025: DevOps skalieren mit Plattformen und KI","type":"blogs"},{"content":"DevOps in Switzerland has reached a tipping point. Once a grassroots movement, it is now a strategic lever for digital resilience, efficiency, and innovation. The DevOps in Switzerland Report 2025, jointly produced by Zühlke and VSHN, presents clear signals of this transformation. Drawing from 184 survey responses, the sixth edition of the report reveals how Swiss organizations are not just adopting DevOps, but scaling it through platform engineering and augmenting it with AI.\n1. DevOps: A Strategic Standard # The report confirms what many practitioners experience daily: DevOps is the operational standard in Switzerland. Agile collaboration, cross functional ownership, and continuous delivery are now embedded across industries, from IT and banking to the public sector. However, success is no longer determined by tool adoption alone. Organizational culture, leadership alignment, and the ability to deliver at scale have become decisive.\n2. Platform Engineering: DevOps at Scale # Over half of Swiss organizations (54%) now have dedicated platform engineering teams. These teams are building internal developer platforms (IDPs) to reduce complexity and accelerate delivery. The key drivers?\nAutonomy and developer experience Faster innovation cycles Operational consistency through self service platforms While tools like Backstage are gaining traction, 40% of organizations still lack an IDP. The practice is maturing, but not yet universal. Interestingly, many adopters prioritize enablement over governance, highlighting the need to evolve platforms from technical systems into strategic products.\n“Platform engineering is no longer optional, it’s foundational.”\n3. Artificial Intelligence: From Hype to Copilot # AI is quietly becoming a DevOps copilot. One third of Swiss DevOps teams already use AI, especially in:\nCode review and quality assurance Architecture design support CI/CD automation Yet AI adoption remains uneven. Late stage lifecycle phases like testing, compliance, and security are still underexplored. Measurement, too, is inconsistent, only a few teams have defined clear KPIs for AI driven initiatives. Nonetheless, developer sentiment is overwhelmingly positive: 79% feel comfortable working with AI tools.\n4. Tooling: Dominant, but Diversifying # The Swiss DevOps stack continues to consolidate around key technologies:\nGitLab, Kubernetes, and Terraform remain dominant. Linux strengthens its hold as the production OS of choice. Argo CD and GitHub are on the rise, suggesting growing adoption of cloud native and GitOps practices. FinOps and MLOps are still early stage. Observability remains a cornerstone, with Grafana and Prometheus leading the way.\n5. The Culture Gap Persists # Despite technological maturity, cultural challenges remain. Top blockers include:\nLegacy systems and technical debt Resistance to change Talent shortages and unclear ownership As the report makes clear, DevOps success in 2025 is less about tools, and more about trust, leadership, and organizational design.\nOutlook: Where We Go Next # Looking ahead, the report identifies three emerging focal points:\nPlatforms as products, not just technical enablers AI augmented engineering across the full software lifecycle Outcome based measurement, moving beyond speed to value As Swiss enterprises face growing complexity and economic uncertainty, DevOps will remain the adaptive core of modern software delivery.\nThe future of DevOps is platform enabled, AI augmented, and outcome driven, but still powered by people.\nDownload the full report for detailed insights, data visualizations, and practical recommendations: https://www.vshn.ch/blog/jetzt-verfuegbar-devops-in-der-schweiz-report-2025/\n🎥 And don’t miss the release video for highlights, context, and behind the scenes perspectives from the authors.\n","date":"13 July 2025","externalUrl":null,"permalink":"/en/blogs/devops-in-switzerland-2025-scaling-devops-with-platforms-and-ai/","section":"Blogs","summary":"DevOps in Switzerland has reached a tipping point. Once a grassroots movement, it is now a strategic lever for digital resilience, efficiency, and innovation. The DevOps in Switzerland Report 2025, jointly produced by Zühlke and VSHN, presents clear signals of this transformation. Drawing from 184 survey responses, the sixth edition of the report reveals how Swiss organizations are not just adopting DevOps, but scaling it through platform engineering and augmenting it with AI.\n","title":"DevOps in Switzerland 2025: Scaling DevOps with Platforms and AI","type":"blogs"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/dsgvo/","section":"Tags","summary":"","title":"DSGVO","type":"tags"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/regulierung/","section":"Tags","summary":"","title":"Regulierung","type":"tags"},{"content":"KI skaliert rasant. Doch wer sich allein von Motivation treiben lässt, riskiert die Kontrolle zu verlieren. Hier setzt Governance an. In diesem Artikel zeigen wir, wie intelligente, schlanke Governance vom Hindernis zum Motor für unternehmensweiten Erfolg wird.\nDie richtige Governance als Schlüssel zur skalierbaren KI # KI versagt nicht im Labor. Sie scheitert in der Praxis, wenn die passende Governance fehlt. Denn sobald KI im echten Leben zum Einsatz kommt, beeinflusst sie Customer Journeys, steuert Entscheidungen und bringt neue regulatorische Risiken mit sich. Doch viele Unternehmen, die ihre KI-Initiativen skalieren wollen, stoßen auf eine unsichtbare Schwachstelle: fehlende effektive Governance.\nAktuelle Zahlen belegen das deutlich: Bis 2025 haben 42 % der Unternehmen den Großteil ihrer KI-Initiativen eingestellt. Das entspricht einem Anstieg von 17 % gegenüber 2024. Im Durchschnitt wurden 46 % der Proofs of Concept (PoCs) nie in die Praxis übertragen.\nDiese Governance-Lücke verursacht ein gefährliches Ungleichgewicht: Für sich betrachtet wirken viele PoCs vielversprechend. Aber ohne Koordination, Verantwortung und Überblick bleibt ihr Mehrwert auf einzelne Projekte beschränkt. Noch kritischer: Wenn KI ohne Governance skaliert wird, drohen dem Unternehmen:\nReputations- und regulatorische Risiken Kostenintensive Nacharbeiten durch fragmentierte Architekturen Ethische Grauzonen und inkonsistente Abläufe Unsicherheit auf Führungsebene durch fehlende Transparenz und Kontrolle Führungskräfte erkennen zunehmend: Das größte Hindernis für Wertschöpfung ist nicht die Technologie, sondern mangelnde Koordination und Steuerung. Die Lösung: Governance, die Skalierung ermöglicht, ohne den Fortschritt auszubremsen. Governance und Agilität sind dabei kein Widerspruch, ganz im Gegenteil: Sie können sich gegenseitig stärken.\nGovernance hat zwei Dimensionen # Wirksame Governance ist mehr als nur das Abhaken einer Checkliste. Sie ist ein strategisches Steuerungsinstrument, das auf zwei ineinandergreifenden Ebenen wirkt:\n1. Operative Ausrichtung # Governance sorgt dafür, dass KI-Initiativen eng mit den Unternehmenszielen verknüpft sind. Durch ihre Integration in den KI-Lebenszyklus können Organisationen:\nMessbare Erfolge erzielen: Eine effektive Governance beginnt mit der klaren Definition strategischer Ziele und KPIs Kohärenz sichern: Standardisierte Protokolle verhindern Silodenken und redundante Prozesse Agil bleiben: Adaptive Governance-Modelle erlauben schnelle Anpassungen an Veränderungen am Markt oder im Unternehmen Zusammenarbeit fördern: Klare Richtlinien und gemeinsame Ziele stärken funktionsübergreifende Teams 2. Ethik und Compliance # Governance Frameworks sind essenziell, um ethische Standards zu wahren und regulatorische Anforderungen zu erfüllen. Dadurch können Unternehmen:\nObjektivität fördern: Regelmäßige Audits, integrierte Kontrollmechanismen und transparente Algorithmen helfen, das Auftreten von Verzerrungen zu erkennen und zu korrigieren Datenschutz sichern: Robuste Prozesse rund um Daten schützen sowohl personenbezogene Daten (z. B. DSGVO) als auch vertrauliche Informationen Verantwortungsbewusstsein stärken: Klar definierte Rollen und Zuständigkeiten (zwischen Menschen sowie zwischen Mensch und KI) machen Ethik zum Kernbestandteil von Entwicklung und Betrieb Vertrauen aufbauen: Transparente, gut gesteuerte KI-Prozesse stärken das Vertrauen von Mitarbeitenden und Stakeholdern, fördern Akzeptanz und motivieren Teams Stellschrauben für erfolgreiche, unternehmensweite KI-Governance # Governance muss leicht genug sein, um die Umsetzung von KI-Projekten nicht zu behindern, aber robust genug, um Sicherheit und Skalierung zu ermöglichen. Führende Unternehmen setzen dabei auf vier Kernprinzipien:\nIntegrierte Überwachung und kontinuierliches Monitoring Governance wird in bestehende Prozesse integriert: Automatisiertes Monitoring, Compliance-Prüfungen und menschliche Aufsicht schaffen Transparenz in Echtzeit über die Performance von KI-Systemen. Das ermöglicht schnelle Eingriffe bei gleichzeitiger Agilität und Compliance.\nSkalierbare Frameworks Modulare Governance-Strukturen erlauben die Anpassung an unterschiedliche Skalierungs-und Komplexitätsstufen. Diese Flexibilität ist entscheidend, um verschiedene Projekte und sich verändernde Bedarfe effizient zu steuern.\nInterdisziplinäre Zusammenarbeit Governance braucht die Expertise unterschiedlicher Kompetenzträger: Technische Expert:innen, Jurist:innen und Compliance-Verantwortliche bilden gemeinsam Teams, die KI ganzheitlich steuern. Das fördert fundierte Entscheidungen und umfassende Kontrolle.\nEinheitliche Werkzeuge und Standards Wildwuchs bei Plattformen reduziert die Effizienz. Gemeinsame Tools und Protokolle erleichtern die teamübergreifende Zusammenarbeit und beschleunigen den Rollout.\nStandardisierte Workflows verringern Reibung, etwa durch On-Premise-LLMs, die sensible Daten sicher verarbeiten, oder integrierte Feedback-Mechanismen, die kontinuierliche Modellverbesserung ohne manuelles Eingreifen ermöglichen.\nGovernance in der Praxis: So setzt man sie richtig um # Zuverlässige KI-Steuerung bedeutet nicht, Innovation zu bremsen, sondern sie so zu gestalten, dass sie skalierbar wird. Führende Organisationen verstehen Governance nicht als nachgelagerte Kontrolle, sondern als integralen Bestandteil ihrer Entwicklungsprozesse.\nGovernance nahtlos integrieren # Die Steuerung von KI sollte sich natürlich in den Arbeitsfluss einfügen. Leichtgewichtige Kontrollen wie automatisierte Dokumentation, rollenbasierte Zugriffskontrolle und automatische Prüfmechanismen sichern Nachvollziehbarkeit, ohne Teams auszubremsen. Beispiel: Die Bereitstellung eines Modells sollte nicht durch Papierkram verzögert werden, sondern automatisch auditierbare Metadaten generieren.\nWiederverwendbare Patterns statt Einzellösungen # Ohne Standardisierung wird Enterprise-KI schnell unübersichtlich. Governance-Bausteine wie Ethik-Checklisten, Datenqualitätsprüfungen und Templates für Decision Logging sparen Zeit und vermeiden Reibungsverluste, besonders bei interdisziplinärer Zusammenarbeit über Abteilungen und Branchen hinweg.\nGemeinsame Definition von Governance schaffen # Effektive Governance gibt es nicht von der Stange. Für das eine Unternehmen bedeutet sie Nachvollziehbarkeit von Empfehlungen, für ein anderes Datenschutzkonformität oder menschliche Kontrolle. Wichtig ist, dass alle ein gemeinsames Verständnis über Definition und Umsetzung teilen. Führende Unternehmen setzen dafür auf Playbooks und skalierbare Frameworks für Freigabe, Monitoring und Weiterentwicklung.\nFeedbackschleifen treiben Verbesserung an # Governance ist kein Warnsystem, sondern ein Werkzeug für Fortschritt: integrierte Feedbackschleifen etwa aus Nutzungsanalysen, User Feedback oder Modellabweichungen können effektiv genutzt werden.\nSie fließen direkt in die Produkt- und Modellentwicklung ein und ermöglichen es, Systeme kontinuierlich und sicher weiterzuentwickeln. So bleibt KI dauerhaft relevant, wirksam und gesetzeskonform, auch in einem sich wandelnden regulatorischen Umfeld.\nWie Zühlke skalierbare, nahtlose Governance ermöglicht # Zühlke ist überzeugt: Governance muss man von Anfang als Treiber für Innovation und Sicherheit mitdenken. In einem Cybernetic Enterprise ist KI-Governance nicht Kontrollinstanz, sondern ein Enabler: Sie befähigt Menschen und Maschinen, gemeinsam über Feedback, Verantwortung und Design zu wachsen.\nMit unserer Cybernetic Delivery Platform (CDP) unterstützen wir Unternehmen bei der Umsetzung mit:\nModularer, sicherer Infrastruktur, die sich am individuellen Bedarf Ihres Unternehmens orientiert Bewährten Governance-Frameworks, die mit dem KI-Reifegrad mitwachsen Menschzentrierter Steuerung für Erklärbarkeit, Verantwortungsbewusstsein und Vertrauen Branchenspezifischen Acceleratoren wie ZenAI und ZAG für schnelle, regelkonforme Umsetzung Die CDP ermöglicht eine sichere, verantwortungsvolle und skalierbare Einführung von KI, ohne Eingriffe in bestehende Abläufe oder Infrastruktur.\nSie möchten wissen, wie Governance bei Ihnen skalierbar wird?\nKontaktieren Sie unser Team für ein unverbindliches Gespräch mit unseren Senior Consultants. Entdecken Sie neue Perspektiven und individuelle Lösungsansätze für Ihre Herausforderungen.\nOrigial Artikel: https://www.zuehlke.com/en/insights/ai-risk-management-turning-governance-into-a-driver-of-long-term-success\n","date":"8. July 2025","externalUrl":null,"permalink":"/de/blogs/risiken-von-ki-minimieren-mit-governance-zum-langfristigen-erfolg/","section":"Blogs","summary":"KI skaliert rasant. Doch wer sich allein von Motivation treiben lässt, riskiert die Kontrolle zu verlieren. Hier setzt Governance an. In diesem Artikel zeigen wir, wie intelligente, schlanke Governance vom Hindernis zum Motor für unternehmensweiten Erfolg wird.\n","title":"Risiken von KI minimieren: Mit Governance zum langfristigen Erfolg","type":"blogs"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/risiko/","section":"Tags","summary":"","title":"Risiko","type":"tags"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/unternehmensleitung/","section":"Tags","summary":"","title":"Unternehmensleitung","type":"tags"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/verantwortung/","section":"Tags","summary":"","title":"Verantwortung","type":"tags"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/vertrauen/","section":"Tags","summary":"","title":"Vertrauen","type":"tags"},{"content":"AI is scaling fast, but without the right governance, ambition can outpace control. In this article, we explore how smart, streamlined oversight turns governance from a blocker into a catalyst for enterprise-wide success.\nScaling AI in business: Bridging the governance gap # AI doesn’t fail in the lab; it fails in production when governance is missing. As new projects move into production, AI begins to influence customer journeys, drive decisions, and introduce new regulatory risks. It’s here where many businesses encounter a hidden fault line: the absence of effective AI governance.\nCurrent statistics show that by the start of 2025, 42% of companies had already abandoned most of their AI initiatives, up from 17% in 2024. And on average, organisations had discontinued some 46% of their AI proof-of-concepts before they ever reached production.\nThis governance gap creates a dangerous imbalance. Isolated proofs of concept (POCs) show promise, but without coordination, accountability or oversight, things rarely evolve from individual gains to enterprise-level impact.\nWorse still, scaling AI for business without governance can expose the business to:\nReputational and regulatory risk Costly rework from fragmented architectures Ethical blind spots and operational inconsistency Leadership uncertainty due to lack of transparency and control C-suites are beginning to realise a key truth: the biggest blocker to value isn’t AI capability, but the lack of coordination and control. Solving this requires effective governance that enables scale without disrupting progress. Governance and agility aren’t mutually exclusive concepts, and they can actually nurture one other on the way to successful AI implementation.\nThe two dimensions of governance # Effective AI governance isn’t just a checklist; it’s a strategic lever that operates on two interdependent planes:\n1. Operational alignment # Effective governance ensures that AI initiatives are closely aligned with business objectives. By embedding governance into the AI lifecycle, organisations can:\nSupport measurable business outcomes: Control frameworks are anchored to strategic goals and KPIs. Ensure consistency: Standardised protocols across teams prevent siloed developments and redundant efforts. Enhance agility: Adaptive governance frameworks allow for rapid adjustments in response to market changes or internal shifts. Facilitate collaboration: Clear guidelines and shared objectives foster cross-functional teamwork, essential for successful AI integration. 2. Ethics and compliance # Beyond operational benefits, governance frameworks are pivotal in upholding ethical standards and ensuring regulatory compliance. By taking this approach, your organisation will:\nPromote equitable and objective outcomes: Regular audits, embedded control mechanisms and transparent algorithms help in identifying and correcting biases. Protect privacy with secure and ethical data management: Robust data handling protocols protect personal data governed by regulations (like GDPR) alongside other confidential or sensitive business information. Foster a culture of responsible action: Defined roles and responsibilities (between humans and AI) ensure that ethical considerations become integral to AI development and deployment. The result is safe human-AI collaboration that keeps people in control. Strengthen confidence through transparency: Transparent, well-governed AI practices foster trust among employees and stakeholders. This strengthens adoption, long-term acceptance and motivation in the workforce. Key success factors for enterprise-ready AI governance # AI governance must be lightweight enough to enable delivery, but robust enough to scale safely. The most advanced organisations in this space focus on four core principles:\nIntegrated oversight and continuous monitoring Embedding governance into existing workflows, through automated monitoring, compliance checks and human oversight, ensures real-time visibility into AI performance. This enables fast intervention, keeping operations agile and compliant.\nScalable frameworks Modular governance structures are useful as they allow organisations to adapt to varying scales and complexities of AI deployments. This flexibility enables more diverse projects and helps meet evolving business needs.\nCross-functional collaboration Establishing interdisciplinary teams that include technical experts, legal advisors and compliance specialists ensures a holistic approach to AI governance. This collaboration promotes comprehensive oversight and informed decision-making.\nUnified tooling and standards Avoiding platform sprawl cuts complexity and cost, while shared protocols across teams streamline collaboration and accelerate delivery. Standardised workflows, meanwhile, reduce friction, making it easier to scale AI securely and efficiently.\nAn on-premises LLM, for instance, may offer a controlled environment for handling sensitive data, without compromising speed of delivery. Likewise, embedded feedback mechanisms ensure models evolve without constant manual intervention.\nAI governance in action: What best practice looks like # Implementing effective governance doesn’t mean halting innovation. It just requires reframing how AI delivery is structured. So, rather than treating governance as a gatekeeper at the end of the pipeline, forward-thinking organisations build it into the fabric of delivery from day one, making it a well-supervised driver of business value.\nHere’s how you can do the same, in four straightforward steps:\nIntegrate governance seamlessly # AI governance in business should feel like a natural part of the flow, not an obstacle. Integrating lightweight controls into existing delivery pipelines, like automated documentation, role-based access controls and model validation gates, keeps teams focused while maintaining accountability.\nDeploying a model shouldn\u0026rsquo;t be blocked by paperwork; it should generate auditable metadata automatically.\nUse reusable patterns, not one-off workarounds # Enterprise AI can quickly become chaotic without consistency. Standardising governance components based on best practices, like ethics checklists, data quality assessments and decision-logging templates, allows teams to move faster while reducing rework and fragmentation.\nThis is particularly effective when multidisciplinary teams cooperate to scale solutions across departments or markets.\nAlign on what ‘governed delivery’ means for your business # Governance depends on context. For some, it might mean ensuring AI recommendations are traceable. For others, it’ll be about cross-border data compliance or human-in-the-loop safeguards. What matters here is aligning business units and technical teams on a shared operational definition, and embedding that into daily practices.\nLeading organisations often operationalise this through governance playbooks and scalable frameworks for approval, monitoring and iteration.\nBuilt-in feedback loops drive iteration # Good governance doesn\u0026rsquo;t just flag issues, it drives improvement. Integrated feedback loops (including usage analytics, user feedback and model drift alerts) should feed directly into product and model evolution, enabling systems to adapt safely over time.\nContinuous adaptability strengthens your long-term resilience, helping systems stay reliable, relevant and effective, even in evolving legal and regulatory landscapes.\nCybernetic thinking: How Zühlke enables seamless, scalable governance # At Zühlke, we believe that AI governance should be baked in from day one to support both innovation and assurance. That’s because we know that in a truly cybernetic enterprise, governance isn’t just about control; it’s about empowering people and machines to evolve together through feedback, responsibility and design.\nThrough our Cybernetic Delivery Platform (CDP), we help organisations implement:\nModular, secure delivery infrastructure tailored to your enterprise needs Proven governance frameworks that scale with your AI maturity Human-centred oversight ensuring explainability, accountability, and trust Industry-specific accelerators, such as ZenAI and Zühlke Augmented Generation (ZAG), that speed up compliant AI implementation The CDP enables teams to deliver AI securely, responsibly, and at scale, without disrupting existing operations or infrastructure.\nWant to learn how the CDP unlocks governance at scale?\nOrigial article: https://www.zuehlke.com/en/insights/ai-risk-management-turning-governance-into-a-driver-of-long-term-success\n","date":"8 July 2025","externalUrl":null,"permalink":"/en/blogs/ai-risk-management-turning-governance-into-a-driver-of-long-term-success/","section":"Blogs","summary":"AI is scaling fast, but without the right governance, ambition can outpace control. In this article, we explore how smart, streamlined oversight turns governance from a blocker into a catalyst for enterprise-wide success.\n","title":"AI risk management: turning governance into a driver of long-term success","type":"blogs"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/risikomanagement/","section":"Tags","summary":"","title":"Risikomanagement","type":"tags"},{"content":"Während die KI-Einführung zunimmt, sind viele Unternehmen nicht in der Lage, zu skalieren. Die Lösung? Externe Governance. Durch die Integration von Compliance, Transparenz und Verantwortlichkeit in den Kern von KI-Initiativen können Führungskräfte Governance in einen Katalysator für Innovation, Vertrauen und nachhaltiges Wachstum verwandeln.\nKI steht an einem Wendepunkt: Pilotprojekte zeigen Wirkung, doch auf Unternehmensebene gerät der Fortschritt ins Stocken. Der Grund: Es fehlt an Vertrauen. Vorausschauende Führungskräfte drehen die Logik um und verankern Compliance und Transparenz von Anfang an. Damit sichern sie sich entscheidende Vorteile: sie behalten die Kontrolle, steigern die Akzeptanz und minimieren regulatorische Risiken. Ohne KI-Governance droht der Aufbruch in die KI-Welt in fragmentierte Einzellösungen zu zerfallen.\nDer Schlüssel liegt für Budgetverantwortliche und Projektteams in einem Governance-first-Ansatz, der von Anfang an klare Strukturen schafft und KI-Projekte strategisch mit Geschäftszielen verbindet. So entsteht ein messbarer Mehrwert fürs Unternehmen. Sicher, verantwortungsbewusst und skalierbar.\nIntegriert, nicht nachgerüstet: KI-Governance von Beginn an mitdenken # KI-Governance proaktiv einzubinden fördert strategische Kohärenz, Skalierbarkeit und minimiert unnötige Tool-Redundanzen. Ineffizienzen und Dopplungen werden deutlich reduziert, damit werden Prozesse schlanker, Entscheidungen schneller. Gleichzeitig sinkt das Risiko für regulatorische Verstöße, weil juristische und ethische Leitlinien von Anfang an berücksichtigt werden.\nWerden zentrale Kennzahlen wie Fehlerquoten, Kosten oder CO₂-Emissionen zudem kontinuierlich, automatisiert und auf Projekt oder Verantwortliche zugeschnitten dargestellt, behalten Teams jederzeit die Kontrolle und können bei Bedarf sofort eingreifen.\nEine integrierte Governance-Struktur schafft also einheitliche Prozesse für Deployment, Monitoring und Zuständigkeiten, eine wertvolle Basis für die unternehmensweite Skalierung und den nachhaltigen Erfolg.\nHier gilt das Prinzip: Einmal entwickeln, überall einsetzen. Diese konsistente Herangehensweise reduziert den Aufwand für Audits, erhöht die Transparenz und schafft eine einheitliche Datenbasis. Das Ergebnis: schnellerer Fortschritt bei voller Compliance.\nVom Betrieb zum ROI: Qualität sichern, Risiken minimieren, Mehrwert generieren # Unternehmen suchen nach Wegen, KI-Projekte schneller umzusetzen, Systeme stabiler zu machen sowie deren Sicherheit und Zuverlässigkeit gemäß entsprechenden Normen zu gewährleisten.\nWas ist dafür konkret erforderlich?\nKI mit Business-Zielen verknüpfen: Jedes KI-Projekt braucht eine klare Verknüpfung mit strategischen oder operativen Geschäftszielen, messbar über konkrete KPIs. Tool-Wildwuchs verhindern: Governance-first ermöglicht einheitliche Prozesse und nachhaltige Strukturen. Unkoordinierte Einzelmaßnahmen werden vermieden. Zusammenarbeit standardisieren: Interdisziplinäre Teams brauchen gemeinsame Playbooks und Self-Service-Umgebungen. Damit braucht es weniger Übergaben, die Zusammenarbeit läuft flüssiger. Agilität sichern: Die KI-Modelle müssen mit dynamischen Markt- und Unternehmensanforderungen mitwachsen, zum Beispiel über technische Kontrollmechanismen und Human-in-the-loop-Überwachung, die sicherstellt, dass der Mensch immer die letzte Instanz bleibt. Piloten skalieren: Governance-Frameworks verhindern eine „PoC-Paralyse“. So wird KI für die Praxis nutzbar. Technische Disruptionen vermeiden: Erfahrene Partner integrieren sich nahtlos in bestehende Tech-Stacks oder bieten bei Bedarf maßgeschneiderte End-to-End-Lösungen, stets im Zusammenspiel mit anderen Partnern und der bestehenden IT. Compliance als Wettbewerbsvorteil: mehr Sicherheit, ohne langsamer zu werden # Vertrauen schaffen und Risiken reduzieren, ohne Tempoverlust, das ist die Herausforderung. Das Ziel, KI-Governance effizient und zukunftssicher zu integrieren, so dass sie sich nahtlos in bestehende Systeme einfügt, erreicht man, wenn man die richtigen Prinzipien verfolgt.\nZunächst gilt es, klare Ziele zu setzen, um messbare Ergebnisse zu realisieren. Dabei ist es entscheidend, über alle Funktionen hinweg eindeutige Verantwortlichkeiten zu etablieren: sei es zur Steigerung des Umsatzes, zur Erhöhung der Effizienz oder zur Minimierung von Risiken.\nEin weiterer zentraler Hebel ist die Automatisierung: Durch den Einsatz bewährter Designmuster, die Automatisierung wiederkehrender Aufgaben und den gezielten Einsatz praxiserprobter KI-Agenten, lassen sich Projekte beschleunigen, Kosten kontrollieren und nachhaltig senken. So gewinnen Teams wertvolle Zeit für strategisch wichtigere Aufgaben mit größerem Impact.\nEin Beispiel aus der Praxis: Für unseren Kunden, ein Finanzinstitut, war es besonders wichtig, die Kosten im Zusammenhang mit dem Betrieb, der Nutzung oder der Entwicklung seiner digitalen Systemlandschaft jederzeit im Blick zu behalten.\nUnsere Cybernetic Delivery Platform (CDP) überwacht automatisiert Applikationen im Live-Betrieb. Ein konfigurierbares Dashboard ermöglicht es Verantwortlichen, Fehlerzustände direkt zu erkennen oder automatisch beheben zu lassen, inklusive klarer Zuständigkeiten. Das sorgt für Vertrauen, Transparenz und Effizienz.\nStrukturierte Skalierbarkeit für langfristigen Erfolg # Schließlich braucht es eine kontrollierte, strukturierte Skalierung. Industrielle Standards in der KI-Implementierung sorgen dafür, dass sich KI-Initiativen auch bei wachsendem Umfang und zunehmender Komplexität beherrschbar skalieren lassen, und KI-Projekte langfristig erfolgreich sind.\nEbenso wichtig ist es, Veränderungen frühzeitig zu adressieren: Egal wie durchdacht ein System heute ist, Normen, Marktbedingungen und der globale Kontext entwickeln sich weiter. Tools, die dabei helfen, Risiken rechtzeitig zu erkennen und flexibel zu reagieren, sind der Schlüssel für langfristigen Erfolg.\nMit skalierbarer Governance zu messbarem KI-Mehrwert # KI-Governance ist kein Bremsklotz, sondern die operative Grundlage für KI-Skalierung. Richtig umgesetzt, macht sie aus Kostenstellen wertschöpfende Prozesse und stärkt gleichzeitig die Resilienz.\nUm KI-Projekte mit messbarem Mehrwert und ohne Einbußen ans Ziel zu bringen, benötigt man fundierte Erfahrung, technologische Kompetenz und geeignete Werkzeuge.\nUnsere Cybernetic Delivery Platform (CDP) ist die modulare Grundlage für industrialisierte KI. Unterstützt durch die Cybernetic Delivery Method™ (CDM), und weiteren KI-Acceleratoren (z.B. ZenAI oder ZAG) können maximal flexibel, je nach individuellen Bedürfnissen, weitere sichere Lösungen geliefert werden.\nNahtlose Integration: Ihr KI-Acceleratorvon Zühlke # Damit gelingt es:\nKI-Projekte von Anfang an mit konkreten Zielen zu verknüpfen, Bestehende Systeme zu integrieren oder End-to-End neu aufzusetzen, je nach Bedarf, Mit einem vertrauenswürdigen Partnernetzwerk ohne Vendor Lock-in zu arbeiten, Und regulatorische Anforderungen wie EU AI Act, DSGVO oder branchenspezifische Vorgaben sicher einzuhalten. Zum Abschluss ein konkreter Blick in die Praxis # Finanzsektor zeigt sich, wie CDP im Alltag wirkt: Offene Logs werden kontinuierlich im Live-Betrieb von CDP überwacht. Ein flexibel konfigurierbares Dashboard liefert den zuständigen Teams genau die Informationen, die sie brauchen, ob zur gezielten Überwachung oder zur automatisierten Fehlerbehebung. So bleibt der Betrieb nicht nur stabil, sondern auch effizient und zukunftssicher.\nZühlke lebt KI sowohl intern als auch mit seinen Kund:innen: wir beseitigen Reibungspunkte, schaffen Freiräume und fördern gezielt Innovation. Risiken? Ja, die gibt es. Aber mit der richtigen Governance wird KI zum nachhaltigen Treiber für Innovation, Vertrauen und Performance.\nOriginal Artikel: https://www.zuehlke.com/en/insights/secure-ai-governance-scalable-delivery-zero-disruption\n","date":"8. July 2025","externalUrl":null,"permalink":"/de/blogs/sichere-ki-governance-skalierbare-umsetzung-ohne-reibungsverluste/","section":"Blogs","summary":"Während die KI-Einführung zunimmt, sind viele Unternehmen nicht in der Lage, zu skalieren. Die Lösung? Externe Governance. Durch die Integration von Compliance, Transparenz und Verantwortlichkeit in den Kern von KI-Initiativen können Führungskräfte Governance in einen Katalysator für Innovation, Vertrauen und nachhaltiges Wachstum verwandeln.\n","title":"Sichere KI-Governance: Skalierbare Umsetzung ohne Reibungsverluste","type":"blogs"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/sicherheit/","section":"Tags","summary":"","title":"Sicherheit","type":"tags"},{"content":"","date":"8. July 2025","externalUrl":null,"permalink":"/de/tags/skalierbarkeit/","section":"Tags","summary":"","title":"Skalierbarkeit","type":"tags"},{"content":" KI ist allgegenwärtig, doch Klarheit, Strategie und echter Nutzen fehlen oft. Wir leben im, wie Romano Roth es formuliert, Zeitalter der „KI-Idioten“, in dem flashy Demos den echten Nutzen überstrahlen. Doch es gibt einen smarteren Weg. Erfahren Sie, wie das Cybernetic Enterprise echten Mehrwert für industrielle Unternehmen schafft.\n\u0026ldquo;Lassen Sie sich nicht täuschen. Vom ‚ChatGPT-Cowboy‘ bis zum politisch motivierten Schnellschuss, der KI-Hype ist überall.\u0026rdquo; - Romano Roth, Zühlke Global Chief of Cybernetic Transformation \u0026amp; Partner\nKein Spott, sondern ein Weckruf für die Industrie # Der Begriff „KI-Idioten“ ist bewusst provokant gemeint, aber nicht verletzend. Er soll Entscheider:innen der Industrie aufrütteln. Gemeint sind gut gemeinte, aber fehlgeleitete KI-Initiativen ohne den Gesamtblick, was es für den Erfolg braucht: Systemdenken, kulturellen Wandel und strategische Einbettung.\nVon der voreiligen ChatGPT-Integration bis zum KI-Washing im Vorstand, zu viele Unternehmen setzen auf KI als schnellen Problemlöser statt als langfristigen Transformationsenabler. Dieser Artikel zeigt, wie man den Hype hinter sich lässt und echte, nachhaltige Veränderung schafft, mit dem Cybernetic Enterprise.\nDie „AI-first“-Illusion: Warum der Hype zum Scheitern verurteilt ist # Künstliche Intelligenz zählt zweifellos zu den wichtigsten technologischen Entwicklungen unserer Zeit. Doch viele Unternehmen scheinen ihre Initiativen derzeit eher hektisch als strategisch anzugehen. Vor allem in der Industrie wird KI als Allheilmittel gefeiert, mit massiven Investitionen in „AI-first“-Initiativen und schnell umgesetzte Prototypen. Doch der ROI bleibt oft aus, besonders dort, wo Stabilität wichtiger ist als Experimente. Wichtig ist zu verstehen, auch diese Technologie hat ihre Grenzen:\nKI kann optimieren, unterstützen, analysieren, aber sie verbesserte keine fehlerhaften Prozesse, keine Entscheidungsstrukturen und keine Unternehmenskultur. Wer auf KI als Alleinlösung setzt, wird enttäuscht.\nStandardaufgaben, wie einfaches Coden, lassen sich automatisieren. Doch der wahre Wert liegt dort, wo KI nicht hinkommt: bei menschlichem Urteilsvermögen, Kontextverständnis, Empathie und Kreativität.\nDie Zukunft ist nicht „AI-first“, sondern menschenzentriert und von KI unterstützt. Das bedeutet: KI dient den Zielen der Menschen, erweitert deren Fähigkeiten und beschleunigt Wertschöpfung, aber die Richtung geben weiterhin die Menschen vor.\nCybernetic Enterprise: Das Unternehmensmodell der Zukunft # Das Cybernetic Enterprise ist Betriebsmodell und Mindset zugleich. Inspiriert vom griechischen Wort für Steuermann, betrachtet es Unternehmen als dynamische Systeme mit Rückkopplung zwischen Mensch, Technologie und Prozessen (siehe Abbildung).\nWesentliche Ziele des Cybernetic Enterprise sind:\nLangfristige Anpassungsfähigkeit Kontinuierliches Lernen Nachhaltige Wertschöpfung KI muss integriert sein, kein Add-on # In diesem Model wird KI wird nicht nachträglich angeflanscht, sondern tief in die DNA der Organisation und in ihre Prozesse integriert. Sie unterstützt die Produktentwicklung, den operativen Betrieb, die Entscheidungsfindung und das Kundenerlebnis als Teil einer einheitlichen Strategie.\nEin konkretes Beispiel: Zühlkes Cybernetic Delivery Platform (CDP), eine modulare, standardbasierte Plattform, die KI-Acceleratoren (KI-Beschleuniger) über den gesamten Lebenszyklus hinweg integriert. Sie bietet Self-Service-Automatisierung, Analysen und KI-as-a-Service, und steigert die Produktivität in der Industrie in echten Projekten um 30-50 %.\nDer Mensch als Basis für smarte KI in der Industrie: Die 3 Säulen der Cybernetic Transformation # Ohne menschenzentriertes Betriebsmodell ist jede KI-Strategie unvollständig. Das Cybernetic Enterprise basiert nicht allein auf Technologie. Es lebt von der Interaktion zwischen Menschen, Prozessen und Plattformen. Drei eng miteinander verknüpfte Säulen sorgen dafür, dass KI nicht nur kurzfristige Effekte bringt, sondern nachhaltigen Erfolg.\nMehr als nur Ausführende: Die Transformation zum Cybernetic Enterprise betrifft alle Rollen, nicht nur die von Softwareingenieur:innen. Egal, ob Shopfloormitarbeitende, Data Analysten, Domainfachleute oder technische Leitende, der Erfolg in KI-basierten Umgebungen erfordert mehr als nur die Ausführung von Aufgaben. Es geht darum, die Komplexität zu beherrschen, in Feedbackschleifen zu denken und die Disziplinen zu verbinden. Kurz gesagt: ein Wechsel von funktionalen Spezialisten zu systembewussten, problemlösenden Mitarbeitenden.\nNeues Skillset: Entscheidend ist „Cybernetic Thinking”, also die Fähigkeit, Technologie, Prozesse und Organisation als lernfähiges System zu begreifen. Kreativität, kritisches Denken und Empathie werden genauso wichtig wie technisches Know-how.\nEmpowerment: Die Teams müssen ihre Produkte selbst verantworten, iterativ arbeiten und Entscheidungen dort treffen, wo das Wissen sitzt, nicht auf einer entfernten Managementebene. Dies ermöglicht mehr Geschwindigkeit, Relevanz und Verantwortlichkeit.\nKontinuerliche Wertschöpfung: Das Cybernetic Enterprises schafft Prozesse, die sich durch Feedback optimieren. Das fördert eine Kultur des ständigen Lernens und der stetigen Verbesserung.\nAgil und anpassungsfähig: Agile Prinzipien kombiniert mit selbstlernenden Systemen halten Teams flexibel und kundenorientiert.\nProduktivität messbar steigern: Mit AI-basierten Plattformen wie Zühlkes Cybernetic Delivery Platform lassen sich messbare Ergebnisse erzielen: In unseren Projekten ist die Entwicklungseffizienz bereits um 30 % gestiegen, mit Potenzial bis 50 %.\nKI-Acceleratoren: Sogenannte KI-Beschleuniger sind modulare Tools und Komponenten, die Intelligenz in alle Schritte der Softwareentwicklung und des Betriebs einbringen.\nDigitalisierung demokratisieren: Mit KI-gestützter Entwicklung können Unternehmen jeder Größe, nicht nur die Tech-Giganten, die Digitalisierung kostengünstig und effektiv skalieren. Dies ebnet das Spielfeld, insbesondere für KI in der Produktion und in Industrieumgebungen\nDie Zukunft gestalten: KI in der Industrie braucht neue Kompetenzen # Erlauben Sie mir, eine weit verbreitete Sorge auszuräumen: KI wird keine Jobs ersetzen, sie wird sie verändern. Und genau dadurch entsteht eine neue Lücke auf dem Talentmarkt, nicht trotz, sondern wegen KI. In dem Maße, wie Maschinen Routineaufgaben übernehmen, wird der Bedarf an spezialisierten menschlichen Fähigkeiten, die KI strategisch, ethisch korrekt und effektiv einsetzen können, rapide steigen.\nUm dem gerecht zu werden, müssen Industrieunternehmen heute Verantwortung übernehmen und aktiv die Fachkräfte von morgen mitgestalten. Wir müssen die Ausbildung, Schulung und Weiterentwicklung von Fachkräften neu denken. Immer neue Tools sind nicht die Lösung. Was wir brauchen, sind neue Formen der Ausbildung und gezielte Weiterbildungsprogramme: Neue Lernformate, gezielte Weiterbildungen und Räume zum Ausprobieren sind essenziell.\nDer Gewinn für Unternehmen? Sie fördern nicht nur fachliche Kompetenzen, sondern auch die Loyalität. Mitarbeitende, denen der Raum für Lernen und Weiterentwicklung geboten wird, sind eher bereit, sich zu engagieren und Veränderungen anzuführen. Indem sie Talente befähigen, sich in KI-gestützten Umgebungen zu entfalten, schaffen Unternehmen nicht nur eine zukunftsfähige Belegschaft, sondern auch eine wandlungsfähige Kultur.\n„ Die Zukunft von KI in der Industrie wird nicht von Tools bestimmt, sondern von Führungskräften, die systemisch denken.“ - Romano Roth, Zühlke Global Chief of Cybernetic Transformation \u0026amp; Partner\nJenseits des Hypes: Der Mensch im Mittelpunkt von KI in der Industrie # Das Cybernetic Enterprise ist mehr als nur ein Buzzword. Es ist ein Appell für eine neue Arbeits- und Denkweise, die über kurzfristige Sprints hinausgeht und ein nachhaltiges, resilientes und anpassungsfähiges Unternehmensmodell schafft:\nDie Zukunft ist nicht „AI-first“.\nSie ist Human-led and AI-enabled.\nZühlke unterstützt Unternehmen auf diesem Weg, von der Entwicklung intelligenter Plattformen bis zur Gestaltung lernfähiger Teams und Organisationen für nachhaltigen Erfolg.\nSie möchten KI in Ihrer Organisation einsetzen, Ihr Betriebsmodell umgestalten oder Ihre Teams für die Zukunft wappnen? Dann würde ich mich freuen, von Ihnen zu hören.\nMelden Sie sich gerne bei mir, ich freue mich auf ein Gespräch. # Original Artikel: https://www.zuehlke.com/en/insights/cybernetic-enterprise-industrial-sector\n","date":"8. July 2025","externalUrl":null,"permalink":"/de/blogs/cybernetic-enterprise-vom-industrial-ai-hype-zu-langfristigem-nutzen/","section":"Blogs","summary":" KI ist allgegenwärtig, doch Klarheit, Strategie und echter Nutzen fehlen oft. Wir leben im, wie Romano Roth es formuliert, Zeitalter der „KI-Idioten“, in dem flashy Demos den echten Nutzen überstrahlen. Doch es gibt einen smarteren Weg. Erfahren Sie, wie das Cybernetic Enterprise echten Mehrwert für industrielle Unternehmen schafft.\n","title":"Cybernetic Enterprise: Vom Industrial AI Hype zu langfristigem Nutzen","type":"blogs"},{"content":"As AI adoption accelerates, many organisations find themselves unable to scale. The solution? Embedding governance from the outset. By integrating compliance, transparency, and accountability into the core of AI initiatives, leaders can transform governance into a catalyst for innovation, trust, and sustainable growth.\nAI is at a crossroads. Pilot projects are delivering results, but progress at the enterprise level is faltering. Why? A lack of trust. So forward-thinking leaders are flipping the script, embedding compliance and transparency from the outset. This shift secures a few vital advantages: control, greater acceptance and reduced regulatory risk. Without this AI governance, the journey into the AI landscape risks fragmenting into isolated one-off solutions.\nFor budget owners and project teams, the key lies in a governance-first approach that establishes clear structures from the start and aligns AI initiatives with business objectives. The result: tangible value for the organization that’s secure, responsible and scalable.\nIntegrated, not retrofitted: Embedding AI governance from day one # Proactively integrating AI governance promotes strategic alignment and scalability, and helps eliminate redundant tooling. It reduces inefficiencies and duplication, streamlining processes and accelerating decision-making. At the same time, the risk of regulatory breaches decreases because legal and ethical guidelines are considered from the beginning.\nWhen essential metrics like error rates, costs or CO₂ emissions are continuously and automatically tracked by project or responsible party, teams retain full oversight and can intervene in real time.\nAn integrated governance structure standardises deployment, monitoring and accountability, providing a strong foundation for enterprise-wide scalability and long-term success.\nThe principle here is to develop once, deploy everywhere. This consistent approach reduces audit efforts, increases transparency and builds a unified data foundation. That means faster progress with full compliance.\nFrom operations to ROI: Secure quality, reduce risk and create value # Organisations are searching for ways to roll out AI projects faster, enhance system stability and ensure security and reliability stay in line with applicable standards.\nLinking AI to business goals: Every AI project must connect to a strategic or operational business objective, measured via clear KPIs. Preventing tool sprawl: A governance-first approach enables unified processes and sustainable structures, avoiding uncoordinated one-offs. Standardising collaboration: Interdisciplinary teams benefit from shared playbooks and self-service environments. Handover points are minimised and collaboration becomes more seamless. Maintaining agility: AI models must adapt to dynamic market and business demands. Mechanisms like human-in-the-loop oversight ensure human judgement remains the final arbiter. Scaling pilots: Governance frameworks prevent ‘PoC paralysis’, making AI deployable in the real world. Avoiding technical disruption: Experienced partners integrate seamlessly with existing tech stacks or deliver tailored end-to-end solutions that fit within broader ecosystems and IT environments. Compliance as a competitive advantage: Enhancing security without slowing down # Building trust and reducing risk, without sacrificing speed, is the challenge. The goal is to integrate AI governance efficiently and in a future-proof manner, so that it fits seamlessly into existing systems. The right principles make this possible.\nThis starts with setting clear goals that deliver measurable outcomes. Crucially, responsibilities must be well-defined across functions, whether that’s to increase revenue, boost efficiency or mitigate risks.\nAnother lever is automation: by applying tried-and-tested design patterns, automating repetitive tasks and deploying proven AI agents, projects can be accelerated, costs brought under control and resources freed up for higher-value work.\nA practical example: For a financial services client, keeping a close eye on costs related to the operation, daily use, and development of their digital systems landscape was critical. Using our Cybernetic Delivery Platform (CDP), live applications are continuously monitored. A configurable dashboard allows responsible teams to detect errors immediately, or have them resolved automatically, with clear lines of accountability.\nStructured scalability for long-term success # Controlled, structured scaling is essential. Industrial standards in AI implementation ensure that initiatives remain manageable as they grow in complexity, paving the way for sustainable success.\nEqually important is addressing change early. No matter how well-designed a system is today, standards, market conditions and the global landscape will continue to evolve. Tools that help detect risks early and respond flexibly are key to long-term success.\nScaling AI responsibly: Zühlke’s answer # AI governance isn’t a brake lever. It’s the operational foundation for scaling AI. When implemented correctly, it turns cost centres into value-generating processes and strengthens organisational resilience.\nTo realise AI projects that deliver measurable value, without compromise, organisations need deep expertise, technological capability and the right tools.\nOur Cybernetic Delivery Platform (CDP) is the modular foundation for industrialised AI.\nSupported by the Cybernetic Delivery Method™ (CDM) and additional AI accelerators like ZenAI or ZAG, CDP offers maximum flexibility to deliver secure solutions tailored to individual needs.\nSeamless integration: Your AI acceleratorby Zühlke # With this approach, you can:\nLink AI projects to clear business objectives from the outset Integrate with existing systems or build end-to-end, depending on your requirements Collaborate within a trusted partner ecosystem, avoiding vendor lock-in Meet regulatory requirements such as the EU AI Act, GDPR or sector-specific standards with confidence Real-world application # In the case of our client from the financial sector, CDP’s value is clear. Open logs are continuously monitored in live operation. A customisable dashboard delivers exactly the right information to the responsible teams, whether for proactive monitoring or automated issue resolution. And AI enables stable, efficient and future-proof operations.\nAt Zühlke, we embrace AI internally and in partnership with our clients. We remove friction, create space for innovation and empower change. Yes, AI carries some inherent risks. But with the right governance, it can become a sustainable driver of innovation, trust and performance.\nOriginal article: https://www.zuehlke.com/en/insights/secure-ai-governance-scalable-delivery-zero-disruption\n","date":"3 July 2025","externalUrl":null,"permalink":"/en/blogs/secure-ai-governance-scalable-delivery-zero-disruption/","section":"Blogs","summary":"As AI adoption accelerates, many organisations find themselves unable to scale. The solution? Embedding governance from the outset. By integrating compliance, transparency, and accountability into the core of AI initiatives, leaders can transform governance into a catalyst for innovation, trust, and sustainable growth.\n","title":"Secure AI governance: Scalable delivery, zero disruption","type":"blogs"},{"content":"","date":"2 July 2025","externalUrl":null,"permalink":"/en/tags/adaptation/","section":"Tags","summary":"","title":"Adaptation","type":"tags"},{"content":"","date":"2 July 2025","externalUrl":null,"permalink":"/en/tags/learning/","section":"Tags","summary":"","title":"Learning","type":"tags"},{"content":"","date":"2 July 2025","externalUrl":null,"permalink":"/en/tags/organization-design/","section":"Tags","summary":"","title":"Organization Design","type":"tags"},{"content":"From Christoph Gulden\nWelcome to Thought Leaders Talk, a podcast-style daily newsletter where bold minds meet real questions. In each episode, we talk with a guest who doesn’t just follow ideas, they shape them. No nonsense. No posturing. Just clear, original thinking on what truly matters.\nSetting # Today’s conversation isn’t about what’s trending. It’s about what’s structural. We’re joined by someone who doesn\u0026rsquo;t just think in systems, he builds them.\nRomano Roth is Global Chief of Cybernetic Transformation at Zühlke. If that sounds abstract, let me simplify it: Romano helps organizations become intelligent, adaptive, and capable of learning at scale, not in theory, but in delivery.\nThis leads directly to the core question of this episode:\nWhat kind of organization can learn, adapt, and deliver in real time, and what does it take to build one?\nSession # Christoph Gulden: Romano, welcome.\nRomano Roth: Thank you, Christoph. I’m excited to bring this topic into focus, and into practice.\nChristoph: Let’s get right into it. You say the current enterprise model is broken. Not outdated, broken. Why?\nRomano: Because it was designed for a world that no longer exists.\nMost companies still run on a command-control model: departments, hierarchies, silos. It assumes predictability. But AI changes the game. We\u0026rsquo;re now dealing with dynamic systems, real-time data, and constantly shifting user needs.\nYou can’t solve that with more org charts. You need systems that learn. That’s where the Cybernetic Enterprise comes in. It’s not a metaphor. It’s a structural shift.\nChristoph: That word, “cybernetic”, can feel abstract. How do you ground it?\nRomano: Cybernetics is the science of feedback, control, and adaptation. I ground it by asking: Does this organization actually know what’s happening? Can it respond without waiting for permission?\nWe build feedback loops between users, code, teams, and strategy. We embed telemetry into platforms. We reduce delay between signal and action.\nWhen you do that, the enterprise stops acting like a machine, and starts behaving like a living system.\nChristoph: I want to pause here. What you’re describing is a shift from efficiency to coherence. Not just “do we work fast”, but “do we work in alignment with what matters.”\nRomano: Exactly. And coherence comes from feedback. AI helps, but only if the system is designed to listen.\nThis isn’t just technology. It’s architecture. It’s leadership. It’s how decisions are made and how teams are structured. A Cybernetic Enterprise is designed for change, not disrupted by it.\nChristoph: You once said: “A static org will always lose to a learning org.” That stuck with me.\nBut this also requires a mindset shift at the top. How do you help leaders move from control to orchestration?\nRomano: It starts by shifting the questions they ask. Instead of: “Who owns this?”, we ask: “What is the feedback loop?”\nInstead of: “What’s the roadmap?”, we ask: “Where’s the signal strongest right now?”\nAnd we make architecture visible. Our delivery platforms let leaders see flow, quality, learning. You don’t need dashboards for control. You need systems for awareness.\nChristoph: That’s powerful. Awareness becomes the infrastructure.\nLet’s close with this. You work with some of the most complex systems out there. What’s one principle any organization, even a small one, - can apply tomorrow?\nRomano: Don’t build for stability. Build for change.\nMap your value loops. Where does insight come in, and how fast can it reach decision-makers? Where is the system deaf or slow?\nStart small, but close the loop. Once feedback becomes part of how you build, the system will start to learn on its own.\nChristoph: Romano, this was dense in the best way, practical, layered, and clear.\nThank you for being here.\nRomano Thank you, Christoph. Let’s keep building systems that can listen and learn.\nTakeaway # That’s it for today’s episode of Thought Leaders Talk. We’re not here for hot takes. We’re here for structure, for clarity you can build on.\nIf this resonated, pause and ask: Where in your system does learning actually happen? If you can’t answer that, it’s time to redesign.\nOriginal article: https://www.linkedin.com/pulse/cybernetic-enterprise-how-organizations-can-learn-adapt-gulden-e2bxe/\n","date":"2 July 2025","externalUrl":null,"permalink":"/en/blogs/the-cybernetic-enterprise-how-organizations-can-learn-adapt-and-deliver-in-an-ai-native-world/","section":"Blogs","summary":"From Christoph Gulden\nWelcome to Thought Leaders Talk, a podcast-style daily newsletter where bold minds meet real questions. In each episode, we talk with a guest who doesn’t just follow ideas, they shape them. No nonsense. No posturing. Just clear, original thinking on what truly matters.\n","title":"The Cybernetic Enterprise: How Organizations Can Learn, Adapt, and Deliver in an AI-Native World","type":"blogs"},{"content":" AI is everywhere, but clarity, strategy, and real impact are often left by the wayside. We live in the era of what Romano Roth has dubbed ‘AI idiots’, an era of flashy demos rather than genuine long-term value. But a smarter way forward is possible. Discover the Cybernetic Enterprise and the business value it offers for industrial organisations.\n\u0026ldquo;Don\u0026rsquo;t be fooled. From ChatGPT cowboys to politically motivated snap decisions and choices based more on buzzwords than substance, AI hype is everywhere.\u0026rdquo; - Romano Roth, Zühlke Global Chief of Cybernetic Transformation \u0026amp; Partner\nA wake-up call for industrial organisation, not an insult # The term ‘AI idiots’ is meant to be provocative, but it’s not meant to offend. Rather it’s a wake-up call for leaders in the industrial sector. The term describes well-meaning but misguided attempts to ‘do AI’ without truly understanding what it takes to succeed: systems thinking, cultural change, and strategic alignment.\nFrom ChatGPT cowboys to AI-washing in boardrooms, our experience shows that too many companies adopting AI see it as a quick fix rather than a long-term transformation. This blog post explores ways to move beyond the hype and build something real and long-term: the Cybernetic Enterprise.\nThe ‘AI-first’ illusion: why chasing the hype is doomed to failure # Artificial intelligence is undoubtedly one of the most significant technological developments of our time. But at many companies, the approach being taken to this technology looks panicked rather than strategic. AI in the industrial sector is being hailed as a panacea, investment is pouring into AI-first initiatives, and prototypes are being rolled out apace. But more often than not the return on investment (ROI) simply never materialises, especially in industrial settings, where robustness matters more than prototypes. It\u0026rsquo;s important to understand that AI has its limits.\nAI can optimise, suggest, and assist, but it doesn’t fix broken processes or make decisions. It doesn’t repair misaligned governance or reshape corporate culture. Companies expecting AI to deliver transformation on its own are going to be disappointed.\nRoutine tasks, like basic coding, are becoming increasingly automated. But the real value lies in what AI can’t replace: human judgment, contextual understanding, empathy, and creativity. That’s where people still make the difference.\nThe future isn’t AI-first. It’s human-led and AI-enabled. This guiding principle means AI serves human goals, amplifies insights, and accelerates value creation, while leaving humans in the driver’s seat.\nThe Cybernetic Enterprise: a future-ready operating model # The Cybernetic Enterprise is both mindset and operating model. Inspired by the original meaning of cybernetic (from the Greek ‘steersman’), it treats organisations as dynamic systems with feedback loops between people, technology, and processes.\nKey objectives of the Cybernetic Enterprise include:\nLong-term adaptability Continuous learning Sustainable value creation AI should be integrated, not an add-on # In this model, AI isn’t a bolt-on tool, it’s baked into the organisational DNA. It supports product development, operations, decision-making, and customer experience as part of a unified strategy.\nFor a real-world example, take a look at Zühlke’s Cybernetic Delivery Platform (CDP). This is a modular, standards-based platform that integrates AI accelerators across the lifecycle. It provides self-service automation, analytics, and AI as a Service, boosting productivity in the industrial sector by up to 30-50% in real client projects.\nThe human system behind smart AI in industry: 3 pillars of Cybernetic Transformation # No AI strategy is complete without a human-centred operating model. The Cybernetic Enterprise is not built on technology alone. It thrives on the interaction between people, processes, and platforms. At the heart of this transformation are three interconnected pillars that ensure that AI delivers lasting value, not just short-term gain:\nBeyond task executors: The transformation into a cybernetic enterprise affects all roles, not just software engineers. Whether you\u0026rsquo;re an operator on the shop floor, a data analyst, a domain expert, or a tech lead, success in AI-augmented environments demands more than just task execution. It calls for navigating complexity, thinking in feedback loops, and connecting the dots across disciplines. In short, a shift from functional specialists to systems-aware, problem-solving collaborators.\nNew skillsets: This requires Cybernetic Thinking, the ability to integrate technology, people, processes, and organisations into a continuously learning system. Critical thinking, creativity, and empathy become as vital as technical know-how.\nEmpowerment: Teams need to own their products, work iteratively, and make decisions locally, where the knowledge is, not at some remote management level. This shift enables speed, relevance, and responsibility.\nContinuous value creation: Cybernetic Enterprises build processes that evolve through feedback. This creates a culture of iteration, where learning and improvement never stop.\nAgile and adaptive: Combining agile principles with self-learning systems keeps teams responsive and aligned with customer success.\nProductivity boost: AI-enabled platforms like Zühlke’s Cybernetic Delivery Platform are already delivering measurable outcomes. In real projects, development productivity has increased by 30%, with a potential of up to 50%.\nAI accelerators: Modular tools and components that embed intelligence into every step of software development and operations.\nDemocratising digitalisation: With AI-supported development, companies of all sizes, not just tech giants, can scale digitalisation affordably and effectively. This levels the playing field, especially for AI in production and industrial environments.\nAI in the industrial sector needs to cultivate a future-ready workforce # Allow me to put to rest a common concern: artificial Intelligence isn’t eliminating jobs, it’s transforming them. And with that transformation comes a growing talent gap. This gap doesn’t exist despite AI, but because of it. As machines take over routine tasks, the need for specialised human capabilities becomes even more critical. The future demands professionals who understand how to work with AI, ethically, strategically, and effectively.\nTo meet this demand, industrial organisations need to step up and start actively shaping the workforce of tomorrow. That means rethinking how we educate, train, and develop people. It’s no longer enough to simply roll out new tools or expect employees to keep up on their own. What’s needed are new forms of education and targeted upskilling programs; real learning environments where people can experiment, grow, and adapt alongside emerging technologies.\nOrganisations that invest in these capabilities gain more than just technical expertise. They cultivate loyalty. Employees who are given the chance to learn and grow are more likely to stay engaged, committed, and willing to lead change. By empowering talent to thrive in AI-supported environments, companies build not only a future-ready workforce but also a future-proof culture.\n\u0026ldquo;The future of AI in the industrial sector isn’t driven by tools. It’s driven by leaders who think cybernetically.\u0026rdquo; - Romano Roth, Zühlke Global Chief of Cybernetic Transformation \u0026amp; Partner\nBeyond the hype: building a human-centric future with AI in the industrial sector # The Cybernetic Enterprise is more than just a buzzword. It’s a call for a more mature way of doing things, for moving beyond short-term sprints and toward a sustainable, resilient, adaptive model:\nThe future is not AI-first.\nIt is human-led and AI-enabled.\nAt Zühlke, we help businesses across industries take that step, from building intelligent platforms to cultivating the skills and culture needed for long-term success.\nIf you\u0026rsquo;re exploring how to apply AI in your industrial environment, redesign your operating model, or empower your teams for the future, I’d love to hear from you.\nReach out to me directly. I\u0026rsquo;m happy to discuss your challenges. # Original Article: https://www.zuehlke.com/en/insights/cybernetic-enterprise-industrial-sector\n","date":"26 June 2025","externalUrl":null,"permalink":"/en/blogs/the-cybernetic-enterprise-turning-industrial-ai-hype-into-lasting-value/","section":"Blogs","summary":" AI is everywhere, but clarity, strategy, and real impact are often left by the wayside. We live in the era of what Romano Roth has dubbed ‘AI idiots’, an era of flashy demos rather than genuine long-term value. But a smarter way forward is possible. Discover the Cybernetic Enterprise and the business value it offers for industrial organisations.\n","title":"The Cybernetic Enterprise: turning industrial AI hype into lasting value","type":"blogs"},{"content":"","date":"14 June 2025","externalUrl":null,"permalink":"/en/tags/cybernetics/","section":"Tags","summary":"","title":"Cybernetics","type":"tags"},{"content":"\u0026ldquo;AI won\u0026rsquo;t fix your broken processes. DevOps won\u0026rsquo;t save your business. But Cybernetics might.\u0026rdquo;\nAt DevOps Pro Europe 2025 in Vilnius, I had the privilege of delivering the opening keynote to a packed hall of engineers, architects, and leaders navigating the ever-accelerating evolution of enterprise technology. My message was direct:\nThe future of DevOps isn’t AI. It’s cybernetic.\nNot hype-driven. Not about replacing developers. Not about chasing trends. About adaptive, resilient systems where AI, humans, processes, and platforms work in concert. Driven by feedback, grounded in governance, and powered by great engineering.\nThe Hype Trap: Why AI Isn’t Enough # We’re deep in an AI hype cycle. Investment is skyrocketing, over $1 trillion projected in 2025, but real business value remains elusive. Tools like ChatGPT are amazing, but most enterprises are still struggling to:\nGovern AI usage Avoid redundancy Integrate AI meaningfully into delivery pipelines And no, AI won’t replace developers anytime soon. It augments them, for now. Complex systems (like air traffic control, financial platforms, or cyber-physical systems) require far more than \u0026ldquo;Hello World\u0026rdquo; AI hacks. They need architecture, domain understanding, security, and responsibility.\nThe Cybernetic Enterprise: Beyond DevOps # So, where do we go next?\nWe shift from DevOps and AI as endpoints to Cybernetics as a foundation.\nA Cybernetic Enterprise is:\nSelf-adaptive: Powered by continuous feedback loops Integrated: Technology, process, people, and AI work together Governed: Every capability is secure, compliant, and reusable Value-driven: Focused on business outcomes, not buzzwords Cybernetics isn’t a toolset. It’s a design philosophy. It redefines how we build and run software systems, across silos, across clouds, across teams.\nPlatform Engineering: The Enabler # At the heart of cybernetics is Platform Engineering.\nWe’ve moved from product teams juggling tech stacks, pipelines, and infrastructure, toward:\nSelf-service platforms Standardized delivery models Floating platform architectures (vendor-agnostic and adaptable) End-to-end responsibility for product teams, powered by shared capabilities We call this a Cybernetic Delivery Platform an internal product, built by platform teams, used by product teams, and designed to scale DevSecOps across the enterprise.\nReal-World Implementation: Lessons from the Field # At Zühlke, we’ve built such a cybernetic delivery platform for ourselves and for clients like a private bank.\nKey elements include:\nInstant partner onboarding with identity federation Domain-driven design and a modular platform architecture AI as a service: Chatbots, synthetic data tools, coding assistants, all available securely through the platform Governed observability: Pre-baked dashboards, secret detection, container scanning out of the box Cloud + On-prem support: Seamless Dev-to-Prod pipelines across hybrid infrastructure → New applications in 15 minutes\n→ Full security, observability, and compliance baked in\n→ Developers empowered, not overwhelmed\nAI as a Capability, Not a Strategy # AI is part of the puzzle. But only a part.\nIn a Cybernetic Delivery Platform, AI is just another capability. Delivered, governed, and versioned like any other component. It’s integrated, not idolized.\nModel hubs Prompt engineering tools Reusable AI components (e.g., chat, search, test data generation) Local LLM hosting for privacy and compliance AI helps product teams build better apps. It doesn’t define the platform. It rides on it.\nKey Takeaways # AI won’t save you if your organisation, technology, and processes are broken. DevOps isn’t dead. But it’s evolving into something deeper. Platform engineering is the foundation of the Cybernetic Enterprise. Cybernetics = Organization + Process + Governance + Technology + AI, orchestrated through feedback loops. The goal is not speed. It’s adaptability at scale. Final Thought: From Factory to Feedback # The software industry is moving toward a Cybernetic Factory. Where reusable services, self-service platforms, and adaptive delivery models create a continuously improving enterprise.\nThe future belongs to those who can master the symphony between humans, machines, and systems.\nLet’s stop chasing magic. Let’s start engineering value.\nWant more? # Look out for my upcoming book: “The Cybernetic Enterprise (August 2025), where I go deeper into models, frameworks, and practical blueprints for building these systems at scale.\nLink to the slides: https://www.linkedin.com/posts/romanoroth_ai-augmented-devops-with-platform-engineering-activity-7332661815111249920-gPRP?utm_source=share\u0026utm_medium=member_desktop\u0026rcm=ACoAAAFlVNkBeox1Z6etOAteIPzww6xSKPNAtZ0\n","date":"14 June 2025","externalUrl":null,"permalink":"/en/blogs/cybernetics-is-the-future-why-ai-and-devops-alone-won-t-get-us-there/","section":"Blogs","summary":"“AI won’t fix your broken processes. DevOps won’t save your business. But Cybernetics might.”\nAt DevOps Pro Europe 2025 in Vilnius, I had the privilege of delivering the opening keynote to a packed hall of engineers, architects, and leaders navigating the ever-accelerating evolution of enterprise technology. My message was direct:\n","title":"Cybernetics Is the Future: Why AI and DevOps Alone Won’t Get Us There","type":"blogs"},{"content":"","date":"14 June 2025","externalUrl":null,"permalink":"/en/tags/digital-factory/","section":"Tags","summary":"","title":"Digital Factory","type":"tags"},{"content":"","date":"14. June 2025","externalUrl":null,"permalink":"/de/tags/kybernetik/","section":"Tags","summary":"","title":"Kybernetik","type":"tags"},{"content":"«KI wird Ihre kaputten Prozesse nicht reparieren. DevOps wird Ihr Geschäft nicht retten. Aber Kybernetik könnte es.»\nAn der DevOps Pro Europe 2025 in Vilnius hatte ich das Privileg, die Eröffnungs-Keynote vor einem vollen Saal von Engineers, Architekten und Führungskräften zu halten, die sich durch die rasante Evolution der Unternehmenstechnologie navigieren. Meine Botschaft war klar:\nDie Zukunft von DevOps ist nicht KI. Sie ist kybernetisch.\nNicht hypegetrieben. Nicht darauf ausgerichtet, Entwickler zu ersetzen. Nicht darauf aus, Trends zu jagen. Sondern auf adaptive, resiliente Systeme, in denen KI, Menschen, Prozesse und Plattformen zusammenwirken. Angetrieben durch Feedback, verankert in Governance und getragen von grossartigem Engineering.\nDie Hype-Falle: Warum KI allein nicht reicht # Wir stecken tief in einem KI-Hype-Zyklus. Die Investitionen schiessen in die Höhe, über 1 Billion US-Dollar werden für 2025 prognostiziert, doch der tatsächliche Geschäftswert bleibt schwer fassbar. Tools wie ChatGPT sind beeindruckend, aber die meisten Unternehmen kämpfen noch immer damit:\nKI-Nutzung zu governen Redundanzen zu vermeiden KI sinnvoll in Delivery-Pipelines zu integrieren Nein, KI wird Entwickler nicht so bald ersetzen. Sie ergänzt sie, vorerst. Komplexe Systeme (wie Flugsicherung, Finanzplattformen oder cyber-physische Systeme) erfordern weit mehr als «Hello World»-KI-Experimente. Sie brauchen Architektur, Domänenverständnis, Sicherheit und Verantwortung.\nDas Cybernetic Enterprise: Jenseits von DevOps # Wohin geht die Reise?\nWir bewegen uns weg von DevOps und KI als Endpunkte hin zu Kybernetik als Fundament.\nEin Cybernetic Enterprise ist:\nSelbst-adaptiv: Angetrieben durch kontinuierliche Feedback-Loops Integriert: Technologie, Prozesse, Menschen und KI arbeiten zusammen Gouverniert: Jede Fähigkeit ist sicher, compliant und wiederverwendbar Wertgetrieben: Fokussiert auf Geschäftsergebnisse, nicht auf Buzzwords Kybernetik ist kein Toolset. Es ist eine Designphilosophie. Sie definiert neu, wie wir Softwaresysteme bauen und betreiben, über Silos, Clouds und Teams hinweg.\nPlatform Engineering: Der Enabler # Im Herzen der Kybernetik steht Platform Engineering.\nWir haben uns wegbewegt von Produktteams, die Tech-Stacks, Pipelines und Infrastruktur jonglieren, hin zu:\nSelf-Service-Plattformen Standardisierten Delivery-Modellen Floating-Platform-Architekturen (herstellerunabhängig und anpassbar) End-to-End-Verantwortung für Produktteams, unterstützt durch gemeinsame Fähigkeiten Wir nennen das eine Cybernetic Delivery Platform: ein internes Produkt, gebaut von Plattformteams, genutzt von Produktteams und darauf ausgelegt, DevSecOps im gesamten Unternehmen zu skalieren.\nPraxiserfahrung: Lektionen aus dem Feld # Bei Zühlke haben wir eine solche kybernetische Delivery-Plattform für uns selbst und für Kunden wie eine Privatbank gebaut.\nWichtige Elemente umfassen:\nSofortiges Partner-Onboarding mit Identity Federation Domain-Driven Design und modulare Plattformarchitektur KI als Service: Chatbots, synthetische Datentools, Coding-Assistenten, alles sicher über die Plattform verfügbar Gouvernierte Observability: Vorgefertigte Dashboards, Secret Detection, Container-Scanning out of the box Cloud- und On-Prem-Unterstützung: Nahtlose Dev-to-Prod-Pipelines über hybride Infrastruktur Neue Anwendungen in 15 Minuten. Volle Sicherheit, Observability und Compliance von Anfang an. Entwickler empowert, nicht überfordert.\nKI als Fähigkeit, nicht als Strategie # KI ist ein Teil des Puzzles. Aber nur ein Teil.\nIn einer Cybernetic Delivery Platform ist KI einfach eine weitere Fähigkeit. Ausgeliefert, gouverniert und versioniert wie jede andere Komponente. Integriert, nicht idealisiert.\nModel Hubs Prompt-Engineering-Tools Wiederverwendbare KI-Komponenten (z.B. Chat, Suche, Testdatengenerierung) Lokales LLM-Hosting für Datenschutz und Compliance KI hilft Produktteams, bessere Apps zu bauen. Sie definiert die Plattform nicht. Sie reitet auf ihr.\nKernaussagen # KI wird Sie nicht retten, wenn Ihre Organisation, Technologie und Prozesse kaputt sind DevOps ist nicht tot. Aber es entwickelt sich zu etwas Tieferem weiter Platform Engineering ist das Fundament des Cybernetic Enterprise Kybernetik = Organisation + Prozesse + Governance + Technologie + KI, orchestriert durch Feedback-Loops Das Ziel ist nicht Geschwindigkeit. Es ist Anpassungsfähigkeit im grossen Massstab Abschliessender Gedanke: Von der Fabrik zum Feedback # Die Softwareindustrie bewegt sich in Richtung einer kybernetischen Fabrik. Wiederverwendbare Services, Self-Service-Plattformen und adaptive Delivery-Modelle schaffen ein kontinuierlich lernendes Unternehmen.\nDie Zukunft gehört denen, die die Symphonie zwischen Menschen, Maschinen und Systemen meistern.\nHören wir auf, Magie zu jagen. Fangen wir an, Wert zu engineeren.\nMehr erfahren? # Mein Buch: «The Cybernetic Enterprise», in dem ich tiefer in Modelle, Frameworks und praktische Blueprints für den Aufbau dieser Systeme im grossen Massstab einsteige.\n","date":"14. June 2025","externalUrl":null,"permalink":"/de/blogs/kybernetik-ist-die-zukunft-warum-ki-und-devops-allein-nicht-reichen/","section":"Blogs","summary":"«KI wird Ihre kaputten Prozesse nicht reparieren. DevOps wird Ihr Geschäft nicht retten. Aber Kybernetik könnte es.»\nAn der DevOps Pro Europe 2025 in Vilnius hatte ich das Privileg, die Eröffnungs-Keynote vor einem vollen Saal von Engineers, Architekten und Führungskräften zu halten, die sich durch die rasante Evolution der Unternehmenstechnologie navigieren. Meine Botschaft war klar:\n","title":"Kybernetik ist die Zukunft: Warum KI und DevOps allein nicht reichen","type":"blogs"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/ai-tools/","section":"Tags","summary":"","title":"AI Tools","type":"tags"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/ai-assisted-development/","section":"Tags","summary":"","title":"AI-Assisted Development","type":"tags"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/code-generation/","section":"Tags","summary":"","title":"Code Generation","type":"tags"},{"content":" Romano Roth is Chief of Cybernetic Transformation at Zühlke and is deeply engaged with the impact of AI on organizations, technology, and culture. In this guest article, he explores how AI is affecting professionals, especially in the coding space.\nArtificial Intelligence is rapidly transforming software development. What was manually coded yesterday is now created via prompts. For companies, this presents a massive opportunity. But for many professionals, it’s also a source of uncertainty.\nA recent article in Trending Topics summed it up: the entry barriers for newcomers in the IT industry are rising. AI is taking over tasks that were previously carried out by developers. Will professionals soon become obsolete? No. But it does mean the industry needs to recalibrate.\nAI Is Changing Processes # Today, software is increasingly developed with AI. Tools assist in writing code, generating tests, and even documenting automatically. When used properly, they massively boost productivity. Innovative platform approaches, like Zühlke’s Cybernetic Delivery Platform (CDP), show how AI can be integrated across the entire development process, from initial idea to finished product. The goal: increase productivity, streamline processes, and enable innovation.\nCDP is a modular platform made up of AI accelerators, which can be used independently or together depending on the project’s needs, seamlessly integrating into existing IT landscapes. Early client projects show promising results: productivity was increased by 30%, with a potential of up to 50%. AI-assisted software development demonstrably accelerates digital product creation while reducing costs. For process digitalization, it\u0026rsquo;s a kind of booster, or even a democratization tool: allowing organizations of all sizes to harness digitalization for business success.\nAI Needs People # As powerful as tools like CDP’s modules are, they don’t design or improve processes. Just like the cloud doesn’t create structure. AI provides suggestions, not decisions. It simplifies workflows, but still needs guidance and expertise. Anyone working with AI must understand it, challenge it critically, and apply it responsibly.\nPeople remain central in AI-assisted software development, as analysts, designers, decision-makers. The term cybernetic, derived from the Greek word for “helmsman,” perfectly describes this interplay: feedback loops, circular processes, and co-learning between humans and machines. It’s a powerful framework for understanding and shaping collaboration with AI, necessary to fully unlock its potential.\nFarewell to the Classic Coder # The idea of the lone coder, toiling away on complex code for hours, is becoming outdated. Traditional programming tasks, especially routine ones are being automated. In AI-powered development, it’s no longer about typing code, but about understanding complexity, thinking in systems, and solving intricate problems.\nWhat’s needed now are engineers with critical thinking, creativity, the ability to reflect, and a feel for users, ethics, and impact. To navigate this new world, syntax knowledge isn’t enough. What’s needed is Cybernetic Thinking, the ability to connect technology, people, processes, and organizations in a meaningful, continuously learning system.\nResponsibility for the Next Generation # Industry has a responsibility to actively shape this transformation. This applies not just to clients of tech companies, but to the tech providers themselves. It’s not enough to integrate AI tools. We also need new forms of education, targeted upskilling, and real learning spaces. The next talent shortage is already foreseeable. Not in spite of AI, but because of it.\nAs automation and new technologies gain ground, the demand grows for talents who can use these tools responsibly. Those who train today’s experts in AI-powered development are not only building knowledge, but also loyalty. Companies that offer real development opportunities secure not just well-trained employees, but also committed teams ready to shape the digital transformation.\nAI as a Cultural Transformer # AI isn’t just a productivity driver. It’s a catalyst for cultural change. In software development, but also in how we build teams, foster talent, and structure responsibility. The code of the future isn’t written alone but through collaboration between human, machine, and mindset.\nOriginal Article: https://www.trendingtopics.eu/coding-ohne-coder/\n","date":"11 June 2025","externalUrl":null,"permalink":"/en/blogs/coding-without-coders/","section":"Blogs","summary":" Romano Roth is Chief of Cybernetic Transformation at Zühlke and is deeply engaged with the impact of AI on organizations, technology, and culture. In this guest article, he explores how AI is affecting professionals, especially in the coding space.\n","title":"Coding Without Coders?","type":"blogs"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/cybernetic-thinking/","section":"Tags","summary":"","title":"Cybernetic Thinking","type":"tags"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/developer-skills/","section":"Tags","summary":"","title":"Developer Skills","type":"tags"},{"content":"","date":"11 June 2025","externalUrl":null,"permalink":"/en/tags/future-of-coding/","section":"Tags","summary":"","title":"Future of Coding","type":"tags"},{"content":" Romano Roth ist Chief of Cybernetic Transformation bei Zühlke und beschäftigt sich intensiv mit den Auswirkungen von KI auf Organisationen, Technologie und Kultur. In diesem Gastbeitrag untersucht er, wie KI Fachkräfte beeinflusst, insbesondere im Bereich des Codings.\nKünstliche Intelligenz verändert die Softwareentwicklung rasant. Was gestern noch manuell programmiert wurde, entsteht heute per Prompt. Für Unternehmen bietet das eine enorme Chance. Für viele Fachkräfte ist es jedoch auch eine Quelle der Verunsicherung.\nEin aktueller Artikel in Trending Topics brachte es auf den Punkt: Die Einstiegshürden für Newcomer in der IT-Branche werden höher. KI übernimmt Aufgaben, die zuvor von Entwicklerinnen und Entwicklern ausgeführt wurden. Werden Fachkräfte bald überflüssig? Nein. Aber es bedeutet, dass sich die Branche neu kalibrieren muss.\nKI verändert Prozesse # Heute wird Software zunehmend mit KI entwickelt. Tools unterstützen beim Schreiben von Code, beim Generieren von Tests und sogar beim automatischen Dokumentieren. Richtig eingesetzt, steigern sie die Produktivität massiv. Innovative Plattformansätze, wie Zühlkes Cybernetic Delivery Platform (CDP), zeigen, wie KI in den gesamten Entwicklungsprozess integriert werden kann, von der ersten Idee bis zum fertigen Produkt. Das Ziel: Produktivität steigern, Prozesse verschlanken und Innovation ermöglichen.\nCDP ist eine modulare Plattform aus KI-Beschleunigern, die je nach Projektbedarf unabhängig oder gemeinsam genutzt werden können und sich nahtlos in bestehende IT-Landschaften integrieren. Erste Kundenprojekte zeigen vielversprechende Ergebnisse: Die Produktivität wurde um 30 % gesteigert, mit einem Potenzial von bis zu 50 %. KI-gestützte Softwareentwicklung beschleunigt nachweislich die Entstehung digitaler Produkte und senkt gleichzeitig die Kosten. Für die Prozessdigitalisierung ist sie eine Art Booster oder sogar ein Demokratisierungswerkzeug: Sie ermöglicht es Organisationen jeder Grösse, die Digitalisierung für den Geschäftserfolg zu nutzen.\nKI braucht Menschen # So leistungsstark Tools wie die Module der CDP auch sind, sie konzipieren oder verbessern keine Prozesse. Genauso wenig wie die Cloud Struktur schafft. KI liefert Vorschläge, keine Entscheidungen. Sie vereinfacht Arbeitsabläufe, braucht aber dennoch Anleitung und Expertise. Wer mit KI arbeitet, muss sie verstehen, kritisch hinterfragen und verantwortungsvoll einsetzen.\nDer Mensch bleibt in der KI-gestützten Softwareentwicklung zentral, als Analyst, Designer, Entscheider. Der Begriff «kybernetisch», abgeleitet vom griechischen Wort für «Steuermann», beschreibt dieses Zusammenspiel perfekt: Feedbackschleifen, zirkuläre Prozesse und gemeinsames Lernen zwischen Mensch und Maschine. Es ist ein wirkungsvolles Rahmenwerk, um die Zusammenarbeit mit KI zu verstehen und zu gestalten, das nötig ist, um ihr Potenzial voll auszuschöpfen.\nAbschied vom klassischen Coder # Die Vorstellung des einsamen Coders, der stundenlang an komplexem Code arbeitet, wird obsolet. Klassische Programmieraufgaben, insbesondere Routinetätigkeiten, werden automatisiert. In der KI-gestützten Entwicklung geht es nicht mehr darum, Code zu tippen, sondern Komplexität zu verstehen, in Systemen zu denken und komplizierte Probleme zu lösen.\nWas nun gefragt ist, sind Engineers mit kritischem Denken, Kreativität, Reflexionsfähigkeit und einem Gespür für Nutzer, Ethik und Wirkung. Um sich in dieser neuen Welt zurechtzufinden, reicht Syntaxwissen nicht aus. Was es braucht, ist Cybernetic Thinking, die Fähigkeit, Technologie, Menschen, Prozesse und Organisationen in einem sinnvollen, kontinuierlich lernenden System zu verbinden.\nVerantwortung für die nächste Generation # Die Industrie hat die Verantwortung, diese Transformation aktiv zu gestalten. Das gilt nicht nur für die Kunden von Tech-Unternehmen, sondern auch für die Tech-Anbieter selbst. Es reicht nicht, KI-Tools zu integrieren. Wir brauchen auch neue Bildungsformen, gezielte Weiterqualifizierung und echte Lernräume. Der nächste Fachkräftemangel ist bereits absehbar. Nicht trotz KI, sondern wegen ihr.\nMit dem Vormarsch von Automatisierung und neuen Technologien wächst die Nachfrage nach Talenten, die diese Tools verantwortungsvoll einsetzen können. Wer heutige Expertinnen und Experten in KI-gestützter Entwicklung schult, baut nicht nur Wissen, sondern auch Loyalität auf. Unternehmen, die echte Entwicklungsmöglichkeiten bieten, sichern sich nicht nur gut ausgebildete Mitarbeitende, sondern auch engagierte Teams, die bereit sind, die digitale Transformation zu gestalten.\nKI als Kulturtransformator # KI ist nicht nur ein Produktivitätstreiber. Sie ist ein Katalysator für kulturellen Wandel. In der Softwareentwicklung, aber auch darin, wie wir Teams aufbauen, Talente fördern und Verantwortung strukturieren. Der Code der Zukunft wird nicht allein geschrieben, sondern in der Zusammenarbeit zwischen Mensch, Maschine und Mindset.\nOriginalartikel: https://www.trendingtopics.eu/coding-ohne-coder/\n","date":"11. June 2025","externalUrl":null,"permalink":"/de/blogs/programmieren-ohne-programmierer/","section":"Blogs","summary":" Romano Roth ist Chief of Cybernetic Transformation bei Zühlke und beschäftigt sich intensiv mit den Auswirkungen von KI auf Organisationen, Technologie und Kultur. In diesem Gastbeitrag untersucht er, wie KI Fachkräfte beeinflusst, insbesondere im Bereich des Codings.\n","title":"Programmieren ohne Programmierer?","type":"blogs"},{"content":"","date":"9 June 2025","externalUrl":null,"permalink":"/en/tags/cost-reduction/","section":"Tags","summary":"","title":"Cost Reduction","type":"tags"},{"content":"Wie können wir Kosten senken, schneller entwickeln und effizienter werden? In dieser Präsentation zeige ich die Kernkonzepte des Cybernetic Enterprise und wie Organisationen durch die Kombination von Wertstromanalyse, Platform Engineering und KI kontinuierlich Wert liefern können.\nDie versteckten Kosten ungenutzter Features # Eine Tatsache, die viele überrascht: 80% der Features in einem durchschnittlichen Softwareprodukt werden selten oder nie verwendet. Mehrere Studien bestätigen diese Zahl. Zusätzlich kommen Wartungskosten über den gesamten Softwarelebenszyklus von weiteren 40 bis 80% auf die ursprünglichen Entwicklungskosten hinzu.\nLassen Sie mich das mit einer einfachen Rechnung veranschaulichen. Wenn Sie 10 Features zu je CHF 100'000 entwickeln, betragen die Gesamtentwicklungskosten CHF 1 Million. Die Wartung kommt mit weiteren CHF 400'000 bis 800'000 dazu. Das ergibt Gesamtlebenszykluskosten von CHF 1,4 bis 1,8 Millionen. Durch die Eliminierung der 80% selten genutzter Features könnten Sie rund CHF 1,1 bis 1,4 Millionen einsparen. Die Erkenntnis ist klar: Das Richtige zu bauen ist enorm wichtig.\n«Das Falsche richtig zu machen ist bei weitem nicht so gut wie das Richtige falsch zu machen.» — Dr. Russell Ackoff\nDas Richtige bauen vs. die Sache richtig bauen # Das sind zwei grundlegende Konzepte zur Kosteneinsparung. Das Richtige bauen bedeutet, die Lösung an Geschäfts- und Nutzerbedürfnisse auszurichten. Nur wenn der Nutzer ein Feature auch tatsächlich verwendet, ist es ein nützliches Feature. Hier geht es um Effektivität.\nDie Sache richtig bauen bezieht sich darauf, wie effizient die Engineering-Praktiken sind, wie schnell Änderungen geliefert werden können und wie einfach man sich anpassen kann. Hier geht es um Effizienz. Meine Präsentation konzentriert sich auf die Effizienzseite, aber beide Aspekte sind gleich wichtig.\nValue Stream Mapping: Sehen, wohin das Geld fliesst # Moderne Softwareentwicklung ist ein kontinuierlicher Prozess über einen Wertstrom. Es ist kein Projekt mit Start- und Enddatum. Es ist Produktentwicklung, die nie aufhört, bis die Software ausserbetrieb genommen wird.\nValue Stream Mapping ist eine wirkungsvolle Technik, um zu verstehen, wie Wert durch das System fliesst, und um Engpässe zu identifizieren. So geht es:\nDas Team zusammenbringen und alle Schritte von der Idee bis zur Produktion identifizieren Die beteiligten Personen identifizieren, um Übergaben zwischen Rollen sichtbar zu machen Leistung messen mit Prozesszeit (tatsächliche wertschöpfende Arbeit), Durchlaufzeit (gesamte verstrichene Zeit) und Prozent korrekt und vollständig (Qualität) Das Aktivitätsverhältnis berechnen, indem die Gesamtprozesszeit durch die Gesamtdurchlaufzeit geteilt wird Den Soll-Zustand entwerfen mit Verbesserungen Im gezeigten Beispiel lag das Aktivitätsverhältnis im Ist-Zustand bei nur 7%. Das bedeutet, dass 93% der Zeit nicht für wertschöpfende Arbeit genutzt wurden. Der Anteil «korrekt und vollständig» lag bei nur 5%, was bedeutet, dass in 95% der Fälle Nacharbeit nötig war. Nach dem Entwurf des Soll-Zustands mit optimierten Prozessen und Automatisierung verbesserte sich das Aktivitätsverhältnis auf 11% und die Qualität stieg auf 72%.\nWo investieren: Prozesse, Automatisierung und Organisation # Sobald der Wertstrom visualisiert ist, können datenbasierte Entscheidungen getroffen werden:\nProzessverbesserungen: Abläufe straffen, Verschwendung eliminieren und Verfahren standardisieren Automatisierung und KI: Moderne Werkzeuge, Infrastructure as Code und KI dort einsetzen, wo die Daten den Mehrwert belegen Organisationsstruktur: Übergaben reduzieren, indem Teams entlang des Wertstroms organisiert werden Governance: Schwerfällige Governance-Gremien automatisieren oder eliminieren Das Schöne am Value Stream Mapping ist: KI ist nicht mehr eine vage «wir könnten es irgendwo einsetzen»-Idee. Man sieht genau, wo KI passt, und kann mit echten Zahlen verifizieren, ob sie den gewünschten Effekt hatte.\nDie Cybernetic Platform: Ihr technologisches Fundament # Ein Wertstrom braucht das richtige technologische Fundament. Wir treten in das Zeitalter der industrialisierten digitalen Produktentwicklung ein und bewegen uns weg von heterogenen Tool-Landschaften hin zu standardisierten Plattformen.\nDas Zielbetriebsmodell eines Cybernetic Enterprise besteht aus autonomen Produktteams, die sich auf Features und Geschäftswert konzentrieren, unterstützt von einem Plattformteam, das eine Self-Service-Plattform erstellt. Diese Plattform, die ich Cybernetic Platform nenne, bietet alle Werkzeuge und Fähigkeiten, die Produktteams brauchen:\nObservability mit vorkonfigurierten Dashboards Sicherheitsscanning für Schwachstellen, Lizenzen und Secrets Golden-Path-Templates für standardisierte Projekterstellung KI als Service für die gesamte Organisation Container-Registries mit automatisiertem Scanning GitOps-basierte Deployments über Argo CD Die Kernarchitektur folgt dem Floating-Platform-Prinzip aus Gregor Hohpes Buch «Platform Strategy». Alle Tools werden über die Plattform integriert, nie direkt miteinander. Das ist entscheidend, denn wenn ein Anbieter übernommen wird (man stelle sich vor, Broadcom kauft GitLab), kann das Tool ausgetauscht werden, ohne die Teams zu stören.\nLive-Demo: Die Zühlke Platform Plane # Bei Zühlke leben wir, was wir predigen. Unsere eigene Cybernetic Delivery Platform bedient 465 Nutzer, 15 Partner, 26 Spaces und 12 Kubernetes-Cluster. Wir setzen sie für interne und Kundenprojekte gleichermassen ein.\nDie wichtigsten demonstrierten Funktionen:\nPartnermanagement: Externe Unternehmen mit eigener Identität über Azure Entra ID einbinden. Innerhalb einer Sekunde erhält jemand Zugang zu allen integrierten Tools. Spaces: Netzwerkzonen im Hub-Spoke-Muster, in denen Teams alles betreiben können, was sie brauchen. Sicherheit: Automatisches Schwachstellen-Scanning, Lizenz-Compliance und Secret-Erkennung über alle Repositories. KI-Integration: Containerimage-Analyse mittels KI, in nur acht Stunden gebaut, weil die Plattform die APIs bereitstellt. Servicekatalog: Entwickler können Datenbanken, Azure-OpenAI-Endpunkte und weitere Services selbst provisionieren, ohne sich um Passwörter oder Backups zu kümmern. FinOps: Kostenverfolgung pro Space, die an Projekte weiterverrechnet wird. Das Plattformteam generiert Wert für die Teams, und die Produktteams generieren Wert für die Kunden.\nKernaussagen # 80% der Features in durchschnittlichen Softwareprodukten werden selten oder nie genutzt. Zuerst das Richtige bauen, dann die Sache richtig bauen. Value Stream Mapping ist eine einfache, aber wirkungsvolle Technik aus den 1940er-Jahren, die datenbasierte Einblicke liefert, wo in Automatisierung und KI investiert werden sollte. Platform Engineering schafft das technologische Fundament für das Cybernetic Enterprise und standardisiert, wie Produkte gebaut werden. Das Floating-Platform-Prinzip stellt sicher, dass Tools ausgetauscht werden können, ohne Teams zu stören. KI ist eine Fähigkeit der Plattform, keine eigenständige Initiative. Sie wird als gesteuerter Service bereitgestellt. Die Zukunft gehört denen, die die Symphonie aus Organisation, Prozess, Technologie, Governance und KI meistern. So senkt man Kosten durch kontinuierliche Wertlieferung. ","date":"9. June 2025","externalUrl":null,"permalink":"/de/blogs/cybernetic-enterprise-erklaert-ki-devops-skalierbare-softwarelieferung/","section":"Blogs","summary":"Wie können wir Kosten senken, schneller entwickeln und effizienter werden? In dieser Präsentation zeige ich die Kernkonzepte des Cybernetic Enterprise und wie Organisationen durch die Kombination von Wertstromanalyse, Platform Engineering und KI kontinuierlich Wert liefern können.\n","title":"Cybernetic Enterprise erklärt: KI, DevOps \u0026 skalierbare Softwarelieferung","type":"blogs"},{"content":"How can we reduce costs, develop faster, and become more efficient? In this presentation, I walk through the core concepts of the Cybernetic Enterprise and show how organizations can continuously deliver value by combining value stream analysis, platform engineering, and AI.\nThe Hidden Cost of Unused Features # Here is a fact that surprises many people: 80% of features in the average software product are rarely or never used. Multiple studies confirm this number. On top of that, maintenance costs over the full software lifecycle add another 40 to 80% on top of the original development cost.\nLet me illustrate this with a simple calculation. If you develop 10 features at CHF 100,000 each, your total development cost is CHF 1 million. Maintenance adds another CHF 400,000 to 800,000. That brings the total lifecycle cost to CHF 1.4 to 1.8 million. By eliminating the 80% of rarely used features, you could save roughly CHF 1.1 to 1.4 million. The takeaway is clear: building the right thing matters enormously.\n\u0026ldquo;Doing the wrong thing right is not nearly as good as doing the right thing wrong.\u0026rdquo; — Dr. Russell Ackoff\nBuilding the Right Thing vs. Building the Thing Right # These are two fundamental concepts for saving costs. Building the right thing is about aligning your solution to business and user needs. Only if the user actually uses a feature is it a useful feature. This is about effectiveness.\nBuilding the thing right is about how efficient your engineering practices are, how fast you can deliver changes, and how easily you can adapt. This is about efficiency. My presentation focuses on the efficiency side, but both are equally important.\nValue Stream Mapping: See Where Your Money Goes # Modern software development is a continuous process across a value stream. It is not a project with a start and end date. It is product development that never stops until you decommission your software.\nValue stream mapping is a powerful technique to understand how value flows through your system and to identify bottlenecks. Here is how you do it:\nGather your team and identify all steps from ideation to production Identify the people working on each step to see handoffs between roles Measure performance using process time (actual value-added work), lead time (total elapsed time), and percentage complete and accurate (quality) Calculate the activity ratio by dividing total process time by total lead time Design your future state value stream with improvements In the example I showed, the current state had an activity ratio of just 7%, meaning 93% of the time was spent not doing value-added work. The percentage complete and accurate was only 5%, meaning rework happened in 95% of cases. After designing the future state with streamlined processes and automation, the activity ratio improved to 11% and quality rose to 72%.\nWhere to Invest: Process, Automation, and Organization # Once you have your value stream visualized, you can make data-driven decisions about where to invest:\nProcess improvements: Streamline workflows, eliminate waste, and standardize procedures Automation and AI: Use modern tooling, infrastructure as code, and AI where the data shows it will have impact Organizational structure: Reduce handoffs by organizing teams along the value stream Governance: Automate or eliminate heavyweight governance bodies that slow things down The beauty of value stream mapping is that AI is no longer a vague \u0026ldquo;we could use it somewhere\u0026rdquo; idea. You can see exactly where AI fits and verify whether it had the right impact with real numbers.\nThe Cybernetic Platform: Your Technology Foundation # A value stream needs the right technology foundation. We are entering the age of industrialized digital product development, moving away from custom, heterogeneous tool landscapes toward standardized platforms.\nThe target operating model of a Cybernetic Enterprise has autonomous product teams focusing on features and business value, supported by a platform team that creates a self-service platform. This platform, what I call the Cybernetic Platform, provides all the tools and capabilities product teams need:\nObservability with pre-configured dashboards Security scanning for vulnerabilities, licenses, and secrets Golden path templates for standardized project creation AI as a service for the entire organization Container registries with automated scanning GitOps-based deployments through Argo CD The core architecture follows the floating platform principle from Gregor Hohpe\u0026rsquo;s book \u0026ldquo;Platform Strategy.\u0026rdquo; You integrate all tools through the platform, never directly with each other. This is critical because if a vendor gets acquired (imagine Broadcom buying GitLab), you can swap out that tool without disrupting your teams.\nLive Demo: The Zühlke Platform Plane # At Zühlke, we practice what we preach. Our own Cybernetic Delivery Platform serves 465 users, 15 partners, 26 spaces, and 12 Kubernetes clusters. We use it for internal projects and customer projects alike.\nKey capabilities I demonstrated:\nPartner management: Onboard external companies with their own identity through Azure Entra ID. Someone gets access to all integrated tools within a second. Spaces: Network zones using a hub-spoke pattern where teams can run whatever they need. Security: Automated vulnerability scanning, license compliance, and secret detection across all repositories. AI integration: Container image analysis powered by AI, built in just eight hours because the platform provides the APIs. Service catalog: Developers can provision databases, Azure OpenAI endpoints, and other services through self-service, no passwords or backups to worry about. FinOps: Cost tracking per space, charged back to projects. The platform team generates value for the teams, and the product teams generate value for the customers.\nKey Takeaways # 80% of features in average software products are rarely or never used. Build the right thing first, then build it right. Value stream mapping is a simple but powerful technique from the 1940s that gives you data-driven insights into where to invest in automation and AI. Platform engineering creates the technology foundation for your Cybernetic Enterprise, standardizing how products are built. The floating platform principle ensures you can swap tools without disrupting teams. AI is a capability of your platform, not a standalone initiative. Provide it as a governed service. The future belongs to those who master the symphony between organization, process, technology, governance, and AI. This is how you reduce costs by continuously delivering value. ","date":"9 June 2025","externalUrl":null,"permalink":"/en/blogs/cybernetic-enterprise-explained-ai-devops-scalable-software-delivery/","section":"Blogs","summary":"How can we reduce costs, develop faster, and become more efficient? In this presentation, I walk through the core concepts of the Cybernetic Enterprise and show how organizations can continuously deliver value by combining value stream analysis, platform engineering, and AI.\n","title":"Cybernetic Enterprise Explained: AI, DevOps \u0026 Scalable Software Delivery","type":"blogs"},{"content":"","date":"9. June 2025","externalUrl":null,"permalink":"/de/tags/kostenreduktion/","section":"Tags","summary":"","title":"Kostenreduktion","type":"tags"},{"content":"","date":"9 June 2025","externalUrl":null,"permalink":"/en/tags/software-delivery/","section":"Tags","summary":"","title":"Software Delivery","type":"tags"},{"content":"","date":"9. June 2025","externalUrl":null,"permalink":"/de/tags/softwarelieferung/","section":"Tags","summary":"","title":"Softwarelieferung","type":"tags"},{"content":" Warum KI allein keine Strategie ersetzt # Künstliche Intelligenz ist auch in der Industriebranche das zentrale Gesprächsthema. Um echte Wettbewerbsvorteile durch und mit KI zu erzielen, dürfen Unternehmen nicht blind dem KI-Hype folgen. Ein „AI-First\u0026quot;-Label garantiert weder Innovation noch Zukunftssicherheit. Nur wer Mensch, Technologie und Organisation in einem lernfähigen System, dem Cybernetic Enterprise, vereint, wird langfristig erfolgreich sein.\nKünstliche Intelligenz ist zweifellos eine der bedeutendsten technologischen Entwicklungen unserer Zeit. Doch der Umgang vieler Unternehmen mit dieser Technologie wirkt derzeit leider oft eher panisch als strategisch: KI wird als Allheilmittel gefeiert, es wird in „AI-First\u0026quot;-Initiativen investiert, Prototypen werden schnellstmöglich ausgerollt, doch der Return on Investment (ROI) bleibt häufig aus. Romano Roth, Global Chief of Cybernetic Transformation bei Zühlke, hat dazu eine klare Meinung: „Lassen Sie sich nicht blenden. Von ‚ChatGPT-Cowboys\u0026rsquo; über politikgetriebene Schnellschüsse bis zu Entscheidungen, die mehr auf Buzzwords als auf Substanz basieren, der KI-Hype ist allgegenwärtig.\u0026quot;\nDie Erfahrungen aus Zühlke-Kundenprojekten zeigen: KI allein wird keine schlechten Prozesse retten. Sie wird keine dysfunktionalen Organisationen heilen und auch nicht kulturelle Herausforderungen in Unternehmen lösen. Wer glaubt, ein Sprachmodell könne Geschäftsmodelle neu erfinden, ohne dass Menschen die Richtung vorgeben, verkennt, worauf es wirklich ankommt.\nDie Wahrheit ist: Die Zukunft gehört nicht der KI, sondern den Unternehmen, die eine Umgebung schaffen, in der Menschen in der Lage sind, mit KI zu arbeiten. Und zwar nicht punktuell, sondern systematisch. Willkommen im Zeitalter des Cybernetic Enterprise.\nLangfristige Anpassungsfähigkeit und nachhaltiger Wert # Ein Cybernetic Enterprise ist ein lernfähiges, sich kontinuierlich selbst regulierendes System. Es kombiniert Technologie, Organisation, Prozesse und Governance in intelligenten Feedbackschleifen. Ziel ist nicht kurzfristige Effizienz, sondern langfristige Anpassungsfähigkeit und nachhaltiger Wert. Entscheidungen sind datenbasiert, Teams agieren dezentral, aber nach gemeinsamen Prinzipien, und die technologische Infrastruktur ermöglicht eine permanente Weiterentwicklung.\nStatt KI als externes Tool zu betrachten, das man bei Bedarf „drüberstülpt\u0026quot;, ist sie im Cybernetic Enterprise integraler Bestandteil einer modernen Plattformstrategie. Die Grundlage dafür bildet das Prinzip des Platform Engineerings: Eine interne, auf Standards basierende Plattform bietet Entwicklern \u0026amp; Entwicklerinnen, Architekten \u0026amp; Architektinnen und Produktteams Self-Service-Funktionen, Automatisierung und KI-Komponenten „as a Service\u0026quot;. Das reduziert Reibung, erhöht die Time-to-Market und schafft den Freiraum für echte Innovation.\nDer Mensch bleibt das Zentrum der industriellen Transformation # Doch selbst die beste Plattform nützt nichts, wenn die Organisation nicht mitzieht. Deshalb setzt das Cybernetic Enterprise auf Empowerment: Teams übernehmen Verantwortung für ihre Produkte, arbeiten iterativ und eng mit Nutzenden zusammen. Entscheidungen werden dort getroffen, wo Wissen vorhanden ist, nicht in fernen Hierarchien.\nDas vielleicht Wichtigste: Im Zentrum des Cybernetic Enterprise stehen Menschen. Es geht nicht darum, menschliche Fähigkeiten durch KI zu ersetzen, sondern sie zu erweitern. KI wird zum Katalysator, nicht zum Dirigenten. Nur durch das Zusammenspiel aus Menschen, Technologie, Organisation und Prozessen entsteht echte Transformation.\nDie Geschichte lehrt uns: Hypes kommen und gehen. Was bleibt, sind diejenigen, die Substanz schaffen. Wer die aktuelle KI-Welle nicht nur überstehen, sondern gezielt nutzen möchte, muss mehr tun, als ein paar Pilotprojekte aufzusetzen. Er muss seine Organisation neu denken - „cybernetic\u0026quot;, lernfähig, menschenzentriert. Denn die Zukunft ist nicht „AI-First\u0026quot;. Sie ist „Human-Led and AI-Enabled\u0026quot;.\nOriginal Artikel: https://www.industr.com/de/die-ki-welle-meistern-wie-industrieunternehmen-sie-gezielt-nutzen-2860664\n","date":"8. June 2025","externalUrl":null,"permalink":"/de/blogs/die-ki-welle-meistern-industrie/","section":"Blogs","summary":"Warum KI allein keine Strategie ersetzt # Künstliche Intelligenz ist auch in der Industriebranche das zentrale Gesprächsthema. Um echte Wettbewerbsvorteile durch und mit KI zu erzielen, dürfen Unternehmen nicht blind dem KI-Hype folgen. Ein „AI-First\"-Label garantiert weder Innovation noch Zukunftssicherheit. Nur wer Mensch, Technologie und Organisation in einem lernfähigen System, dem Cybernetic Enterprise, vereint, wird langfristig erfolgreich sein.\n","title":"Die KI-Welle meistern: Wie Industrieunternehmen sie gezielt nutzen","type":"blogs"},{"content":" Why AI Alone Doesn’t Replace Strategy # Artificial Intelligence is the central topic in the industrial sector, too. But to gain real competitive advantages through and with AI, companies must not blindly follow the hype. An “AI-First” label guarantees neither innovation nor future viability. Only those who combine people, technology, and organization in a learning system, the Cybernetic Enterprise, will be successful in the long run.\nArtificial Intelligence is undoubtedly one of the most significant technological developments of our time. Yet many companies are approaching it more with panic than strategy: AI is hailed as a cure-all, “AI-First” initiatives are launched, prototypes are rolled out at high speed, yet the return on investment (ROI) often fails to materialize. Romano Roth, Global Chief of Cybernetic Transformation at Zühlke, has a clear stance:“Don’t be fooled. From ‘ChatGPT cowboys’ to politically driven quick fixes to decisions based more on buzzwords than substance, the AI hype is everywhere.”\nExperience from Zühlke client projects shows: AI alone won’t fix broken processes. It won’t heal dysfunctional organizations or solve cultural challenges. Believing that a language model can reinvent a business model without human direction misses the point entirely.\nThe truth is this: The future doesn’t belong to AI. It belongs to the companies that create environments where people can work effectively with AI. Not occasionally, but systematically. Welcome to the age of the Cybernetic Enterprise.\nLong-Term Adaptability and Sustainable Value # A Cybernetic Enterprise is a learning, continuously self-regulating system. It combines technology, organization, processes, and governance through intelligent feedback loops. The goal isn’t short-term efficiency, but long-term adaptability and sustainable value. Decisions are data-driven, teams act in a decentralized manner but follow shared principles, and the technological infrastructure enables continuous evolution.\nRather than treating AI as an external tool that is applied when needed, in a Cybernetic Enterprise, AI is an integral part of a modern platform strategy. The foundation for this is the principle of platform engineering: An internal, standards-based platform provides developers, architects, and product teams with self-service capabilities, automation, and AI components “as a service.” This reduces friction, accelerates time-to-market, and creates the space for true innovation.\nHumans Remain at the Center of Industrial Transformation # But even the best platform is useless if the organization doesn’t keep up. That’s why the Cybernetic Enterprise focuses on empowerment: Teams take responsibility for their products, work iteratively, and collaborate closely with users. Decisions are made where knowledge resides, not in distant hierarchies.\nAnd perhaps most importantly: At the heart of the Cybernetic Enterprise are people. It’s not about replacing human capabilities with AI, but augmenting them. AI becomes a catalyst, not the conductor. True transformation arises only through the interplay of people, technology, organization, and processes.\nHistory teaches us: Hypes come and go. What endures are those who build substance. Those who want to not just survive but deliberately leverage the current AI wave must do more than launch a few pilot projects. They must rethink their organization, to be cybernetic, adaptive, and human-centered.Because the future is not AI-First. It is Human-Led and AI-Enabled.\nAt the upcoming event, the Zühlke Group will host a topic table titled:”AI Between Hype and Reality: How Companies Can Survive the Era of AI Idiocy.” Speak with Romano Roth, Chief of Cybernetic Transformation at Zühlke. Because in a time when AI is transforming nearly every industry, one thing is clear: Those who implement AI without understanding it are buying their next crisis. And without cultural change and a solid data strategy, every AI initiative remains nothing more than a paper tiger.\nOriginal Post in German: https://www.industr.com/de/die-ki-welle-meistern-wie-industrieunternehmen-sie-gezielt-nutzen-2860664\n","date":"8 June 2025","externalUrl":null,"permalink":"/en/blogs/riding-the-ai-wave-how-industrial-companies-can-harness-it-purposefully/","section":"Blogs","summary":"Why AI Alone Doesn’t Replace Strategy # Artificial Intelligence is the central topic in the industrial sector, too. But to gain real competitive advantages through and with AI, companies must not blindly follow the hype. An “AI-First” label guarantees neither innovation nor future viability. Only those who combine people, technology, and organization in a learning system, the Cybernetic Enterprise, will be successful in the long run.\n","title":"Riding the AI Wave: How Industrial Companies Can Harness It Purposefully","type":"blogs"},{"content":"The most successful companies of the next decade will not just use AI. They will be organized around it. The AI-augmented enterprise is an operating model where human expertise and AI capabilities form a continuous feedback loop, enabling organizations to sense, decide, and act faster than ever before.\nIn this keynote, I draw on 10+ years of experience helping enterprises adopt DevOps, Platform Engineering, and AI to outline a practical path from today\u0026rsquo;s siloed AI experiments to a fully integrated AI-native organization.\nWhat is an AI-Augmented Enterprise? # Traditional organizations operate in cycles: plan, execute, review, adjust. An AI-augmented enterprise compresses these cycles by embedding AI-driven feedback loops at every level. From real-time market sensing to automated infrastructure scaling, to AI-augmented strategic decisions, the entire organization becomes adaptive.\nThe Three Pillars # 1. Intelligent Sensing AI agents continuously monitor markets, customer behavior, operational metrics, and competitive landscapes. Rather than quarterly reports, leaders receive real-time, contextualized insights.\n2. Augmented Decision-Making Human judgment remains central, but is amplified by AI that can simulate scenarios, identify blind spots, and quantify trade-offs. The result: faster decisions with higher confidence.\n3. Autonomous Execution Platform Engineering and AI-powered DevOps enable teams to move from decision to deployment in minutes, not months. Self-healing infrastructure and AI-assisted development reduce the cost of change.\nFrom Vision to Reality # This is not science fiction. I share concrete examples from organizations that have begun this transformation, including the tools, team structures, and cultural shifts that made it possible. Whether you are leading a startup or a Fortune 500, the AI-augmented model offers a clear path to building an organization that does not just respond to change, but thrives on it.\n","date":"3 June 2025","externalUrl":null,"permalink":"/en/speaking/ai-augmented-delivery/","section":"Speaking","summary":"The most successful companies of the next decade will not just use AI. They will be organized around it. The AI-augmented enterprise is an operating model where human expertise and AI capabilities form a continuous feedback loop, enabling organizations to sense, decide, and act faster than ever before.\n","title":"AI-Augmented Delivery: Building AI-Powered Organizations","type":"speaking"},{"content":"Many teams have ideas, but they lose time between gut feelings, vague requirements, and lengthy alignment meetings. In this workshop, I demonstrate live how we use Artificial Intelligence to drastically shorten the path from idea to prototype.\nAgenda # 1. Sharpen the Problem # Translate an idea into a clear problem statement, target audience definition, and success criteria. Instead of vague notions, concrete, testable hypotheses emerge.\n2. Generate Requirements # Create testable requirements (user stories, acceptance criteria, edge cases) and prioritize them into a small, buildable-today scope. AI helps structure and challenge the requirements.\n3. Build the Prototype # Build a clickable prototype of a digital product (flow, screens, copy, data mocks) and run a quick reality check.\nInteractive Elements # Live poll to select an audience use case Mini exercise with a decision canvas 2-minute peer review of requirements with the audience AI as Co-Builder # AI in this workshop is not an oracle delivering finished answers. It is a co-builder that helps iterate faster, uncover blind spots, and transform ideas into tangible results. You leave with a prototype and a concrete plan for the next 7 days.\n","date":"1 June 2025","externalUrl":null,"permalink":"/en/speaking/monday-morning-idea-monday-afternoon-prototype/","section":"Speaking","summary":"Many teams have ideas, but they lose time between gut feelings, vague requirements, and lengthy alignment meetings. In this workshop, I demonstrate live how we use Artificial Intelligence to drastically shorten the path from idea to prototype.\n","title":"Monday Morning: Idea. Monday Afternoon: Prototype. Become a Builder!","type":"speaking"},{"content":"","date":"1 June 2025","externalUrl":null,"permalink":"/en/tags/prototyping/","section":"Tags","summary":"","title":"Prototyping","type":"tags"},{"content":"","date":"1 June 2025","externalUrl":null,"permalink":"/en/tags/workshop/","section":"Tags","summary":"","title":"Workshop","type":"tags"},{"content":"","date":"17 May 2025","externalUrl":null,"permalink":"/en/tags/business-transformation/","section":"Tags","summary":"","title":"Business Transformation","type":"tags"},{"content":"Keynote am CTO Forum der Rudolf-Diesel-Medaille. Veranstaltet von Zühlke, München\nWir leben im KI-Hype-Zeitalter # KI dominiert die Schlagzeilen. Von natürlichen Sprachschnittstellen bis zur automatisierten Codegenerierung ist das Entwicklungstempo unerbittlich. Doch neben der Begeisterung sehen wir auch überzogene Versprechungen, übereilte Implementierungen und enttäuschende Ergebnisse.\nAllein im Jahr 2025 werden die globalen Investitionen in KI voraussichtlich eine Billion Dollar übersteigen. Die geschätzten Einnahmen betragen jedoch nur einen Bruchteil davon, etwa 120 Milliarden. Diese Lücke wird mit Annahmen über zukünftige Effizienzgewinne gefüllt, die alles andere als garantiert sind.\nDas Muster ist bekannt. Wie bei der Dotcom-Blase im Jahr 2000 springen viele Organisationen heute auf den KI-Zug auf, ohne klare Strategie oder Wertschöpfung. Das Ergebnis ist eine sich abzeichnende Blase, die wir anerkennen müssen, bevor sie platzt.\nKI allein ist nicht die Antwort # KI ist ein leistungsstarkes Werkzeug. Aber sie kann weder kaputte Prozesse, veraltete Technologiestacks, fehlgeleitete Governance noch fragmentierte Organisationen reparieren.\nTransformation entsteht nicht durch KI in Isolation. Sie entsteht durch kybernetisches Denken, durch den Aufbau adaptiver Systeme, in denen Prozess, Organisation, Technologie, Governance und KI in kontinuierlichen Feedbackschleifen zusammenwirken, um Wert zu schaffen.\nDas ist die Grundlage des Cybernetic Enterprise.\nWas ist ein Cybernetic Enterprise? # Ein Cybernetic Enterprise ist ein sich selbst regulierendes, kontinuierlich weiterentwickelndes System. Es lernt durch Feedback, passt sich an Veränderungen an und richtet alle Komponenten, technische wie organisatorische, auf Geschäftsergebnisse aus.\nEs zeichnet sich aus durch:\nIntegriertes Feedback über alle Dimensionen hinweg Plattformbasierte Lieferung zur Reduzierung von Reibung und Steigerung der Standardisierung KI als Fähigkeit eingesetzt, eingebettet dort, wo sie klaren Mehrwert liefert Autonome Teams, die befähigt werden, ihre eigenen Produkte zu bauen und zu betreiben Dieses Modell führt uns von fragmentierter Entwicklung zu unternehmensweiter Orchestrierung.\nVon Custom Software zu industrialisierter Lieferung # Die meisten Unternehmen entwickeln Software heute noch in isolierten Umgebungen: interne Teams, externe Anbieter, hybride Modelle. Das Ergebnis ist Komplexität, Inkonsistenz und Ineffizienz.\nWir betreten nun das Zeitalter der industrialisierten Softwarelieferung. So wie die Fertigung sich durch Standardisierung weiterentwickelt hat, muss auch die Software- und KI-Lieferung nachziehen.\nStandardisierung von Services, Infrastruktur und Tooling Reduzierung der kognitiven Last für Produktteams Automatisierung von Compliance, Sicherheit und Observability Schaffung gemeinsamer Entwicklungsumgebungen, die die Lieferung beschleunigen Dieser Wandel ist bereits im Gange. Führende Organisationen investieren in kybernetische Plattformen als Rückgrat dieser Transformation.\nDie kybernetische Plattform: Skalierbare, adaptive Teams ermöglichen # Im Herzen des Cybernetic Enterprise steht die kybernetische Plattform, eine flexible Self-Service-Plattform, die die Fähigkeiten, Werkzeuge und Infrastruktur bereitstellt, die zum Bau moderner digitaler und cyber-physischer Produkte benötigt werden.\nEin einheitliches Developer Portal (z.B. Backstage oder massgeschneidert) Automatisierte Bereitstellungs- und Deployment-Schichten Standardisierte Integration von Werkzeugen durch die Plattform, nicht zwischen ihnen Eingebaute Fähigkeiten für Observability, Sicherheit und Lifecycle Management KI als Service bereitgestellt, nicht als separates Silo Diese Plattform ist kein zentraler Engpass. Sie ist ein Produkt an sich, gepflegt von einem dedizierten Team und gebaut, um autonome Produktteams in der gesamten Organisation zu unterstützen.\nPraxisbeispiel bei Zühlke # Bei Zühlke haben wir unsere eigene kybernetische Delivery-Plattform aufgebaut, um sowohl interne Projekte als auch Kundenprojekte zu unterstützen. Sie beschleunigt die Lieferung, verbessert die Konsistenz und dient als Blaupause für die Unternehmenstransformation.\nStandardisierung der digitalen Produktlieferung über verschiedene Branchen hinweg Unterstützung von Kunden, die keine internen Plattform-Fähigkeiten haben Wiederverwendung bewährter Komponenten und Services ermöglichen KI-Werkzeuge und Infrastruktur konsistent und gesteuert bereitstellen Sie ist die Grundlage dafür, wie wir Kunden helfen, von Komplexität zu Klarheit zu gelangen.\nEin Aufruf an CTOs und digitale Führungskräfte # CTOs und Technologieführer müssen jetzt über den Hype hinausgehen und sich auf nachhaltige, skalierbare, wertorientierte Grundlagen konzentrieren.\nKI strategisch einsetzen, nicht reaktiv Interne Plattformen aufbauen, die Teams befähigen Lieferung standardisieren, um Geschwindigkeit und Skalierung zu ermöglichen Feedback-getriebene Systeme schaffen, die sich kontinuierlich anpassen Das Cybernetic Enterprise ist keine Theorie. Es ist ein Betriebsmodell, das bereits in der realen Welt Ergebnisse liefert.\nFazit: Die Zukunft ist kybernetisch # Wir betreten eine neue Ära des Unternehmensdesigns, eine Ära, die KI, Governance, Organisation, Prozesse und Technologie in ein kohärentes, adaptives System integriert.\nDie Zukunft wird nicht allein durch KI definiert, sondern durch jene, die verstehen, wie sie deren Rolle in einem grösseren System orchestrieren. Das Cybernetic Enterprise ist dieses System.\nJetzt ist die Zeit, von Experimenten zur Umsetzung überzugehen.\n","date":"17. May 2025","externalUrl":null,"permalink":"/de/blogs/das-cybernetic-enterprise-warum-ki-allein-die-industrie-nicht-transformiert/","section":"Blogs","summary":"Keynote am CTO Forum der Rudolf-Diesel-Medaille. Veranstaltet von Zühlke, München\nWir leben im KI-Hype-Zeitalter # KI dominiert die Schlagzeilen. Von natürlichen Sprachschnittstellen bis zur automatisierten Codegenerierung ist das Entwicklungstempo unerbittlich. Doch neben der Begeisterung sehen wir auch überzogene Versprechungen, übereilte Implementierungen und enttäuschende Ergebnisse.\n","title":"Das Cybernetic Enterprise: Warum KI allein die Industrie nicht transformiert","type":"blogs"},{"content":"","date":"17. May 2025","externalUrl":null,"permalink":"/de/tags/systemdenken/","section":"Tags","summary":"","title":"Systemdenken","type":"tags"},{"content":"Keynote at the CTO Forum of the Rudolf-Diesel-Medaille. Hosted by Zühlke, Munich\nWe Are Living in the AI Hype Era # AI is dominating headlines. From natural language interfaces to automated code generation, the pace of development is relentless. But alongside this excitement, we are seeing inflated promises, rushed implementations, and disappointing returns.\nIn 2025 alone, global investment in AI is projected to exceed one trillion dollars. Yet, estimated revenues are only a fraction of that. Around 120 billion. This gap is filled with assumptions about future efficiency gains that are far from guaranteed.\nThe pattern is familiar. Like the dot-com bubble of 2000, many organizations today are jumping on the AI bandwagon without clear strategy or value. The result is an emerging bubble. One we must acknowledge before it bursts.\nAI Alone Is Not the Answer # AI is a powerful tool. But it cannot fix broken processes, outdated technology stacks, misaligned governance, or disjointed organizations.\nTransformation does not come from AI in isolation. It comes from cybernetic thinking, building adaptive systems where process, organization, technology, governance, and AI work together in continuous feedback loops to deliver value.\nThis is the foundation of the cybernetic enterprise.\nWhat Is a Cybernetic Enterprise? # A cybernetic enterprise is a self-regulating, continuously evolving system. It learns through feedback, adapts to change, and aligns all components, technical and organizational, toward business outcomes.\nIt is characterized by:\nIntegrated feedback across all dimensions Platform-based delivery to reduce friction and increase standardization AI used as a capability, embedded where it delivers clear value Autonomous teams enabled to build and run their own products This model moves us from fragmented development to enterprise-wide orchestration.\nFrom Custom Software to Industrialized Delivery # Most companies today still develop software in isolated environments, internal teams, external vendors, hybrid models, resulting in complexity, inconsistency, and inefficiency.\nWe are now entering the age of industrialized software delivery. Just as manufacturing evolved through standardization, software and AI delivery must follow suit.\nStandardizing services, infrastructure, and tooling Reducing cognitive load on product teams Automating compliance, security, and observability Creating common development environments that accelerate delivery This shift is already underway. Leading organizations are investing in cybernetic platforms as the backbone of this transformation.\nThe Cybernetic Platform: Enabling Scalable, Adaptive Teams # At the heart of the cybernetic enterprise is the cybernetic platform, a floating, self-service platform that provides the capabilities, tools, and infrastructure needed to build modern digital and cyber-physical products.\nA unified developer portal (e.g., Backstage or custom-built) Automated provisioning and deployment layers Standardized integration of tools through the platform, not between them Built-in capabilities for observability, security, and lifecycle management AI delivered as a service, not as a separate silo This platform is not a central bottleneck. It is a product in itself, maintained by a dedicated team, and built to support autonomous product teams across the organization.\nReal-World Implementation at Zühlke # At Zühlke, we have built our own cybernetic delivery platform to support both internal projects and client engagements. It accelerates delivery, improves consistency, and serves as a blueprint for enterprise transformation.\nStandardize digital product delivery across diverse industries Support clients who lack internal platform capabilities Enable reuse of proven components and services Deliver AI tools and infrastructure in a consistent, governed way It is the foundation of how we help clients move from complexity to clarity.\nA Call to Action for CTOs and Digital Leaders # CTOs and technology leaders must now move beyond hype and focus on creating sustainable, scalable, value-driven foundations.\nUsing AI strategically, not reactively Building internal platforms that empower teams Standardizing delivery to enable speed and scale Creating feedback-driven systems that adapt continuously The cybernetic enterprise is not a theory. It is an operating model that is already delivering results in the real world.\nConclusion: The Future is Cybernetic # We are entering a new era of enterprise design. One that integrates AI, governance, organization, process, and technology into a coherent, adaptive system.\nThe future will not be defined by AI alone, but by those who understand how to orchestrate its role within a larger system. The cybernetic enterprise is that system.\nNow is the time to move from experimentation to execution.\n","date":"17 May 2025","externalUrl":null,"permalink":"/en/blogs/the-cybernetic-enterprise-why-ai-alone-won-t-transform-industry/","section":"Blogs","summary":"Keynote at the CTO Forum of the Rudolf-Diesel-Medaille. Hosted by Zühlke, Munich\nWe Are Living in the AI Hype Era # AI is dominating headlines. From natural language interfaces to automated code generation, the pace of development is relentless. But alongside this excitement, we are seeing inflated promises, rushed implementations, and disappointing returns.\n","title":"The Cybernetic Enterprise: Why AI Alone Won’t Transform Industry","type":"blogs"},{"content":"","date":"24. March 2025","externalUrl":null,"permalink":"/de/tags/automatisierung/","section":"Tags","summary":"","title":"Automatisierung","type":"tags"},{"content":"Romano Roth advocates the importance of companies focusing on the developer experience and enabling developers to concentrate on creating business value.\nBy Romano Roth (*)\nThe speed of innovation is a key factor for business success. However, despite its advantages, we see many organizations unintentionally slowing down their progress by neglecting a critical component: the developer experience (DevEx). Today, developers spend a worrying amount of time on non-coding tasks, managing infrastructure, configuring pipelines, and ensuring security, which hinders speed, productivity, and innovation.\nFaced with this challenge, organizations that invest in the developer experience unlock powerful benefits. A DevEx strategy enables faster time to market, higher software quality, and increased developer satisfaction. Moreover, in a market where top technical talent is scarce, offering an environment that removes unnecessary friction is no longer optional, it’s a decisive factor for business success.\nWhy should CIOs and CTOs prioritize DevEx? # In the past, the focus of leadership was on DevOps, which eliminated silos between development and operations to accelerate software delivery. However, as companies evolve, developers are burdened by increasingly complex infrastructure, compliance requirements, and security demands. This is where DevEx becomes critical.\nWith DevEx, the productivity boost enables developers to focus on creating business value instead of being bogged down with infrastructure and operational tasks. It creates a frictionless workflow that accelerates innovation, allowing teams to deliver features and solutions more quickly. This helps retain top talent and ensures that developers stay motivated, reducing turnover. At the same time, according to DORA (DevOps Research and Assessment), organizations with strong internal platforms see tangible improvements: an 8% increase in individual productivity, a 10% improvement in team performance, and a 6% boost in software delivery and operations. For leaders, these numbers translate directly into a competitive advantage.\nPlatform Engineering: The Foundation of Developer Experience # Improving developer experience requires intentional investment in platform engineering. A well-designed Internal Developer Platform (IDP) offers self-service capabilities, enabling teams to work independently without being overwhelmed by operational complexities. This way, developers can focus on writing code instead of managing infrastructure, reducing inefficiencies and risks. By prioritizing platform engineering, companies create an ecosystem where developers can move faster, test more confidently, and deliver value more efficiently.\nAI in DevEx: The Next Big Leap # Artificial Intelligence (AI) is changing how software is developed. Given this reality, organizations that embrace Cyber-Development, that is, enhancing DevEx through AI, will gain a significant advantage. AI-assisted coding tools, such as GitHub Copilot, accelerate development while reducing errors, predicting failures, and fixing issues. In fact, AI does not replace developers; it empowers them.\nHow Can Leaders Drive DevEx Transformation? # For leaders, investing in DevEx is no longer optional. It is a critical business strategy. Organizations should build a dedicated team to maintain a self-service internal platform, minimizing wait times and giving teams the autonomy to build and deploy software. By automating infrastructure, they can reduce operational friction, while the use of AI-powered tools optimizes workflows and speeds up problem-solving.\nThe Future of Software Development Depends on DevEx # The organizations that will lead the next era of digital transformation won’t just be those deploying software faster. They’ll be the ones providing an environment where developers, empowered by AI, can innovate without friction. Indeed, developer experience is not a technical luxury but a strategic necessity. That’s why companies that invest in DevEx and platform engineering will accelerate innovation, productivity, and talent acquisition and retention, gaining a lasting competitive advantage.\n(*) Global Chief of DevOps \u0026amp; Partner at Zühlke\nOriginal article in portuguese: https://tek.sapo.pt/opiniao/artigos/devex-um-imperativo-estrategico-para-o-sucesso-empresarial\n","date":"24 March 2025","externalUrl":null,"permalink":"/en/blogs/devex-a-strategic-imperative-for-business-success/","section":"Blogs","summary":"Romano Roth advocates the importance of companies focusing on the developer experience and enabling developers to concentrate on creating business value.\n","title":"DevEx: A Strategic Imperative for Business Success","type":"blogs"},{"content":"Romano Roth plädiert dafür, dass sich Unternehmen auf die Developer Experience konzentrieren und es ihren Entwicklerinnen und Entwicklern ermöglichen, sich auf die Schaffung von Geschäftswert zu fokussieren.\nVon Romano Roth (*)\nDie Geschwindigkeit der Innovation ist ein Schlüsselfaktor für den Geschäftserfolg. Trotz ihrer Vorteile sehen wir jedoch viele Organisationen, die ihren Fortschritt unbeabsichtigt verlangsamen, indem sie eine entscheidende Komponente vernachlässigen: die Developer Experience (DevEx). Heute verbringen Entwicklerinnen und Entwickler einen besorgniserregenden Anteil ihrer Zeit mit Aufgaben ausserhalb des Codings, mit dem Verwalten von Infrastruktur, dem Konfigurieren von Pipelines und dem Sicherstellen von Sicherheit, was Geschwindigkeit, Produktivität und Innovation behindert.\nAngesichts dieser Herausforderung erschliessen Unternehmen, die in die Developer Experience investieren, erhebliche Vorteile. Eine DevEx-Strategie ermöglicht eine schnellere Time-to-Market, höhere Softwarequalität und gesteigerte Zufriedenheit der Entwicklerinnen und Entwickler. Darüber hinaus ist es in einem Markt, in dem technische Top-Talente knapp sind, kein optionales Extra mehr, ein Umfeld zu bieten, das unnötige Reibung beseitigt – es ist ein entscheidender Faktor für den Geschäftserfolg.\nWarum sollten CIOs und CTOs DevEx priorisieren? # In der Vergangenheit lag der Fokus der Führung auf DevOps, das die Silos zwischen Development und Operations beseitigt hat, um die Software-Auslieferung zu beschleunigen. Doch mit der Weiterentwicklung der Unternehmen werden Entwicklerinnen und Entwickler durch zunehmend komplexe Infrastruktur, Compliance-Anforderungen und Sicherheitsanforderungen belastet. Genau hier wird DevEx entscheidend.\nMit DevEx ermöglicht der Produktivitätsschub den Entwicklerinnen und Entwicklern, sich auf die Schaffung von Geschäftswert zu konzentrieren, statt sich mit Infrastruktur- und Betriebsaufgaben zu belasten. Es entsteht ein reibungsloser Workflow, der Innovation beschleunigt und Teams ermöglicht, Features und Lösungen schneller zu liefern. Das hilft, Top-Talente zu halten und sorgt dafür, dass Entwicklerinnen und Entwickler motiviert bleiben, was die Fluktuation reduziert. Gleichzeitig sehen Organisationen mit starken internen Plattformen laut DORA (DevOps Research and Assessment) konkrete Verbesserungen: eine Steigerung der individuellen Produktivität um 8 %, eine Verbesserung der Teamleistung um 10 % und einen Schub bei Software-Auslieferung und Betrieb um 6 %. Für Führungskräfte schlagen sich diese Zahlen direkt in einem Wettbewerbsvorteil nieder.\nPlatform Engineering: Das Fundament der Developer Experience # Die Verbesserung der Developer Experience erfordert gezielte Investitionen in Platform Engineering. Eine gut gestaltete Internal Developer Platform (IDP) bietet Self-Service-Funktionen und ermöglicht es Teams, unabhängig zu arbeiten, ohne von operativer Komplexität überwältigt zu werden. So können sich Entwicklerinnen und Entwickler auf das Schreiben von Code konzentrieren, statt Infrastruktur zu verwalten, was Ineffizienzen und Risiken reduziert. Indem sie Platform Engineering priorisieren, schaffen Unternehmen ein Ökosystem, in dem Entwicklerinnen und Entwickler sich schneller bewegen, sicherer testen und Wert effizienter liefern können.\nKI in DevEx: Der nächste grosse Sprung # Künstliche Intelligenz (KI) verändert die Art und Weise, wie Software entwickelt wird. Angesichts dieser Realität werden Organisationen, die Cyber-Development annehmen – also DevEx durch KI verbessern – einen erheblichen Vorteil erlangen. KI-gestützte Coding-Tools wie GitHub Copilot beschleunigen die Entwicklung, reduzieren Fehler, sagen Ausfälle voraus und beheben Probleme. Tatsächlich ersetzt KI keine Entwicklerinnen und Entwickler – sie befähigt sie.\nWie können Führungskräfte die DevEx-Transformation vorantreiben? # Für Führungskräfte ist die Investition in DevEx nicht mehr optional. Sie ist eine entscheidende Geschäftsstrategie. Organisationen sollten ein dediziertes Team aufbauen, um eine interne Self-Service-Plattform zu pflegen, Wartezeiten zu minimieren und Teams die Autonomie zu geben, Software zu bauen und auszurollen. Durch die Automatisierung der Infrastruktur können sie operative Reibung reduzieren, während der Einsatz KI-gestützter Tools Workflows optimiert und die Problemlösung beschleunigt.\nDie Zukunft der Softwareentwicklung hängt von DevEx ab # Die Organisationen, die die nächste Ära der digitalen Transformation anführen werden, sind nicht einfach diejenigen, die Software schneller ausrollen. Es werden diejenigen sein, die ein Umfeld bieten, in dem Entwicklerinnen und Entwickler – befähigt durch KI – ohne Reibung innovieren können. In der Tat ist Developer Experience kein technischer Luxus, sondern eine strategische Notwendigkeit. Deshalb werden Unternehmen, die in DevEx und Platform Engineering investieren, Innovation, Produktivität sowie Talentgewinnung und -bindung beschleunigen und sich einen dauerhaften Wettbewerbsvorteil sichern.\n(*) Global Chief of DevOps \u0026amp; Partner bei Zühlke\nOriginalartikel auf Portugiesisch: https://tek.sapo.pt/opiniao/artigos/devex-um-imperativo-estrategico-para-o-sucesso-empresarial\n","date":"24. March 2025","externalUrl":null,"permalink":"/de/blogs/devex-strategischer-imperativ-fuer-geschaeftserfolg/","section":"Blogs","summary":"Romano Roth plädiert dafür, dass sich Unternehmen auf die Developer Experience konzentrieren und es ihren Entwicklerinnen und Entwicklern ermöglichen, sich auf die Schaffung von Geschäftswert zu fokussieren.\n","title":"DevEx: Ein strategischer Imperativ für den Geschäftserfolg","type":"blogs"},{"content":"","date":"24 March 2025","externalUrl":null,"permalink":"/en/tags/talent/","section":"Tags","summary":"","title":"Talent","type":"tags"},{"content":"","date":"24. March 2025","externalUrl":null,"permalink":"/de/tags/talente/","section":"Tags","summary":"","title":"Talente","type":"tags"},{"content":"","date":"15 March 2025","externalUrl":null,"permalink":"/en/tags/developer-platform/","section":"Tags","summary":"","title":"Developer Platform","type":"tags"},{"content":"","date":"15. March 2025","externalUrl":null,"permalink":"/de/tags/entwicklerplattform/","section":"Tags","summary":"","title":"Entwicklerplattform","type":"tags"},{"content":"","date":"15 March 2025","externalUrl":null,"permalink":"/en/tags/open-source/","section":"Tags","summary":"","title":"Open Source","type":"tags"},{"content":"Should we open-source our internal developer platform? That is the question I brought to the audience during this talk. Instead of a traditional presentation, I gave a live demo of the Zühlke Platform Plane and then opened the floor for an honest discussion about the benefits, risks, and realities of open-sourcing a commercial platform product.\nWhat is the Platform Plane? # The Platform Plane is an internal developer platform that goes far beyond what most people think of when they hear \u0026ldquo;IDP.\u0026rdquo; It was born about two years ago from a shared investment between Zühlke and LGT, a private bank in Liechtenstein. LGT came to us and said: \u0026ldquo;We want to build a platform, but not just for ourselves. Let\u0026rsquo;s make a shared investment because we think other companies can benefit too.\u0026rdquo;\nThe result is a platform that spans the entire software lifecycle, from development through to production, covering both cloud and on-premises environments. It runs in a developer cloud where external and internal developers can access it, with the same platform deployed in production and on-prem. This means teams use the same pipelines and tools in development and production, which massively reduces friction.\nArchitecture: Domain-Driven and Tool-Agnostic # The architecture follows domain-driven design. We identified the different domains (repositories, container registries, security, observability, deployment) and created unified integration blocks for each. Tools are never integrated directly with each other. They are always integrated through the platform.\nWhy? Consider GitLab as an example. GitLab loses roughly $50 million every quarter. If Google buys the company, everything is fine. If Broadcom buys it, you might want to swap that tool very quickly. The floating platform principle, described in Gregor Hohpe\u0026rsquo;s book \u0026ldquo;Platform Strategy,\u0026rdquo; ensures you can play Lego with your tools.\nThe whole concept is: integrate all tools, DevOps platforms, and cloud providers into your floating platform so you can standardize processes and tool usage. The critical rule is: never duplicate the features of integrated tools, or your platform will become dependent and start to sink.\nLive Demo Highlights # During the demo, I showed the Zühlke instance of the Platform Plane, which currently serves 445 users, 14 partners, and 22 spaces across 15 Kubernetes clusters. Here are the highlights:\nPartner Management: The partner concept lets you onboard external companies. Using Azure Entra ID (with Keycloak migration underway), partners bring their own identity. An owner can onboard someone, and within a second, that person gets access to all integrated tools and repositories. Offboarding is equally instant. Compare that to my recent experience at a large company where it took three weeks to get access.\nSpaces: Each space is a network zone using the hub-spoke pattern. Teams get their own isolated environment where they can run VMs, Kubernetes clusters, or whatever they need.\nSecurity (DevSecOps): Every repository is automatically scanned for vulnerabilities, license compliance issues, and secrets using Trivy. Developers do not need to configure anything. Credentials are stored in a vault automatically.\nGolden Path Templates: When creating a new repository, developers can choose from templates that include predefined infrastructure and GitOps configurations.\nContainer Registry: Full vulnerability scanning, layer visualization, and even an AI-powered container analysis feature that was built in just eight hours because the platform APIs made it easy.\nKubernetes Management: Applications deployed via GitOps through Argo CD. Built-in log aggregation through Grafana, service graphs via Tempo, and pre-configured dashboards. Developers do not need to care about logging configuration.\nService Catalog: Developers self-service provision databases, Azure OpenAI endpoints, and more. No passwords, no backup configuration needed.\nRelease Management: Releases are created in the developer cloud and pulled into production environments, with vulnerability reports attached. Release managers in regulated industries can approve deployments with full traceability.\nThe Open Source Discussion # After the demo, I asked the audience three questions: Should we open-source it? What are the benefits and risks? How can we convince management?\nThe discussion was rich and nuanced. Here are the key perspectives that emerged:\nThe \u0026ldquo;land and expand\u0026rdquo; model: One audience member pointed out that companies like HashiCorp and Terraform open-source their tools as a go-to-market strategy. Developers adopt the open-source version, it gets embedded in infrastructure, and then professional services and enterprise licenses follow. The question is whether this business model applies here.\nCommunity is everything: Open-sourcing only makes sense if you can build a community. Without community adoption, it does not help. With a community, you get more developers than you could ever afford to pay. But building that community requires significant investment in marketing, documentation, and onboarding.\nSubscription model compatibility: Since the Platform Plane already uses a subscription model, open-sourcing would not fundamentally change the revenue model. People buy subscriptions for support and services, not for access to the software itself. Those who want to run it without paying for support would never have become paying customers anyway.\n\u0026ldquo;There is no real risk to revenue. The risk is the time investment needed to nurture the community and build critical mass.\u0026rdquo;\nThe onboarding challenge: Setting up the platform currently takes weeks because of the many integrations, different APIs, and customer-specific configurations. If developers cannot get it running quickly, they will not contribute. This same problem exists whether the product is open or closed: a proper product needs great onboarding.\nPartial open-sourcing: One suggestion was to open-source parts of the platform, similar to how Backstage operates. The core is open, and commercial services layer on top. This could attract developers who want to build integrations for their own tools.\nCompetition with existing solutions: The platform competes with Red Hat Developer Hub, Backstage, VMware Tanzu, and others. But none of them cover the full lifecycle from ideation to production the way the Platform Plane does.\nThe Current Position # The honest answer is that we are still evaluating. Right now, the ROI is better without open-sourcing because we are early-stage and cannot yet predict how many clients will adopt the platform. But the arguments for open-sourcing are compelling: more eyeballs on the code improve security, community contributions accelerate development, and adoption could grow faster.\nThe most pragmatic advice from the audience was: focus on making the platform easy to set up and run. Whether it is open or closed, the onboarding experience is what determines adoption.\nKey Takeaways # A developer platform is more than a portal. The Platform Plane covers the full lifecycle from ideation through production, including on-premises deployments. Tool integration through the platform (the floating platform principle) protects you from vendor lock-in and enables tool swaps without disrupting teams. Open-sourcing is a business decision, not a technical one. It requires community building, great onboarding, and a clear revenue model. Subscription models survive open-sourcing. People pay for support and services, not for code access. Onboarding friction is the enemy of both open-source adoption and commercial success. Making setup fast and simple is a prerequisite for either path. The discussion showed that there is no single right answer. The decision depends on the organization\u0026rsquo;s readiness to invest in community building and the strategic bet on market adoption. ","date":"15 March 2025","externalUrl":null,"permalink":"/en/blogs/zuehlke-platform-plane-open-source/","section":"Blogs","summary":"Should we open-source our internal developer platform? That is the question I brought to the audience during this talk. Instead of a traditional presentation, I gave a live demo of the Zühlke Platform Plane and then opened the floor for an honest discussion about the benefits, risks, and realities of open-sourcing a commercial platform product.\n","title":"The Zühlke Platform Plane: Should It Go Open Source?","type":"blogs"},{"content":"","date":"15 March 2025","externalUrl":null,"permalink":"/en/tags/z%C3%BChlke/","section":"Tags","summary":"","title":"Zühlke","type":"tags"},{"content":"","date":"4 March 2025","externalUrl":null,"permalink":"/en/tags/ci/cd/","section":"Tags","summary":"","title":"CI/CD","type":"tags"},{"content":"Imagine a world where security is seamlessly integrated into your development workflow from ideation until production, so that development teams can completely focus on feature development while building secure applications. That is exactly what I presented at the OWASP Chapter Meetup Switzerland. In this talk, I show how platform engineering transforms modern application security and makes DevSecOps a reality at scale.\nToday\u0026rsquo;s Challenges: Walls of Confusion # When I join different companies, I often see the same picture. The business throws ideas over a wall of confusion to the development team. The development team builds something and throws it over another wall to testing. Testing passes it to operations, and operations duct-tapes it into production. The customer gets something they can barely use.\nThese walls of confusion come from the silo organization that still exists in many enterprises. Business, engineering, QA, and operations each have their own business unit, their own goals, and their own incentives. The result: misalignment, legacy processes, and security treated as an afterthought.\nDevSecOps: Bringing Everyone Together # DevSecOps is a mindset, a culture, and a set of technical practices that helps align everyone across the value stream. The debate about terminology (DevSecOps vs. DevBizOps vs. DevSecBizARCompQAOps) is pointless. In the end, DevOps is about bringing all people, processes, and technology together to continuously deliver secure value.\nThe numbers speak for themselves. The State of DevOps Report 2024 shows that high performers have 182 times more deployments, 127 times faster lead time, and significantly better security, quality, and customer satisfaction. This is what every CIO and CEO wants.\nThe Cognitive Load Problem # But here is the challenge: implementing DevSecOps is complex. When you look at the CI/CD pipeline alone, baking in security is a huge effort. I have created 25 videos just on implementing DevSecOps in CI/CD pipelines for GitHub and GitLab.\nAnd that is just one piece. Development teams also need infrastructure (cloud or on-prem), a runtime environment, monitoring, security tools, cost management, and access management. In larger companies, this creates an enormous cognitive load. Multiple application stacks, tool complexity, and constant maintenance drain productivity.\nThe question becomes: Can you scale DevSecOps at all? Or should we go back to silos?\nThe Digital Factory: Where the Industry Is Moving # The answer is not silos. The answer is the digital factory model, where lean portfolio management aligns strategy with execution, product management organizes products and teams, product teams do DevSecOps with end-to-end responsibility, and the platform team builds the foundation that makes it all possible.\nThis is where platform engineering comes in. Platform engineering is the industrialization of software engineering. Instead of every team building their own toolchain and infrastructure, you standardize how software is built and delivered across the company.\nPlatform Engineering in Practice # The target operating model is clear: product teams focus on feature development with a small technology stack, while a self-service platform built by a platform team handles the heavy lifting. The platform is an internal product. Its customers are the product teams.\nThe key principles are straightforward. The platform exposes all tools and capabilities the product teams need. Monitoring, for example, is provided as a capability by the platform team through tools like Grafana and Prometheus, but the actual monitoring is done by the product teams because they own the end-to-end responsibility for their product.\nAt Zühlke, we built such a platform together with LGT, a private bank. It supports 462 developers across 14 partners and 22 spaces with 15 Kubernetes clusters. Key features include instant onboarding and offboarding through identity federation, repository scanning with Trivy and secret detection at the platform level, container image scanning with AI-powered analysis, standardized observability with pre-built Grafana dashboards, a self-service catalog for databases, AI services, and infrastructure, and a release portal with vulnerability gating.\nCodify Your Security Policies # One of the most important lessons: do not write your security policies into Word documents or Confluence pages. Codify them into the platform. When policies are automated, no developer needs to read a 50-page security guideline. The rules are applied automatically, and teams get speed and security at the same time.\nAI as a Capability on the Platform # Where does AI fit? AI is just a capability on the platform. You expose it through an API to your product teams in a governed and standardized way. When you zoom in, that \u0026ldquo;small box\u0026rdquo; is actually quite large: application layer (chatbots, coding assistants, synthetic data tools), tools layer (prompt engineering, vector databases, RAG, fine-tuning), model hub (versioned models), and GenAI infrastructure (cloud and on-prem).\nHaving AI governed through the platform was a game changer for us. Before, everyone was doing their own AI experiments and our CISO was not happy. With the platform, AI usage became secure, governed, and productive.\nFrom Ticket-Ops to Enabling IT # The IT of the future is not about filing tickets and waiting weeks for infrastructure. It is about providing preconfigured services, golden path templates, and entire development factories through a self-service platform. This is what I call the enabling IT, and it is where the industry is heading.\nKey Takeaways # DevSecOps is not dead: Platform engineering enables teams to do DevSecOps at scale Build a self-service platform: Your platform is an internal product with the development teams as customers Codify all policies: Security, compliance, and governance rules belong in the platform, not in documents Use the floating platform concept: Integrate tools over the platform, never directly together, so you can replace any tool without disruption AI is a capability, not a strategy: Provide AI through your platform in a governed, secure way New applications in 15 minutes: With certificates, backups, security, and monitoring baked in from day one ","date":"4 March 2025","externalUrl":null,"permalink":"/en/blogs/continuous-security-with-devsecops-and-platform-engineering/","section":"Blogs","summary":"Imagine a world where security is seamlessly integrated into your development workflow from ideation until production, so that development teams can completely focus on feature development while building secure applications. That is exactly what I presented at the OWASP Chapter Meetup Switzerland. In this talk, I show how platform engineering transforms modern application security and makes DevSecOps a reality at scale.\n","title":"Continuous Security with DevSecOps and Platform Engineering","type":"blogs"},{"content":"","date":"4 March 2025","externalUrl":null,"permalink":"/en/tags/devsecops/","section":"Tags","summary":"","title":"DevSecOps","type":"tags"},{"content":"Stellen Sie sich eine Welt vor, in der Sicherheit nahtlos in Ihren Entwicklungsworkflow integriert ist, von der Idee bis zur Produktion, sodass sich Entwicklungsteams vollständig auf die Feature-Entwicklung konzentrieren können und dabei sichere Anwendungen bauen. Genau das habe ich am OWASP Chapter Meetup Schweiz präsentiert. In diesem Vortrag zeige ich, wie Platform Engineering die moderne Anwendungssicherheit transformiert und DevSecOps im grossen Massstab zur Realität macht.\nHeutige Herausforderungen: Mauern der Verwirrung # Wenn ich bei verschiedenen Unternehmen einsteige, sehe ich oft dasselbe Bild. Der Fachbereich wirft Ideen über eine Mauer der Verwirrung zum Entwicklungsteam. Das Entwicklungsteam baut etwas und wirft es über eine weitere Mauer zum Testing. Das Testing reicht es an den Betrieb weiter, und der Betrieb klebt es mit Klebeband in die Produktion. Der Kunde bekommt etwas, das er kaum nutzen kann.\nDiese Mauern entstehen durch die Siloorganisation, die in vielen Unternehmen noch existiert. Business, Engineering, QA und Betrieb haben jeweils ihre eigene Organisationseinheit, ihre eigenen Ziele und ihre eigenen Anreize. Das Ergebnis: Fehlausrichtung, veraltete Prozesse und Sicherheit als Nachgedanke.\nDevSecOps: Alle an einen Tisch bringen # DevSecOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken, die dabei helfen, alle Beteiligten über den gesamten Wertstrom hinweg auszurichten. Die Debatte über die Terminologie (DevSecOps vs. DevBizOps vs. DevSecBizARCompQAOps) führt nirgendwohin. Am Ende geht es bei DevOps darum, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich sicheren Wert zu liefern.\nDie Zahlen sprechen für sich. Der State of DevOps Report 2024 zeigt, dass High Performer 182-mal mehr Deployments haben, eine 127-mal schnellere Durchlaufzeit und deutlich bessere Sicherheit, Qualität und Kundenzufriedenheit. Genau das wollen CIO und CEO.\nDas Problem der kognitiven Last # Hier liegt die Herausforderung: DevSecOps umzusetzen ist komplex. Allein das Einbauen von Sicherheit in die CI/CD-Pipeline ist ein enormer Aufwand. Ich habe 25 Videos allein zur Implementierung von DevSecOps in CI/CD-Pipelines für GitHub und GitLab erstellt.\nUnd das ist nur ein Puzzlestück. Entwicklungsteams brauchen auch Infrastruktur (Cloud oder On-Prem), eine Laufzeitumgebung, Monitoring, Sicherheitstools, Kostenmanagement und Zugriffsmanagement. In grösseren Unternehmen erzeugt das eine enorme kognitive Last. Multiple Anwendungsstacks, Toolkomplexität und ständige Wartung fressen die Produktivität auf.\nDie Frage lautet: Lässt sich DevSecOps überhaupt skalieren? Oder sollten wir zurück zu Silos?\nDie digitale Fabrik: Wohin sich die Industrie bewegt # Die Antwort sind nicht Silos. Die Antwort ist das Digital-Factory-Modell, bei dem Lean Portfolio Management die Strategie mit der Umsetzung ausrichtet, Produktmanagement Produkte und Teams organisiert, Produktteams DevSecOps mit End-to-End-Verantwortung betreiben und das Plattformteam das Fundament baut, das alles ermöglicht.\nHier kommt Platform Engineering ins Spiel. Platform Engineering ist die Industrialisierung der Softwareentwicklung. Statt dass jedes Team seine eigene Toolchain und Infrastruktur aufbaut, wird standardisiert, wie Software im Unternehmen gebaut und ausgeliefert wird.\nPlatform Engineering in der Praxis # Das Zielbetriebsmodell ist klar: Produktteams fokussieren sich auf Feature-Entwicklung mit einem kleinen Technologie-Stack, während eine Self-Service-Plattform, gebaut vom Plattformteam, die schwere Arbeit übernimmt. Die Plattform ist ein internes Produkt. Ihre Kunden sind die Produktteams.\nDie Schlüsselprinzipien sind unkompliziert. Die Plattform stellt alle Werkzeuge und Fähigkeiten bereit, die Produktteams brauchen. Monitoring beispielsweise wird als Fähigkeit vom Plattformteam über Tools wie Grafana und Prometheus bereitgestellt, aber das tatsächliche Monitoring wird von den Produktteams durchgeführt, weil sie die End-to-End-Verantwortung für ihr Produkt tragen.\nBei Zühlke haben wir eine solche Plattform gemeinsam mit LGT, einer Privatbank, aufgebaut. Sie unterstützt 462 Entwickler über 14 Partner und 22 Spaces mit 15 Kubernetes-Clustern. Zu den wichtigsten Funktionen gehören: sofortiges Onboarding und Offboarding durch Identity Federation, Repository-Scanning mit Trivy und Secret Detection auf Plattformebene, Container-Image-Scanning mit KI-gestützter Analyse, standardisierte Observability mit vorgefertigten Grafana-Dashboards, ein Self-Service-Katalog für Datenbanken, KI-Services und Infrastruktur sowie ein Release-Portal mit Schwachstellen-Gating.\nSicherheitsrichtlinien kodifizieren # Eine der wichtigsten Lektionen: Schreiben Sie Ihre Sicherheitsrichtlinien nicht in Word-Dokumente oder Confluence-Seiten. Kodifizieren Sie sie in die Plattform. Wenn Richtlinien automatisiert sind, muss kein Entwickler einen 50-seitigen Sicherheitsleitfaden lesen. Die Regeln werden automatisch angewendet, und Teams erhalten gleichzeitig Geschwindigkeit und Sicherheit.\nKI als Fähigkeit auf der Plattform # Wo passt KI hinein? KI ist einfach eine Fähigkeit auf der Plattform. Sie wird über eine API den Produktteams in einer gouvernierten und standardisierten Weise bereitgestellt. Wenn man hineinzoomt, ist diese «kleine Box» tatsächlich recht gross: die Anwendungsschicht (Chatbots, Coding-Assistenten, synthetische Datentools), die Werkzeugschicht (Prompt Engineering, Vektordatenbanken, RAG, Fine-Tuning), der Model Hub (versionierte Modelle) und die GenAI-Infrastruktur (Cloud und On-Prem).\nDie Governance von KI über die Plattform war für uns ein Gamechanger. Vorher machte jeder seine eigenen KI-Experimente und unser CISO war nicht glücklich. Mit der Plattform wurde die KI-Nutzung sicher, gouverniert und produktiv.\nVon Ticket-Ops zu Enabling IT # Die IT der Zukunft dreht sich nicht darum, Tickets zu eröffnen und wochenlang auf Infrastruktur zu warten. Es geht darum, vorkonfigurierte Services, Golden-Path-Templates und ganze Entwicklungsfabriken über eine Self-Service-Plattform bereitzustellen. Das nenne ich die Enabling IT, und dahin bewegt sich die Branche.\nKernaussagen # DevSecOps ist nicht tot: Platform Engineering befähigt Teams, DevSecOps im grossen Massstab umzusetzen Bauen Sie eine Self-Service-Plattform: Ihre Plattform ist ein internes Produkt mit den Entwicklungsteams als Kunden Kodifizieren Sie alle Richtlinien: Sicherheits-, Compliance- und Governance-Regeln gehören in die Plattform, nicht in Dokumente Nutzen Sie das Floating-Platform-Konzept: Integrieren Sie Tools über die Plattform, nie direkt miteinander, damit Sie jedes Tool ohne Störung ersetzen können KI ist eine Fähigkeit, keine Strategie: Stellen Sie KI über Ihre Plattform gouverniert und sicher bereit Neue Anwendungen in 15 Minuten: Mit Zertifikaten, Backups, Sicherheit und Monitoring ab dem ersten Tag ","date":"4. March 2025","externalUrl":null,"permalink":"/de/blogs/kontinuierliche-sicherheit-mit-devsecops-und-platform-engineering/","section":"Blogs","summary":"Stellen Sie sich eine Welt vor, in der Sicherheit nahtlos in Ihren Entwicklungsworkflow integriert ist, von der Idee bis zur Produktion, sodass sich Entwicklungsteams vollständig auf die Feature-Entwicklung konzentrieren können und dabei sichere Anwendungen bauen. Genau das habe ich am OWASP Chapter Meetup Schweiz präsentiert. In diesem Vortrag zeige ich, wie Platform Engineering die moderne Anwendungssicherheit transformiert und DevSecOps im grossen Massstab zur Realität macht.\n","title":"Kontinuierliche Sicherheit mit DevSecOps und Platform Engineering","type":"blogs"},{"content":"","date":"4 March 2025","externalUrl":null,"permalink":"/en/tags/security/","section":"Tags","summary":"","title":"Security","type":"tags"},{"content":"Security is no longer an afterthought in modern software development. It must be integrated seamlessly into every stage of the development lifecycle. This talk delves into the transformative power of combining DevSecOps principles with Platform Engineering to address the challenges of ensuring continuous security in a fast-paced, agile environment.\nWhat This Talk Covers # Discover how a robust, self-service platform empowers development teams by automating security checks, integrating essential tools, and providing standardized environments that reduce complexity and cognitive load. Learn how Platform Engineering fosters collaboration, scalability, and visibility, enabling organizations to deliver secure, high-quality applications at speed.\nKey Messages # 1. Security as Part of the Development Lifecycle Security must be integrated seamlessly into every stage. DevSecOps principles ensure that security is not a gate at the end, but a continuous practice throughout.\n2. Platform Engineering as Enabler A robust, self-service platform empowers development teams by automating security checks, integrating essential tools, and providing standardized environments that reduce complexity and cognitive load.\n3. From Constraint to Innovation Driver Through real-world examples and actionable insights, this talk demonstrates how the synergy of DevSecOps and Platform Engineering transforms application security into a driver of innovation and trust.\n","date":"19 February 2025","externalUrl":null,"permalink":"/en/speaking/continuous-security-with-devsecops/","section":"Speaking","summary":"Security is no longer an afterthought in modern software development. It must be integrated seamlessly into every stage of the development lifecycle. This talk delves into the transformative power of combining DevSecOps principles with Platform Engineering to address the challenges of ensuring continuous security in a fast-paced, agile environment.\n","title":"Continuous Security with DevSecOps: How Platform Engineering Transforms Modern Application Security","type":"speaking"},{"content":"","date":"25 January 2025","externalUrl":null,"permalink":"/en/tags/agile/","section":"Tags","summary":"","title":"Agile","type":"tags"},{"content":"How can organizations reduce costs while still delivering real value to their customers? This is a question I get asked frequently, and one that a client recently brought to me when they wanted a keynote for their solution architects. In this talk, I walk through the key principles and practical techniques for continuously delivering value while cutting unnecessary spending.\n80% of Features Are Rarely or Never Used # Let that number sink in. Studies consistently show that roughly 80% of features in an average software product are rarely or never used. On top of that, the maintenance cost of any feature is an additional 40 to 80% of the original development cost over its lifecycle.\nLet me give you a quick calculation. If you develop 10 features at 100,000 Swiss Francs each, your total development cost is 1 million. Add maintenance at 40 to 80%, and you are looking at total costs between 1.4 and 1.8 million Swiss Francs. Since 80% of those features are rarely used, the potential savings in development alone are 800,000 Swiss Francs, plus 320,000 to 640,000 in maintenance savings. That is over 1 million Swiss Francs in total savings.\n\u0026ldquo;Doing the wrong thing right is not nearly as good as doing the right thing wrong.\u0026rdquo; — Dr. Russell Ackoff\nBuilding the Right Thing Right # There are two dimensions to delivering value efficiently. Building the right thing is about effectiveness: aligning your solutions to real business and user needs. Building the thing right is about efficiency: applying solid software engineering practices to deliver quickly and maintain easily.\nYou are only successful when both come together. And if you think this is not your responsibility because \u0026ldquo;the business ordered it,\u0026rdquo; remember: if you run with the crowd, you share the blame. It is your company, and features that are never used still affect the bottom line.\nFrom Projects to Products # Part of the problem is that many organizations still think in projects instead of products. A project has a fixed scope, a fixed budget, and a set number of features to deliver. It maximizes output: the number of things produced. A product, on the other hand, focuses on outcomes: solving real customer problems and changing behavior.\nWhen we move from project thinking to product thinking, we stop asking \u0026ldquo;How many features can we deliver?\u0026rdquo; and start asking \u0026ldquo;What problem are we solving?\u0026rdquo;\nThe Lean Startup Cycle # The solution is to use the Lean Startup cycle. We acknowledge that we have many ideas, most of them not great, and we build minimal viable products (MVPs) to test our hypotheses. I recommend using the SAFe epic hypothesis statement format, which includes an elevator pitch, a business outcome with measurable benefits, leading indicators for early validation, and non-functional requirements.\nStart with the customer and the problem to solve. Do not start with the technology and work your way back to the customer.\nI walked through a practical example: a Swiss dentist company wanting a mobile app for scheduling appointments. Using paper prototypes, they discovered customers did not want another mobile app. They pivoted to a web application. By testing early and cheaply, they avoided building something nobody wanted.\nMaking Cost-Effective Decisions with MCDA # When you have multiple options in your solution space, use the Multiple Criteria Decision Analysis (MCDA) technique. It is simple, powerful, and I use it nearly every week.\nThe steps are straightforward: define your objective, list the criteria with weights (cost effectiveness at 30%, scalability at 20%, etc.), list your options (monolith, SOA, microservices, serverless), rate each option, and calculate weighted totals. The key insight is that there is no silver bullet. Every solution has disadvantages that need to be mitigated. MCDA makes those trade-offs visible and deliberate.\nValue Stream Mapping: Understanding the Whole System # To identify and reduce waste, you need to look at your organization as a sociotechnical system. Processes, technology, and people must work together like a well-maintained factory. This requires whole-system thinking.\nA value stream is a sequence of steps that delivers value to the customer. You have operational value streams (starting and ending with the customer) and development value streams that support them. By mapping your development value stream, you can measure process time, lead time, and the percentage complete and accurate at each step.\nIn one example I showed, the total lead time was 2,160 hours with only 7% of that time spent on value-adding work. By identifying bottlenecks (testing had 8 hours of process time but 336 hours of lead time) and applying automation, the future state could reduce lead time to 147 hours. That is a massive improvement in time to market, and faster time to market means faster value generation.\nWhat About AI? # Yes, AI can help across the value stream. But do not start with the technology. Start with the problem. If you can remove or simplify a process step, that is far better than replacing it with an AI. And remember: every AI agent you build will need maintenance, consuming that same 40 to 80% of development cost over its lifecycle. Always find the simplest solution first.\nKey Takeaways # Build the right thing right: Focus on effectiveness first, then efficiency Use the Lean Startup cycle: Test hypotheses early with MVPs and paper prototypes Focus on outcomes, not output: Move from project thinking to product thinking Use MCDA for decisions: Make trade-offs visible and mitigate disadvantages deliberately Map your value streams: Understand how value flows, identify bottlenecks, and improve the whole system Start with the problem, not the technology: This applies to AI as much as anything else Remember the maintenance cost: Every feature, every AI agent needs ongoing care at 40 to 80% of its development cost ","date":"25 January 2025","externalUrl":null,"permalink":"/en/blogs/how-to-reduce-costs-while-continuously-delivering-value/","section":"Blogs","summary":"How can organizations reduce costs while still delivering real value to their customers? This is a question I get asked frequently, and one that a client recently brought to me when they wanted a keynote for their solution architects. In this talk, I walk through the key principles and practical techniques for continuously delivering value while cutting unnecessary spending.\n","title":"How to Reduce Costs While Continuously Delivering Value","type":"blogs"},{"content":"Wie können Organisationen Kosten senken und gleichzeitig echten Mehrwert für ihre Kunden liefern? Diese Frage wird mir regelmässig gestellt. Kürzlich bat mich ein Kunde, eine Keynote für seine Lösungsarchitekten genau zu diesem Thema zu halten. In diesem Vortrag gehe ich die wichtigsten Prinzipien und praktischen Techniken durch, um kontinuierlich Wert zu liefern und gleichzeitig unnötige Ausgaben zu vermeiden.\n80% der Features werden selten oder nie genutzt # Diese Zahl muss man erst einmal verdauen. Studien zeigen konsistent, dass rund 80% der Features eines durchschnittlichen Softwareprodukts selten oder nie genutzt werden. Dazu kommen Wartungskosten von 40 bis 80% der ursprünglichen Entwicklungskosten über den gesamten Lebenszyklus.\nEin kurzes Rechenbeispiel: Wenn Sie 10 Features zu je 100'000 Schweizer Franken entwickeln, betragen die Gesamtentwicklungskosten 1 Million. Addieren Sie Wartungskosten von 40 bis 80%, und Sie landen bei Gesamtkosten zwischen 1,4 und 1,8 Millionen Schweizer Franken. Da 80% dieser Features kaum genutzt werden, ergeben sich allein bei der Entwicklung potenzielle Einsparungen von 800'000 Franken, plus 320'000 bis 640'000 Franken bei der Wartung. Das sind über 1 Million Schweizer Franken an möglichen Einsparungen.\n«Das Falsche richtig zu tun ist bei weitem nicht so gut wie das Richtige falsch zu tun.» — Dr. Russell Ackoff\nDas Richtige richtig bauen # Es gibt zwei Dimensionen für die effiziente Wertlieferung. Das Richtige zu bauen betrifft die Effektivität: Lösungen an den tatsächlichen Geschäfts- und Nutzerbedürfnissen auszurichten. Das Ding richtig zu bauen betrifft die Effizienz: solide Software-Engineering-Praktiken anzuwenden, um schnell zu liefern und einfach zu warten.\nErfolg entsteht nur, wenn beides zusammenkommt. Und wer denkt, das sei nicht die eigene Verantwortung, weil «der Fachbereich es bestellt hat», sollte bedenken: Wer mit der Masse mitläuft, trägt die Mitverantwortung. Es ist Ihr Unternehmen, und Features, die nie genutzt werden, belasten trotzdem das Ergebnis.\nVon Projekten zu Produkten # Ein Teil des Problems ist, dass viele Organisationen immer noch in Projekten statt in Produkten denken. Ein Projekt hat einen fixen Umfang, ein festes Budget und eine festgelegte Anzahl Features. Es maximiert den Output: die Menge der produzierten Dinge. Ein Produkt hingegen fokussiert auf Outcomes: echte Kundenprobleme lösen und Verhalten verändern.\nWenn wir vom Projektdenken zum Produktdenken wechseln, hören wir auf zu fragen «Wie viele Features können wir liefern?» und fangen an zu fragen «Welches Problem lösen wir?»\nDer Lean-Startup-Zyklus # Die Lösung besteht darin, den Lean-Startup-Zyklus zu nutzen. Wir erkennen an, dass wir viele Ideen haben, die meisten davon nicht besonders gut, und bauen minimale funktionsfähige Produkte (MVPs), um unsere Hypothesen zu testen. Ich empfehle das SAFe Epic Hypothesis Statement Format, das einen Elevator Pitch, einen Business Outcome mit messbaren Vorteilen, Frühindikatoren zur Validierung und nicht-funktionale Anforderungen umfasst.\nBeginnen Sie beim Kunden und dem zu lösenden Problem. Beginnen Sie nicht bei der Technologie und arbeiten Sie sich zurück zum Kunden.\nIm Vortrag zeigte ich ein praktisches Beispiel: Ein Schweizer Zahnarztnetzwerk wollte eine mobile App für Terminbuchungen. Mit Papierprototypen stellten sie fest, dass die Kunden keine weitere App wollten. Sie schwenkten auf eine Webapplikation um. Durch frühes und günstiges Testen vermieden sie es, etwas zu bauen, das niemand nutzen würde.\nKosteneffektive Entscheidungen mit MCDA # Wenn Sie mehrere Optionen im Lösungsraum haben, nutzen Sie die Multiple Criteria Decision Analysis (MCDA). Die Methode ist einfach, wirkungsvoll, und ich verwende sie fast jede Woche.\nDie Schritte sind unkompliziert: Definieren Sie das Ziel, listen Sie die Kriterien mit Gewichtungen auf (Kosteneffizienz 30%, Skalierbarkeit 20%, etc.), listen Sie Ihre Optionen auf (Monolith, SOA, Microservices, Serverless), bewerten Sie jede Option und berechnen Sie gewichtete Gesamtwerte. Die zentrale Erkenntnis: Es gibt keine Universallösung. Jede Lösung hat Nachteile, die adressiert werden müssen. MCDA macht diese Abwägungen sichtbar und bewusst.\nValue Stream Mapping: Das Gesamtsystem verstehen # Um Verschwendung zu identifizieren und zu reduzieren, müssen Sie Ihre Organisation als soziotechnisches System betrachten. Prozesse, Technologie und Menschen müssen wie eine gut gewartete Fabrik zusammenarbeiten. Das erfordert systemisches Denken.\nEin Value Stream ist eine Abfolge von Schritten, die dem Kunden Wert liefert. Es gibt operative Value Streams (die beim Kunden beginnen und enden) und Entwicklungs-Value-Streams, die diese unterstützen. Durch das Mapping Ihres Entwicklungs-Value-Streams können Sie Prozesszeit, Durchlaufzeit und den Prozentsatz «Complete and Accurate» an jedem Schritt messen.\nIn einem Beispiel aus dem Vortrag betrug die Gesamtdurchlaufzeit 2'160 Stunden, wobei nur 7% der Zeit auf wertschöpfende Arbeit entfielen. Durch das Identifizieren von Engpässen (Tests hatten 8 Stunden Prozesszeit bei 336 Stunden Durchlaufzeit) und den Einsatz von Automatisierung konnte der Zielzustand die Durchlaufzeit auf 147 Stunden reduzieren. Das ist eine massive Verbesserung der Time-to-Market, und schnellere Time-to-Market bedeutet schnellere Wertgenerierung.\nWas ist mit KI? # Ja, KI kann im gesamten Value Stream helfen. Aber beginnen Sie nicht mit der Technologie. Beginnen Sie mit dem Problem. Wenn Sie einen Prozessschritt entfernen oder vereinfachen können, ist das besser als ihn durch eine KI zu ersetzen. Und denken Sie daran: Jeder KI-Agent, den Sie bauen, braucht Wartung, die dieselben 40 bis 80% der Entwicklungskosten über den Lebenszyklus verschlingt. Finden Sie immer zuerst die einfachste Lösung.\nKernaussagen # Das Richtige richtig bauen: Zuerst auf Effektivität fokussieren, dann auf Effizienz Den Lean-Startup-Zyklus nutzen: Hypothesen früh mit MVPs und Papierprototypen testen Auf Outcomes statt Output fokussieren: Vom Projektdenken zum Produktdenken wechseln MCDA für Entscheidungen verwenden: Abwägungen sichtbar machen und Nachteile bewusst adressieren Value Streams mappen: Verstehen, wie Wert durch das System fliesst, Engpässe identifizieren und das Gesamtsystem verbessern Beim Problem beginnen, nicht bei der Technologie: Das gilt für KI genauso wie für alles andere Die Wartungskosten beachten: Jedes Feature, jeder KI-Agent braucht laufende Pflege mit 40 bis 80% der Entwicklungskosten ","date":"25. January 2025","externalUrl":null,"permalink":"/de/blogs/kosten-senken-und-kontinuierlich-wert-liefern/","section":"Blogs","summary":"Wie können Organisationen Kosten senken und gleichzeitig echten Mehrwert für ihre Kunden liefern? Diese Frage wird mir regelmässig gestellt. Kürzlich bat mich ein Kunde, eine Keynote für seine Lösungsarchitekten genau zu diesem Thema zu halten. In diesem Vortrag gehe ich die wichtigsten Prinzipien und praktischen Techniken durch, um kontinuierlich Wert zu liefern und gleichzeitig unnötige Ausgaben zu vermeiden.\n","title":"Kosten senken und kontinuierlich Wert liefern","type":"blogs"},{"content":"","date":"25 January 2025","externalUrl":null,"permalink":"/en/tags/lean-startup/","section":"Tags","summary":"","title":"Lean Startup","type":"tags"},{"content":"","date":"25 January 2025","externalUrl":null,"permalink":"/en/tags/value-stream-mapping/","section":"Tags","summary":"","title":"Value Stream Mapping","type":"tags"},{"content":"Many software organizations spend too much effort building and maintaining features that create little real value. This talk shows how to reduce cost not by slowing down delivery, but by improving effectiveness and efficiency at the same time.\nWhat This Talk Covers # Teams must focus on solving the right customer problems, not just producing more output. This presentation demonstrates how product thinking, hypothesis-driven development, and outcome orientation help avoid waste.\nKey Messages # 1. Effectiveness Over Output Many teams optimize for throughput when the real problem is building the wrong things. Product thinking and hypothesis-driven development help focus on what truly creates value.\n2. Value Stream Mapping for Flow Value stream mapping is a practical way to identify bottlenecks, improve flow, and increase delivery performance across socio-technical systems.\n3. AI for Resolving Constraints Structured decision-making and targeted use of AI can help teams resolve the most critical constraints in their development value stream.\n","date":"21 January 2025","externalUrl":null,"permalink":"/en/speaking/continuously-deliver-value-while-reducing-cost/","section":"Speaking","summary":"Many software organizations spend too much effort building and maintaining features that create little real value. This talk shows how to reduce cost not by slowing down delivery, but by improving effectiveness and efficiency at the same time.\n","title":"Continuously Deliver Value While Reducing Cost","type":"speaking"},{"content":"","date":"21 January 2025","externalUrl":null,"permalink":"/en/tags/product-thinking/","section":"Tags","summary":"","title":"Product Thinking","type":"tags"},{"content":"","date":"21 January 2025","externalUrl":null,"permalink":"/en/tags/value-streams/","section":"Tags","summary":"","title":"Value Streams","type":"tags"},{"content":"","date":"7 December 2024","externalUrl":null,"permalink":"/en/tags/commerce/","section":"Tags","summary":"","title":"Commerce","type":"tags"},{"content":"","date":"7. December 2024","externalUrl":null,"permalink":"/de/tags/handel/","section":"Tags","summary":"","title":"Handel","type":"tags"},{"content":"What does \u0026ldquo;continuous value flow through platform engineering\u0026rdquo; actually mean? In this Zühlke Commerce Talk, I sat down with my colleague Dennis Kolmitz, Engagement Manager at Zühlke responsible for our commerce customers, to discuss exactly that. We explored why platform engineering is becoming essential for commerce organizations that want to innovate faster, reduce friction, and keep their best talent.\nFrom Projects to Products # The concept of continuous value flow comes from a fundamental shift: moving away from projects toward products. Projects have a start date and an end date. But products, especially in retail, need continuous updates. Your customers expect the app to get better, more secure, and more feature-rich over time. That requires continuity.\nWhen organizations operate in project mode, they plan a mobile app or an online shop, build it, and then it just sits there. A gap emerges until the next project starts. Teams get reassigned or even let go. Knowledge is lost. But when you treat it as a product, you establish a value stream that you fund continuously. The product keeps evolving, and the team stays intact.\nWhat Is Platform Engineering? # Platform engineering is a discipline that has emerged because DevOps put an enormous cognitive load on development teams. When teams started doing DevOps, they suddenly had to handle operations, logging, monitoring, and much more on top of building features. That overload is where platform engineering comes in.\nA platform engineering team builds a platform that offers self-service capabilities to development teams. Need a CI/CD pipeline? The platform team provides it. Need authentication? It is available as a service. The development teams can focus on building business features instead of reinventing infrastructure.\nPlatform engineering is not about building a small internal tool. It is a strategic decision, usually made at the executive level, to create an internal product whose customers are the development teams.\nThe Business Case # Dennis brought a crucial perspective to the conversation: the business value. In commerce, the pressure is relentless. Everything needs to be faster, better, and cheaper. Margins are tight. The tension between IT and business is real, and platform engineering can help resolve it by enabling teams to deliver value faster.\nWhen teams are enabled and empowered, the constant conflict between \u0026ldquo;the business wants more\u0026rdquo; and \u0026ldquo;IT cannot deliver fast enough\u0026rdquo; starts to dissolve. Everyone\u0026rsquo;s needs get addressed more effectively.\nWar for Talent # Nobody wants to work with outdated technologies, outdated mindsets, outdated cultures, or outdated processes. When talent joins a company today, they ask whether the organization practices DevOps or platform engineering. They do not want to work in a project where everything follows the waterfall model, where there are silo organizations, where people throw things over the \u0026ldquo;wall of confusion,\u0026rdquo; and where teams work against each other instead of together. That is not an environment anyone wants.\nPlatform engineering creates the kind of modern working environment that attracts and retains talent, both on the technical and the business side.\nInnovation Through Experimentation # One of the most powerful benefits of a product-based approach with platform engineering is the ability to experiment. Management can say: \u0026ldquo;Let\u0026rsquo;s try something new.\u0026rdquo; They bring a new idea into an existing value stream, define leading indicators to test their hypothesis, bring it to market, and see if it resonates. If it does not, they simply stop. The value stream is already there, so there is no wasted infrastructure.\nThis ability to experiment drives innovation and gives both technical and business team members the freedom to bring creative ideas to life. As Dennis put it: when people can try things out, it is fulfilling, because they can contribute their own ideas.\nThe Mindset Shift: Whole System Thinking # When organizations come to us with their challenges, they often say things like \u0026ldquo;make our pipeline faster\u0026rdquo; or \u0026ldquo;we need to speed up development.\u0026rdquo; You can do that, but you have to look at the whole picture. We call this whole system thinking. A value stream goes from idea to production, covering an entire product. If you only turn one dial, it might have a positive effect on that one component but a negative effect on another.\nThat is why we always start with a root cause analysis. What problem are we really solving? And why do we want to solve it? The most common driver we see is that teams can no longer focus on business features because they are overloaded with operational tasks, and that is where platform engineering becomes the solution.\nPlatform Engineering Is a Transformation # An important insight from our discussion: platform engineering is essentially a transformation. Teams are transformed because certain responsibilities move to the platform team. A platform gets built, services get consumed by different teams, and the way of working fundamentally changes.\nBut here is the key point: it is not a transformation project with a start and end date. It is an internal product, an internal service. It will never end. It continuously evolves as new technologies emerge, including AI services that the platform team can provide, such as hosting large language models or providing APIs that other teams can use.\nKey Takeaways # Shift from projects to products. Continuous value flow requires treating your software as a product with ongoing investment, not a project with a fixed end date. Platform engineering reduces cognitive load. By providing self-service capabilities, it frees development teams to focus on business features. It is a strategic investment. Platform engineering is not something you \u0026ldquo;just do.\u0026rdquo; It requires executive-level commitment and proper funding. The platform team builds an internal product. Think of it as product development for your own teams, with a product owner who constantly asks: \u0026ldquo;What do my internal customers need?\u0026rdquo; Whole system thinking is essential. Do not just optimize one part. Look at the entire value stream from idea to production. Experimentation drives innovation. A product-based approach makes it easy to test new ideas with low risk. Talent retention matters. Modern engineering practices create the environment that top talent expects. ","date":"7 December 2024","externalUrl":null,"permalink":"/en/blogs/platform-engineering-continuous-value-flow-in-commerce/","section":"Blogs","summary":"What does “continuous value flow through platform engineering” actually mean? In this Zühlke Commerce Talk, I sat down with my colleague Dennis Kolmitz, Engagement Manager at Zühlke responsible for our commerce customers, to discuss exactly that. We explored why platform engineering is becoming essential for commerce organizations that want to innovate faster, reduce friction, and keep their best talent.\n","title":"Platform Engineering: How Continuous Value Flow Transforms Commerce","type":"blogs"},{"content":"Kontinuierlicher Wertfluss durch Platform Engineering. Was heisst das eigentlich? Im Zühlke Commerce Talk habe ich zusammen mit meinem Kollegen Dennis Kolmitz, Engagement Manager bei Zühlke und verantwortlich für unsere Commerce-Kunden, genau darüber gesprochen. Wir haben erkundet, warum Platform Engineering für Handelsunternehmen essenziell wird, die schneller innovieren, Reibungsverluste reduzieren und ihre besten Talente halten wollen.\nVon Projekten zu Produkten # Das Konzept des kontinuierlichen Wertflusses kommt von einem fundamentalen Wandel: weg von Projekten, hin zu Produkten. Projekte haben einen Start- und einen Endpunkt. Aber Produkte, gerade im Retail-Bereich, brauchen kontinuierliche Updates. Die Kunden erwarten, dass die App besser, sicherer und funktionsreicher wird. Das erfordert Kontinuität.\nWenn Unternehmen im Projektmodus arbeiten, planen sie eine Mobile App oder einen Onlineshop, bauen ihn, und dann steht er einfach da. Es entsteht eine Lücke, bis das nächste Projekt startet. Teams werden umverteilt oder sogar entlassen. Wissen geht verloren. Wenn man es aber als Produkt behandelt, etabliert man einen Wertstrom, der kontinuierlich finanziert wird. Das Produkt entwickelt sich weiter, und das Team bleibt zusammen.\nWas ist Platform Engineering? # Platform Engineering ist eine neue Disziplin, die entstanden ist, weil DevOps einen enormen kognitiven Load auf die Entwicklungsteams gebracht hat. Als die Teams anfingen, DevOps zu machen, mussten sie sich plötzlich auch um den Betrieb kümmern, um Logging, Monitoring und vieles mehr, zusätzlich zum Bauen von Features. Diese Überlastung ist der Ausgangspunkt für Platform Engineering.\nEin Platform-Engineering-Team baut eine Plattform, die Self-Service-Capabilities für die Entwicklungsteams anbietet. Braucht man eine CI/CD-Pipeline? Das Plattform-Team stellt sie bereit. Braucht man Authentisierung? Sie steht als Service zur Verfügung. Die Entwicklungsteams können sich auf Businessfunktionalitäten konzentrieren, statt Infrastruktur neu zu erfinden.\nPlatform Engineering ist nicht das Bauen eines kleinen internen Tools. Es ist eine strategische Entscheidung, die üblicherweise auf Geschäftsleitungsebene getroffen wird, um ein internes Produkt zu schaffen, dessen Kunden die Entwicklungsteams sind.\nDer Business Case # Dennis brachte eine entscheidende Perspektive ein: den Business-Wert. Im Handel ist der Druck unerbittlich. Alles muss schneller, besser und günstiger sein. Die Margen sind eng. Die Spannung zwischen IT und Business ist real, und Platform Engineering kann helfen, sie zu lösen, indem Teams befähigt werden, schneller Wert zu liefern.\nWenn Teams enabled und empowered sind, beginnt sich der ständige Konflikt zwischen \u0026ldquo;das Business will mehr\u0026rdquo; und \u0026ldquo;die IT kann nicht schnell genug liefern\u0026rdquo; aufzulösen. Die Bedürfnisse aller Seiten werden effektiver adressiert.\nWar for Talent # Niemand will mit veralteten Technologien, veralteten Mindsets, veralteter Kultur oder veralteten Prozessen arbeiten. Wenn Talente heute in ein Unternehmen kommen, fragen sie, ob DevOps oder Platform Engineering praktiziert wird. Sie wollen nicht in einem Projekt arbeiten, wo alles nach dem Wasserfall läuft, wo es Siloorganisationen gibt, wo man Dinge über die \u0026ldquo;Wall of Confusion\u0026rdquo; wirft und Teams gegeneinander statt miteinander arbeiten. Das ist kein Umfeld, in dem jemand arbeiten will.\nPlatform Engineering schafft genau das moderne Arbeitsumfeld, das Talente anzieht und hält, sowohl auf der technischen als auch auf der Business-Seite.\nInnovation durch Experimentieren # Einer der stärksten Vorteile eines produktbasierten Ansatzes mit Platform Engineering ist die Fähigkeit zu experimentieren. Das Management kann sagen: \u0026ldquo;Lasst uns etwas Neues ausprobieren.\u0026rdquo; Man bringt eine neue Idee in einen bestehenden Wertstrom ein, definiert Leading Indicators, um die Hypothese zu testen, bringt sie an den Markt und schaut, ob sie Anklang findet. Falls nicht, hört man einfach auf. Der Wertstrom ist ja bereits da, es gibt keine verschwendete Infrastruktur.\nDiese Fähigkeit zum Experimentieren treibt Innovation und gibt sowohl technischen als auch Business-Teammitgliedern die Freiheit, kreative Ideen zum Leben zu bringen. Wie Dennis es formulierte: Wenn Menschen Dinge ausprobieren können, ist das erfüllend, weil sie ihre eigenen Ideen einbringen können.\nDer Mindset Shift: Whole System Thinking # Wenn Unternehmen mit ihren Herausforderungen zu uns kommen, sagen sie oft Dinge wie \u0026ldquo;macht unsere Pipeline schneller\u0026rdquo; oder \u0026ldquo;wir müssen die Entwicklung beschleunigen.\u0026rdquo; Das kann man tun, aber man muss das Gesamtbild betrachten. Wir nennen das Whole System Thinking. Ein Wertstrom geht von der Idee bis in die Produktion und deckt ein gesamtes Produkt ab. Wenn man nur an einem Rädchen dreht, kann das einen positiven Effekt auf diese eine Komponente haben, aber einen negativen auf eine andere.\nDeshalb starten wir immer mit einer Root-Cause-Analyse. Welches Problem wollen wir wirklich lösen? Und warum wollen wir es lösen? Der häufigste Treiber, den wir sehen: Die Teams können sich nicht mehr auf Businessfeatures konzentrieren, weil sie mit operativen Aufgaben überlastet sind. Genau dort wird Platform Engineering zur Lösung.\nPlatform Engineering ist eine Transformation # Eine wichtige Erkenntnis aus unserer Diskussion: Platform Engineering ist im Kern eine Transformation. Teams werden transformiert, weil bestimmte Verantwortlichkeiten zum Plattform-Team wandern. Eine Plattform wird aufgebaut, Services werden von verschiedenen Teams konsumiert, und die Arbeitsweise ändert sich fundamental.\nAber der entscheidende Punkt: Es ist kein Transformationsprojekt mit Start- und Enddatum. Es ist ein internes Produkt, ein interner Service. Es wird nie enden. Es entwickelt sich kontinuierlich weiter, wenn neue Technologien aufkommen, einschliesslich KI-Services, die das Plattform-Team bereitstellen kann, wie das Hosting von Large Language Models oder APIs, die andere Teams nutzen können.\nKernaussagen # Vom Projekt zum Produkt wechseln. Kontinuierlicher Wertfluss erfordert, Software als Produkt mit laufender Investition zu behandeln, nicht als Projekt mit festem Enddatum. Platform Engineering reduziert die kognitive Last. Durch Self-Service-Capabilities werden Entwicklungsteams entlastet und können sich auf Businessfeatures konzentrieren. Es ist ein strategisches Investment. Platform Engineering ist nichts, was man \u0026ldquo;einfach mal macht.\u0026rdquo; Es braucht Commitment auf Geschäftsleitungsebene und angemessene Finanzierung. Das Plattform-Team baut ein internes Produkt. Man kann es sich als Produktentwicklung für die eigenen Teams vorstellen, mit einem Product Owner, der ständig fragt: \u0026ldquo;Was brauchen meine internen Kunden?\u0026rdquo; Whole System Thinking ist essenziell. Nicht nur einen Teil optimieren, sondern den gesamten Wertstrom von der Idee bis zur Produktion betrachten. Experimentieren treibt Innovation. Ein produktbasierter Ansatz macht es einfach, neue Ideen mit geringem Risiko zu testen. Talentbindung zählt. Moderne Engineering-Praktiken schaffen das Umfeld, das Top-Talente erwarten. ","date":"7. December 2024","externalUrl":null,"permalink":"/de/blogs/platform-engineering-kontinuierlicher-wertfluss-im-handel/","section":"Blogs","summary":"Kontinuierlicher Wertfluss durch Platform Engineering. Was heisst das eigentlich? Im Zühlke Commerce Talk habe ich zusammen mit meinem Kollegen Dennis Kolmitz, Engagement Manager bei Zühlke und verantwortlich für unsere Commerce-Kunden, genau darüber gesprochen. Wir haben erkundet, warum Platform Engineering für Handelsunternehmen essenziell wird, die schneller innovieren, Reibungsverluste reduzieren und ihre besten Talente halten wollen.\n","title":"Platform Engineering: Wie kontinuierlicher Wertfluss den Handel transformiert","type":"blogs"},{"content":" Im August 2025 erscheint mein neues Buch, The Cybernetic Enterprise: How to Build a Future-Ready Organization.\nEs ist das Ergebnis von zwei Jahrzehnten, in denen ich Unternehmen durch DevOps, Platform Engineering und in jüngerer Zeit durch AI-getriebene Transformation begleitet habe. Heute möchte ich dir einen tieferen Blick darauf geben, was das Buch bietet und warum es genau jetzt wichtig ist.\nWarum noch ein Transformationsbuch? # Weil sich der Boden unter jeder Branche verschiebt. Legacy-Betriebsmodelle, optimiert für Vorhersagbarkeit und Kontrolle, brechen unter beschleunigtem Wandel, zunehmender Komplexität und unaufhörlicher Disruption. Das Ergebnis sind Silos, mehrfach belastete Teams und eine Governance, die Innovation erstickt – Probleme, die ich in den meisten Assessments sehe, die ich durchführe.\nEs braucht ein anderes Betriebssystem, eines, das Anpassung zur Norm und nicht zur Ausnahme macht. Dieses Betriebssystem ist das Cybernetic Enterprise.\nWas genau ist ein Cybernetic Enterprise? # «Eine kontinuierlich adaptive Organisation, die durch geschlossene Feedback-Schleifen, AI-augmentierte Intelligenz und autonome, cross-funktionale Teams arbeitet.»\nDas Modell ruht auf einer Triade der Intelligenz:\nOrganisation: beständige Produktteams, ermächtigte Führung, verteilte Entscheidungen. Technologie: eine Self-Service-interne Plattform, in der AI allgegenwärtig ist. Prozess: weg von Projekt-Meilensteinen, hin zu schnellen, feedbackreichen Produktschleifen. Einfach ausgedrückt bedeutet kybernetisch «durch Feedback gesteuert». Ein Cybernetic Enterprise versucht nicht, den Wandel einzufrieren; es lernt kontinuierlich daraus.\nAcht leitende Prinzipien # Bei Hunderten von Transformationen stelle ich fest, dass die erfolgreichen einen gemeinsamen Kompass teilen. Im Buch kodifiziere ich sie zu acht Prinzipien, deinem Nordstern für jede strategische und operative Entscheidung:\nOutcome over Output: Wert, nicht Volumen. Feedback Everywhere: jede Schicht für das Lernen instrumentieren. AI at the Edge: Menschen augmentieren, nicht ersetzen. Empowered Teams: Verantwortung liegt beim Team. Platform Enablement: reibungsloser Self-Service. Transparency by Default: Metriken im Sonnenlicht. Adaptation as Norm: Wandel ist Designinput. Resilience through Autonomy: Geschwindigkeit und Robustheit zusammen. Diese Prinzipien übersetzen sich in konkrete Praktiken wie Trunk-based Development, Lean Portfolio Management, AI-augmentierte Operations und Value-Stream Management, alle detailliert mit Praxisbeispielen.\nDie Cybernetic Platform: dein Transformationsbeschleuniger # Jedes Cybernetic Enterprise steht auf einer Cybernetic Platform, die Sicherheit, Compliance, Observability und AI-Unterstützung in vorgepflasterte Pfade für Teams einbackt. Provisionierung in Minuten, Policy-as-Code-Leitplanken und sofortige Telemetrie verwandeln Autonomie in Beschleunigung statt Chaos.\nIm Inneren des Buches # Das Material ist sorgfältig organisiert, sodass du dort einsteigen kannst, wo du am meisten Erkenntnis brauchst:\nAktuelle IT-Schmerzpunkte und der Case for Change: warum überlastete, fragmentierte IT nicht überleben kann. Body of Knowledge: Lean, Kanban, Systems Thinking, DevOps, AI und mehr, destilliert in Prinzipien, Praktiken, Vorteile und Herausforderungen. Das Cybernetic-Enterprise-Modell: Definition, mentales Modell, geschichtete Architektur und Triade der Intelligenz. Transformations-Taktiken: Team-Topologie, Produkt-Discovery, Coaching und Leadership-Hebel für kulturellen Wandel. Kulturpraktiken: Mitarbeiterzufriedenheit, lernende Organisation und Innovationskultur für nachhaltigen Wandel. Durchgängig webe ich Geschichten aus dem Feld ein und zeige, wie AI als Schreib-Coach fungierte, und veranschauliche so genau, wie die Mensch-AI-Zusammenarbeit in der Praxis aussieht.\nWer sollte es lesen? # C-Level- und Board-Mitglieder, die Strategie inmitten von Volatilität steuern müssen. Technologie- und Produktverantwortliche, die mit dem Aufbau von Plattformen und der Befähigung von Teams betraut sind. Enterprise-Architekten und Engineers, die die Schleife zwischen Design und Realität schliessen wollen. Change Agents: Agile-, DevOps- und AI-Champions, die kulturelle Evolution vorantreiben. Werde Teil der Bewegung # Die Zukunft gehört Unternehmen, die kybernetisch by Design sind, jenen, die AI, Feedback und ermächtigte Menschen nutzen, um schneller zu lernen, als sich der Markt verändert.\nWenn du möchtest, dass deine Organisation 2026 und darüber hinaus schneller, intelligenter und stärker ist, reserviere dein Exemplar noch heute und sei bereit, wenn The Cybernetic Enterprise diesen August erscheint.\n👉 Pre-Order auf Leanpub oder abonniere meinen Newsletter für frühe Bonuskapitel und Live-Q\u0026amp;A-Termine: https://leanpub.com/CyberneticEnterprise\nLass uns gemeinsam die zukunftsfähigen Organisationen aufbauen, die das nächste Jahrzehnt verlangt.\n","date":"30. November 2024","externalUrl":null,"permalink":"/de/blogs/das-cybernetic-enterprise-kommt-bist-du-bereit/","section":"Blogs","summary":" Im August 2025 erscheint mein neues Buch, The Cybernetic Enterprise: How to Build a Future-Ready Organization.\nEs ist das Ergebnis von zwei Jahrzehnten, in denen ich Unternehmen durch DevOps, Platform Engineering und in jüngerer Zeit durch AI-getriebene Transformation begleitet habe. Heute möchte ich dir einen tieferen Blick darauf geben, was das Buch bietet und warum es genau jetzt wichtig ist.\n","title":"Das Cybernetic Enterprise kommt: Bist du bereit?","type":"blogs"},{"content":" In August 2025 I will release my new book, The Cybernetic Enterprise: How to Build a Future-Ready Organization.\nIt is the product of two decades spent guiding enterprises through DevOps, platform engineering and, more recently, AI-driven transformation. Today I want to give you a deeper look at what the book delivers, and why it matters right now.\nWhy another transformation book? # Because the ground is shifting under every industry.Legacy operating models optimized for predictability and control are cracking under accelerating change, mounting complexity and relentless disruption. The result is siloed functions, multi-loaded teams and governance that stifles innovation, issues I see in most assessments I run.\nA different operating system is required, one that makes adaptation the default rather than the exception. That operating system is the Cybernetic Enterprise.\nWhat exactly is a Cybernetic Enterprise? # “A continuously adaptive organization that operates through closed feedback loops, AI-augmented intelligence and autonomous, cross-functional teams.”\nThe model rests on a triad of intelligence:\nOrganization: durable product teams, empowered leadership, distributed decisions. Technology: a self-service internal platform where AI is ambient. Process: from project milestones to fast, feedback-rich product loops. Put simply, cybernetic means “governed by feedback.” A Cybernetic Enterprise does not attempt to freeze change; it learns from it, continuously.\nEight guiding principles # Across hundreds of transformations I find the successful ones share a common compass. In the book I codify them into eight principles, your North Star for every strategic and operational decision:\nOutcome over Output: value, not volume. Feedback Everywhere: instrument every layer for learning. AI at the Edge: augment people, don’t replace them. Empowered Teams: ownership lives with the team. Platform Enablement: frictionless self-service. Transparency by Default: metrics in the sunlight. Adaptation as Norm: change is design input. Resilience through Autonomy: speed and robustness together. These principles translate into concrete practices such as trunk-based development, lean portfolio management, AI-augmented ops and value-stream management, all detailed with real-world examples.\nThe Cybernetic Platform: your transformation accelerator # Every Cybernetic Enterprise stands on a Cybernetic Platform that bakes security, compliance, observability and AI assistance into paved paths for teams. Provisioning in minutes, policy-as-code guardrails and instant telemetry turn autonomy into acceleration instead of chaos.\nInside the book # The material is meticulously organized so you can dip in where you need the most insight:\nCurrent IT pains \u0026amp; the case for change: why overloaded, fragmented IT cannot survive. Body of Knowledge: Lean, Kanban, Systems Thinking, DevOps, AI and more distilled into principles, practices, benefits and challenges. The Cybernetic Enterprise model: definition, mental model, layered architecture and triad of intelligence. Transformation tactics: team topology, product discovery, coaching and leadership levers for cultural shift. Culture practices: employee satisfaction, learning organization and innovation culture for sustainable change. Throughout, I weave stories from the field and show how AI acted as a writing coach, illustrating exactly how human-AI collaboration looks in practice.\nWho should read it? # C-level and Board members who must steer strategy amid volatility. Technology and Product leaders tasked with building platforms and empowering teams. Enterprise architects and engineers looking to close the loop between design and reality. Change agents: Agile, DevOps, and AI champions driving cultural evolution. Join the movement # The future belongs to enterprises that are cybernetic by design, those that harness AI, feedback and empowered people to learn faster than the market changes.\nIf you want your organization to be faster, smarter and stronger in 2026 and beyond, reserve your copy today and be ready when The Cybernetic Enterprise lands this August.\n👉 Pre-order on Leanpub or subscribe to my newsletter for early bonus chapters and live Q\u0026amp;A dates: https://leanpub.com/CyberneticEnterprise\nTogether, let’s build the future-ready organizations the next decade demands.\n","date":"30 November 2024","externalUrl":null,"permalink":"/en/blogs/the-cybernetic-enterprise-is-coming-are-you-ready/","section":"Blogs","summary":" In August 2025 I will release my new book, The Cybernetic Enterprise: How to Build a Future-Ready Organization.\nIt is the product of two decades spent guiding enterprises through DevOps, platform engineering and, more recently, AI-driven transformation. Today I want to give you a deeper look at what the book delivers, and why it matters right now.\n","title":"The Cybernetic Enterprise is Coming: Are You Ready?","type":"blogs"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/a/b-testing/","section":"Tags","summary":"","title":"A/B Testing","type":"tags"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/continuous-deployment/","section":"Tags","summary":"","title":"Continuous Deployment","type":"tags"},{"content":" In meinen zwei Jahrzehnten Erfahrung mit der Leitung von DevOps-, Digital- und Agile-Transformationen habe ich beobachtet, dass der Weg zur Modernisierung selten eine gerade Linie ist. Insbesondere Organisationen in datensensiblen Branchen wie Banken, Behörden und dem Gesundheitswesen stehen oft an einem Scheideweg. Sie müssen schneller innovieren und gleichzeitig strenge Sicherheits- und Zuverlässigkeitsanforderungen einhalten. Diese Spannung zwischen Geschwindigkeit und Sicherheit hat Unternehmen traditionell gezwungen, sich für eines von beidem zu entscheiden. Doch das muss nicht so sein.\n„Ohne Feature Flags fällt es Organisationen schwer, Deployment von Release zu trennen, was begrenzt, wie häufig sie Änderungen sicher ausrollen können.\u0026quot;\nFeature Flags entwickeln sich auf dieser Reise zu einem strategischen Enabler und verändern grundlegend, wie Organisationen Softwareentwicklung und -auslieferung angehen. Sie sind unverzichtbar, um in der modernen Software Delivery Spitzenleistung zu erreichen, insbesondere bei der Deployment Frequency, einer der vier zentralen DORA-Metriken zur Messung der Software-Delivery-Performance. Ohne Feature Flags fällt es Organisationen schwer, Deployment von Release zu trennen, was begrenzt, wie häufig sie Änderungen sicher ausrollen können. Mit Feature Flags können Teams kleinere Änderungen mehrmals täglich deployen und dabei präzise Kontrolle behalten. Dieser Ansatz reduziert das Risiko erheblich: Je kleiner die Änderungen in einem Deployment sind, desto geringer ist die Wahrscheinlichkeit von Problemen und desto einfacher ist es, Probleme zu identifizieren und zu beheben, wenn sie auftreten.\nIn der heutigen vernetzten Welt überschreiten Feature Flags die Grenzen einzelner Anwendungen. Moderne Unternehmen betreiben komplexe Anwendungslandschaften, in denen APIs verschiedene Services und Systeme verbinden. Diese vernetzte Natur erfordert einen ganzheitlichen Ansatz für das Feature Management. Mit dem Aufstieg des Platform Engineering ist Feature Flagging zu einer grundlegenden Plattformfähigkeit geworden. Lösungen wie Flagsmith bieten zentrale Steuerung über ganze Anwendungs-Ökosysteme hinweg, von Frontend-Anwendungen über Backend-Services bis zu deren APIs.\n„Traditionelle Ansätze der Softwareentwicklung mit ihren langen Release-Zyklen und Alles-oder-Nichts-Deployments werden zunehmend untragbar. Feature Flags bieten eine ausgereifte Lösung, die Innovation demokratisiert und gleichzeitig Kontrolle ermöglicht.\u0026quot;\nDer Erfolg von Feature Flags im Unternehmensmassstab erfordert durchdachte Praktiken. Teams müssen Flags als First-Class-Artefakte behandeln und ihren Lebenszyklus mit derselben Sorgfalt verwalten wie Anwendungscode. Dieser zentrale Ansatz adressiert wichtige Anliegen von Unternehmen: umfassende Audit Trails für Compliance, rollenbasierte Zugriffskontrolle für Sicherheit und standardisierte Implementierungsmuster, die operative Komplexität und Total Cost of Ownership reduzieren. Indem Feature Flags as a Service bereitgestellt werden, stellen Organisationen eine konsistente Implementierung, Governance und Best Practices über ihre gesamte Landschaft hinweg sicher und halten gleichzeitig strenge Sicherheits- und Compliance-Standards ein.\nDer Zeitpunkt dieses Buches ist bedeutsam. Wir leben in einer Ära, in der digitale Transformation nicht länger optional ist. Datensensible Unternehmen stehen unter wachsendem Druck, schneller Mehrwert zu liefern und gleichzeitig Risiken zu managen. Die Einführung von Feature Flags erfordert eine sorgfältige Betrachtung der organisatorischen Reife, einschliesslich der Schulung von Entwicklern und der Anpassung von Prozessen. Mit Bedacht umgesetzt, werden Feature Flags jedoch zu einem Eckpfeiler der digitalen Transformation. Das ist besonders entscheidend für KI-gestützte Anwendungen, wo Feature Flags es Organisationen ermöglichen, KI-Funktionen schrittweise einzuführen, A/B-Tests mit verschiedenen KI-Modellen durchzuführen und problematisches KI-Verhalten schnell zu deaktivieren, alles unter Beibehaltung von Audit Trails und regulatorischer Compliance.\n„Der Weg zur modernen Softwareentwicklung ist komplex, muss aber nicht überwältigend sein. Feature Flags sind ein konkreter, umsetzbarer Schritt nach vorn, der unmittelbaren Mehrwert liefert und gleichzeitig den Weg für eine umfassendere Transformation ebnet.\u0026quot;\nTraditionelle Ansätze der Softwareentwicklung mit ihren langen Release-Zyklen und Alles-oder-Nichts-Deployments werden zunehmend untragbar. Feature Flags bieten eine ausgereifte Lösung, die Innovation demokratisiert und gleichzeitig Kontrolle ermöglicht. Mit klaren Governance-Modellen sorgfältig umgesetzt, ermöglichen sie Teams, mit grösserer Autonomie und Zuversicht zu arbeiten, und verwandeln risikoreiche Releases in kontrollierte, beobachtbare Prozesse. Das ist insbesondere für datensensible Unternehmen entscheidend, wo die Kosten eines Fehlers ausserordentlich hoch sein können und die regulatorischen Anforderungen streng sind.\nIch habe immer wieder erlebt, dass Feature Flags in Modernisierungsdiskussionen ein zentrales Thema sind. Sie sind ein praktischer erster Schritt zu anspruchsvolleren Entwicklungspraktiken, indem sie ein Sicherheitsnetz für selbstbewusstes Experimentieren, wirksame Risikosteuerung und die Flexibilität bieten, schnell auf Marktanforderungen zu reagieren, und das alles bei Einhaltung der Sicherheits- und Compliance-Standards, die Unternehmen benötigen.\nDieses Buch baut auf dem Banking-Modernisierungs-Playbook auf und bietet eine detaillierte Roadmap für Organisationen, die bereit sind, moderne Entwicklungspraktiken zu übernehmen. Der Weg zur modernen Softwareentwicklung ist komplex, muss aber nicht überwältigend sein. Feature Flags sind ein konkreter, umsetzbarer Schritt nach vorn, der unmittelbaren Mehrwert liefert und gleichzeitig den Weg für eine umfassendere Transformation ebnet. Die Investition in eine Feature-Flag-Infrastruktur amortisiert sich in der Regel durch reduzierte Deployment-Risiken, schnellere Time-to-Market und kürzere Reaktionszeiten bei Vorfällen.\nLassen Sie uns diese Reise gemeinsam antreten und erkunden, wie Feature Flags Ihrer Organisation helfen können, die Lücke zwischen dem Heute und dem, wonach Sie morgen streben, zu überbrücken.\nVollständiges eBook herunterladen: https://www.flagsmith.com/ebook/flip-the-switch-on-modern-software-development-with-feature-flags\n","date":"27. November 2024","externalUrl":null,"permalink":"/de/blogs/einfuehrung-flip-the-switch-moderne-softwareentwicklung-mit-feature-flags/","section":"Blogs","summary":" In meinen zwei Jahrzehnten Erfahrung mit der Leitung von DevOps-, Digital- und Agile-Transformationen habe ich beobachtet, dass der Weg zur Modernisierung selten eine gerade Linie ist. Insbesondere Organisationen in datensensiblen Branchen wie Banken, Behörden und dem Gesundheitswesen stehen oft an einem Scheideweg. Sie müssen schneller innovieren und gleichzeitig strenge Sicherheits- und Zuverlässigkeitsanforderungen einhalten. Diese Spannung zwischen Geschwindigkeit und Sicherheit hat Unternehmen traditionell gezwungen, sich für eines von beidem zu entscheiden. Doch das muss nicht so sein.\n","title":"Einführung: Flip the Switch on Modern Software Development with Feature Flags","type":"blogs"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/experimentation/","section":"Tags","summary":"","title":"Experimentation","type":"tags"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/feature-flags/","section":"Tags","summary":"","title":"Feature Flags","type":"tags"},{"content":" In my two decades of experience leading DevOps, Digital, and Agile transformations, I’ve observed that the path to modernisation is rarely a straight line. Organisations, particularly those in data-sensitive sectors, like banking, government, and healthcare, often find themselves at a crossroads. They need to innovate faster while maintaining rigorous security and reliability. This tension between speed and safety has traditionally forced companies to choose one over the other. But it doesn’t have to be this way.\n“Without feature flags, organisations struggle to separate deployment from release, limiting how frequently they can safely deploy changes.”\nFeature flags emerge as a strategic enabler in this journey, fundamentally transforming how organisations approach software development and delivery. They are essential for achieving high performance in modern software delivery, particularly in deployment frequency, one of the four key DORA metrics that indicate Software Delivery Performance. Without feature flags, organisations struggle to separate deployment from release, limiting how frequently they can safely deploy changes. With feature flags, teams can deploy smaller changes multiple times per day while maintaining precise control. This approach significantly reduces risk: the smaller the changes in a deployment, the lower the likelihood of issues and the easier it is to identify and resolve problems when they occur.\nIn today’s interconnected world, feature flags transcend individual application boundaries. Modern enterprises operate complex application landscapes where APIs connect various services and systems. This interconnected nature demands a holistic approach to feature management. The rise of Platform Engineering has made feature flags a fundamental platform capability. Solutions like Flagsmith provide centralised control across entire application ecosystems, from frontend applications to backend services and their APIs.\n“Traditional approaches to software development, with their long release cycles and all-or-nothing deployments, are becoming increasingly unfeasible. Feature flags offer a sophisticated solution that democratises innovation while maintaining control.”\nThe success of feature flags at enterprise scale requires thoughtful practices. Teams must treat flags as first-class artefacts, managing their lifecycle with the same rigour as application code. This centralised approach addresses key enterprise concerns: comprehensive audit trails for compliance, rolebased access control for security, and standardised implementation patterns that reduce operational complexity and total cost of ownership. By providing feature flags as a service, organisations ensure consistent implementation, governance, and best practices across their landscape while maintaining strict security and compliance standards.\nThe timing of this book is significant. We’re in an era where digital transformation is no longer optional. Data-sensitive enterprises face mounting pressure to deliver value faster while managing risk. The implementation of feature flags requires careful consideration of organisational readiness, including developer training and process adaptation. However, when executed thoughtfully, feature flags become a cornerstone of digital transformation. This is particularly crucial for AI-enabled applications, where feature flags enable organisations to gradually introduce AI features, conduct A/B tests with different AI models, and quickly disable problematic AI behaviours, all while maintaining audit trails and regulatory compliance.\n“The journey to modern software development is complex but it doesn’t have to be overwhelming. Feature flags represent a concrete, actionable step forward that delivers immediate value while paving the way for broader transformation.”\nTraditional approaches to software development, with their long release cycles and all-or-nothing deployments, are becoming increasingly unfeasible. Feature flags offer a sophisticated solution that democratises innovation while maintaining control. When implemented thoughtfully with clear governance models, they enable teams to work with greater autonomy and confidence, transforming high-stakes releases into controlled, observable processes. This is particularly crucial for data-sensitive enterprises, where the cost of failure can be extraordinary and regulatory requirements are stringent.\nI’ve seen feature flags consistently emerge as a critical topic in modernisation discussions. They represent a practical first step towards more sophisticated development practices by providing a safety net for confident experimentation, effective risk management control, and the flexibility to respond rapidly to market demands, all while maintaining the security and compliance standards that enterprises require.\nThis book builds upon the banking modernisation playbook, offering a detailed roadmap for organisations ready to embrace modern development practices. The journey to modern software development is complex but it doesn’t have to be overwhelming. Feature flags represent a concrete, actionable step forward that delivers immediate value while paving the way for broader transformation. The investment in feature flag infrastructure typically pays for itself through reduced deployment risks, faster time to market, and decreased incident response times.\nLet’s embark on this journey together, exploring how feature flags can help your organisation bridge the gap between where you are today and where you aspire to be tomorrow.\nDownload the full eBook: https://www.flagsmith.com/ebook/flip-the-switch-on-modern-software-development-with-feature-flags\n","date":"27 November 2024","externalUrl":null,"permalink":"/en/blogs/introduction-to-flip-the-switch-on-modern-software-development-with-feature-flags/","section":"Blogs","summary":" In my two decades of experience leading DevOps, Digital, and Agile transformations, I’ve observed that the path to modernisation is rarely a straight line. Organisations, particularly those in data-sensitive sectors, like banking, government, and healthcare, often find themselves at a crossroads. They need to innovate faster while maintaining rigorous security and reliability. This tension between speed and safety has traditionally forced companies to choose one over the other. But it doesn’t have to be this way.\n","title":"Introduction to Flip the Switch on Modern Software Development with Feature Flags","type":"blogs"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/modern-development/","section":"Tags","summary":"","title":"Modern Development","type":"tags"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/product-management/","section":"Tags","summary":"","title":"Product Management","type":"tags"},{"content":"","date":"27 November 2024","externalUrl":null,"permalink":"/en/tags/risk-management/","section":"Tags","summary":"","title":"Risk Management","type":"tags"},{"content":"I recently joined Ben on the We Chat Tech podcast for a wide-ranging conversation about DevOps, leadership, career growth, and the future of AI in software engineering. Over 23 years at Zühlke, I have worked across industries helping organizations transform how they deliver software. In this episode, we covered everything from the fundamentals of DevOps to the skills that future engineers will need.\nWhat DevOps Really Means # For me, DevOps is about bringing all the people, all the processes, and all the technology together to continuously deliver value. It is not just about connecting development and operations. It is about the entire value stream, from the first idea all the way to the customer, and back again through monitoring and feedback.\nEvery company is at a different point in their DevOps journey. Some organizations have mature value stream teams and their own platforms. Others are still using file systems for version control. As a consultant, my job is to meet each organization where they are and help them move forward.\nValue Stream Mapping: The Foundation # When I enter a new engagement, the first thing I do is a value stream mapping exercise. You bring all the people working on a product into a room, give them Post-its, and ask them to lay out every step from idea to production. Then you measure three things for each step:\nLead Time: The total time from start to finish of that step Process Time: The actual value-adding work time Percentage Complete and Accurate: How often the output is good enough to move forward without rework The results are always eye-opening. Typically, one third of the total time is spent at the beginning, before a developer even receives a task. Managers are surprised by how much hidden waiting exists. Developers discover what happens before they get their Jira ticket. Operations learns about the full journey before something reaches them.\nWhen you bring all these people together and suddenly they see the whole value stream, very interesting things happen. It is an eye-opener. They start to think in the whole system instead of their silo.\nThis whole-system thinking is the foundation for real cultural change. Only when people understand the entire value stream can they begin to act as one team with collaborative ownership.\nLeadership and Growing People # At Zühlke, education is a central part of our culture. Our people spend roughly 10 to 20 days per year on education and professional development. I have been mentored and coached throughout my career, and everything I am today is thanks to that mentoring, that coaching, and the education I received.\nWhat makes a great leader in our industry? It comes down to communication, empathy, and the ability to see both strengths and weaknesses in people. Leadership is not management. It is about understanding what each person needs, whether that is coaching, mentoring, or something else entirely, and providing the right support so they can grow.\nWhen it comes to problem-solving with my team, I encourage them to come up with their own ideas. We use the architectural trade-off technique: identify the problem, define a solution space with multiple options, establish evaluation criteria, and then evaluate together. This collaborative approach produces better outcomes and develops the team at the same time.\nRetaining Talent # Hiring the right people is essential. At Zühlke, we use a three-step interview process: first, cultural fit; second, understanding who we are and what we offer; third, a three-hour technical deep dive to determine fit and level. But hiring is only half the equation.\nRetaining talent requires giving people awesome projects, showing them a career path, coaching them through their growth, and letting them see that they are getting better every day. When people feel that kind of progress, they stay.\nAI in Software Engineering: A Tool, Not a Replacement # AI will play a significant role in the future of technology, but we need to be realistic about where it helps today. For coding, AI assists with boilerplate and routine tasks. But when you need to create something genuinely new, develop a new algorithm, or solve a novel problem, it does not help yet.\nThere is a real danger that AI makes people stop thinking. Critical thinking and problem solving will become the most important skills for future engineers. The comparison to history is useful: when we introduced object-oriented programming, there was a risk of laziness around memory management. We had issues until standards emerged. The same will happen with AI. People will get lazy at first, problems will surface, and then we will develop expertise and standards for using AI well.\nAI is just the next level. When Java came along, people said we would need fewer developers. That was not true. AI will follow the same pattern: we will use it to create more awesome stuff that is more complex.\nFor practical AI applications in DevOps, the results are already impressive. We built a platform for a bank in Liechtenstein where we integrated a large language model for log file analysis. Developers click a button, the model analyzes the logs, and they can act on the findings. The feedback from developers: \u0026ldquo;This is absolutely awesome. It helps us massively in finding and analyzing problems.\u0026rdquo;\nAdvice for Young Engineers # My biggest piece of advice: never stop learning. Stay up to date with technology, and do not focus too narrowly on one language or stack for too long. Today, tools like GitHub Copilot make it easier than ever to switch between languages. Becoming a polyglot programmer is more achievable and more valuable than it has ever been.\nI focused heavily on C# for many years. Looking back, it would have been more beneficial to switch between languages earlier. The industry now expects engineers to be comfortable with multiple languages, and platform teams especially need people with broad technical skills.\nKey Takeaways # DevOps is about the entire value stream, not just development and operations. Start with value stream mapping to understand where you are. Whole-system thinking is the foundation for cultural change. When people see the full picture, they stop thinking in silos. Great leadership is about empathy and growth. See what each person needs and provide the right support. Retain talent through meaningful work, education, and visible career progression. AI is a powerful tool, not a replacement. It helps with routine tasks but cannot substitute for critical thinking and problem solving. Never stop learning. The best investment you can make is in your own continuous education and breadth of skills. ","date":"29 October 2024","externalUrl":null,"permalink":"/en/blogs/building-high-impact-devops/","section":"Blogs","summary":"I recently joined Ben on the We Chat Tech podcast for a wide-ranging conversation about DevOps, leadership, career growth, and the future of AI in software engineering. Over 23 years at Zühlke, I have worked across industries helping organizations transform how they deliver software. In this episode, we covered everything from the fundamentals of DevOps to the skills that future engineers will need.\n","title":"Building High-Impact DevOps: Expert Insights","type":"blogs"},{"content":"","date":"29 October 2024","externalUrl":null,"permalink":"/en/tags/career/","section":"Tags","summary":"","title":"Career","type":"tags"},{"content":"Im We Chat Tech Podcast sprach ich mit Ben über DevOps, Führung, Karriereentwicklung und die Zukunft von KI in der Softwareentwicklung. Über 23 Jahre bei Zühlke habe ich in verschiedensten Branchen Organisationen bei der Transformation ihrer Software-Delivery begleitet. In dieser Episode haben wir alles abgedeckt: von den Grundlagen von DevOps bis hin zu den Fähigkeiten, die zukünftige Ingenieure brauchen.\nWas DevOps wirklich bedeutet # Für mich bedeutet DevOps, alle Menschen, alle Prozesse und alle Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. Es geht nicht nur darum, Entwicklung und Betrieb zu verbinden. Es geht um den gesamten Value Stream, von der ersten Idee bis zum Kunden und zurück über Monitoring und Feedback.\nJedes Unternehmen befindet sich an einem anderen Punkt seiner DevOps-Reise. Einige Organisationen haben reife Value-Stream-Teams und eigene Plattformen. Andere nutzen noch Dateisysteme für die Versionskontrolle. Als Berater ist es meine Aufgabe, jede Organisation dort abzuholen, wo sie steht, und ihr zu helfen, voranzukommen.\nValue Stream Mapping: Das Fundament # Wenn ich ein neues Engagement beginne, mache ich als erstes ein Value Stream Mapping. Man bringt alle Personen, die an einem Produkt arbeiten, in einen Raum, gibt ihnen Post-its und bittet sie, jeden Schritt von der Idee bis zur Produktion aufzulisten. Dann misst man drei Dinge für jeden Schritt:\nLead Time: Die Gesamtzeit vom Anfang bis zum Ende dieses Schritts Process Time: Die tatsächliche wertschöpfende Arbeitszeit Percentage Complete and Accurate: Wie oft der Output gut genug ist, um ohne Nacharbeit weiterzugehen Die Ergebnisse sind immer ein Augenöffner. Typischerweise wird ein Drittel der Gesamtzeit am Anfang verbracht, bevor ein Entwickler überhaupt eine Aufgabe erhält. Manager sind überrascht, wie viel versteckte Wartezeit existiert. Entwickler erfahren, was passiert, bevor sie ihr Jira-Ticket bekommen. Der Betrieb lernt die gesamte Reise kennen, bevor etwas bei ihnen ankommt.\nWenn man all diese Menschen zusammenbringt und sie plötzlich den ganzen Value Stream sehen, passieren sehr interessante Dinge. Es ist ein Augenöffner. Sie beginnen im Gesamtsystem zu denken, statt in ihrem Silo.\nDieses Gesamtsystem-Denken ist das Fundament für echten kulturellen Wandel. Erst wenn Menschen den gesamten Value Stream verstehen, können sie beginnen, als ein Team mit geteilter Verantwortung zu agieren.\nFührung und Mitarbeiterentwicklung # Bei Zühlke ist Weiterbildung ein zentraler Bestandteil unserer Kultur. Unsere Mitarbeitenden verbringen etwa 10 bis 20 Tage pro Jahr mit Weiterbildung und professioneller Entwicklung. Ich wurde während meiner gesamten Karriere gementoret und gecoacht, und alles, was ich heute bin, verdanke ich diesem Mentoring, diesem Coaching und der Ausbildung, die ich erhalten habe.\nWas macht eine grossartige Führungspersönlichkeit in unserer Branche aus? Es kommt auf Kommunikation, Empathie und die Fähigkeit an, sowohl Stärken als auch Schwächen bei Menschen zu erkennen. Führung ist nicht Management. Es geht darum zu verstehen, was jede Person braucht, ob Coaching, Mentoring oder etwas ganz anderes, und die richtige Unterstützung zu geben, damit sie wachsen kann.\nWenn es um Problemlösung mit meinem Team geht, ermutige ich sie, eigene Ideen einzubringen. Wir nutzen die architektonische Trade-off-Technik: das Problem identifizieren, einen Lösungsraum mit mehreren Optionen definieren, Bewertungskriterien festlegen und dann gemeinsam evaluieren. Dieser kollaborative Ansatz produziert bessere Ergebnisse und entwickelt gleichzeitig das Team.\nTalente halten # Die richtigen Leute einzustellen ist essenziell. Bei Zühlke nutzen wir einen dreistufigen Interviewprozess: erstens Cultural Fit, zweitens Verständnis darüber, wer wir sind und was wir bieten, drittens ein dreistündiger technischer Deep Dive. Aber die Einstellung ist nur die halbe Gleichung.\nTalente zu halten erfordert grossartige Projekte, einen sichtbaren Karrierepfad, Coaching durch die Entwicklung und das Gefühl, jeden Tag besser zu werden. Wenn Menschen diesen Fortschritt spüren, bleiben sie.\nKI in der Softwareentwicklung: Ein Werkzeug, kein Ersatz # KI wird eine bedeutende Rolle in der Zukunft der Technologie spielen, aber wir müssen realistisch sein, wo sie heute hilft. Beim Programmieren unterstützt KI bei Boilerplate und Routineaufgaben. Aber wenn man etwas wirklich Neues schaffen, einen neuen Algorithmus entwickeln oder ein neuartiges Problem lösen muss, hilft sie noch nicht.\nEs gibt eine reale Gefahr, dass KI Menschen dazu bringt, aufzuhören zu denken. Kritisches Denken und Problemlösung werden die wichtigsten Fähigkeiten für zukünftige Ingenieure sein. Der Vergleich mit der Geschichte ist hilfreich: Als wir objektorientierte Programmierung einführten, gab es das Risiko der Faulheit beim Speichermanagement. Wir hatten erhebliche Probleme, bis Standards entstanden. Dasselbe wird mit KI passieren. Menschen werden zunächst faul, Probleme werden auftauchen, und dann werden wir Expertise und Standards für den guten Einsatz von KI entwickeln.\nKI ist einfach die nächste Stufe. Als Java kam, hiess es, wir bräuchten weniger Entwickler. Das stimmte nicht. KI wird dem gleichen Muster folgen: Wir werden damit komplexere und bessere Dinge erschaffen.\nFür praktische KI-Anwendungen in DevOps sind die Ergebnisse bereits beeindruckend. Wir haben eine Plattform für eine Bank in Liechtenstein gebaut, in die wir ein Large Language Model für die Log-Analyse integriert haben. Entwickler klicken auf einen Button, das Modell analysiert die Logs, und sie können auf die Erkenntnisse reagieren. Das Feedback der Entwickler: \u0026ldquo;Das ist absolut grossartig. Es hilft uns enorm beim Finden und Analysieren von Problemen.\u0026rdquo;\nRat für junge Ingenieure # Mein wichtigster Rat: Hört nie auf zu lernen. Bleibt auf dem neuesten Stand der Technologie und fokussiert euch nicht zu lange zu eng auf eine Sprache oder einen Stack. Heute machen Tools wie GitHub Copilot den Wechsel zwischen Sprachen einfacher als je zuvor. Ein polyglotter Programmierer zu werden, ist erreichbarer und wertvoller als je zuvor.\nIch habe mich viele Jahre stark auf C# fokussiert. Rückblickend wäre es vorteilhafter gewesen, früher zwischen Sprachen zu wechseln. Die Branche erwartet heute, dass Ingenieure mit mehreren Sprachen vertraut sind, und besonders Platform-Teams brauchen Menschen mit breiten technischen Fähigkeiten.\nKernaussagen # DevOps umfasst den gesamten Value Stream, nicht nur Entwicklung und Betrieb. Mit Value Stream Mapping beginnen, um zu verstehen, wo man steht. Gesamtsystem-Denken ist das Fundament für kulturellen Wandel. Wenn Menschen das grosse Bild sehen, hören sie auf, in Silos zu denken. Gute Führung bedeutet Empathie und Wachstum. Erkennen, was jede Person braucht, und die richtige Unterstützung bieten. Talente halten durch sinnvolle Arbeit, Weiterbildung und sichtbare Karriereentwicklung. KI ist ein mächtiges Werkzeug, kein Ersatz. Sie hilft bei Routineaufgaben, kann aber kritisches Denken und Problemlösung nicht ersetzen. Nie aufhören zu lernen. Die beste Investition ist in die eigene kontinuierliche Weiterbildung und die Breite der Fähigkeiten. ","date":"29. October 2024","externalUrl":null,"permalink":"/de/blogs/devops-mit-wirkung-aufbauen/","section":"Blogs","summary":"Im We Chat Tech Podcast sprach ich mit Ben über DevOps, Führung, Karriereentwicklung und die Zukunft von KI in der Softwareentwicklung. Über 23 Jahre bei Zühlke habe ich in verschiedensten Branchen Organisationen bei der Transformation ihrer Software-Delivery begleitet. In dieser Episode haben wir alles abgedeckt: von den Grundlagen von DevOps bis hin zu den Fähigkeiten, die zukünftige Ingenieure brauchen.\n","title":"DevOps mit Wirkung aufbauen: Erkenntnisse aus der Praxis","type":"blogs"},{"content":"","date":"29 October 2024","externalUrl":null,"permalink":"/en/tags/interview/","section":"Tags","summary":"","title":"Interview","type":"tags"},{"content":"","date":"29. October 2024","externalUrl":null,"permalink":"/de/tags/karriere/","section":"Tags","summary":"","title":"Karriere","type":"tags"},{"content":"","date":"24 October 2024","externalUrl":null,"permalink":"/en/tags/conference/","section":"Tags","summary":"","title":"Conference","type":"tags"},{"content":"","date":"24 October 2024","externalUrl":null,"permalink":"/en/tags/devopsdays/","section":"Tags","summary":"","title":"DevOpsDays","type":"tags"},{"content":"On October 4, 2024, the global DevOpsDays Organizer Summit took place in Antwerp, bringing together organizers from DevOpsDays events around the world. Our team from DevOpsDays Zürich delivered a presentation titled \u0026ldquo;Bigger is Not Always Better.\u0026rdquo; I was not able to attend in person due to another conference, but my co-organizers Nadine and Dirk absolutely rocked the stage. Here is the story of why we decided not to scale our sold-out conference.\nThe History of DevOpsDays Zürich # DevOpsDays Zürich started in 2017, triggered by folks from the DevOps Meetup group who said \u0026ldquo;Let\u0026rsquo;s do a DevOpsDays in Switzerland.\u0026rdquo; They found that venues in downtown Zürich were expensive, so the first event took place at the Alte Kaserne in Winterthur, about 20 minutes by train from Zürich. The venue was perfect: the right price, breakout rooms for Open Spaces, and capacity for about 250 people.\nWith 12 organizers and 4 supporters, the first edition attracted around 200 attendees. By 2018, it was sold out at 250 people, and the team decided it was time to scale.\nThe Scaling Experiment of 2019 # In 2019, the event moved to the Arena in Spreitenbach, a much larger venue booked for 600 people. Over 500 attendees showed up. But the numbers tell the real story: the core team grew to 16 organizers, and onsite supporters jumped from 4 to 19. Finding those supporters meant asking friends and family, people who had nothing to do with organizing conferences or even DevOps, but who were needed to guide attendees, manage registration, and keep things running.\nIt was clear for all the organizers: this was stress. Not only does a new venue mean re-evaluating Wi-Fi, catering, and logistics, the sheer size requires finding and instructing many more people.\nThe COVID Pivot and Return # Then COVID struck. In 2020, the team organized five online sessions across the Tuesday evenings of September. Despite many registrations, attendance was disappointing. More importantly, the online format completely missed what makes DevOpsDays special: the spirit of connecting people, the Open Spaces, and the sense of community.\nThe team paused until late 2021, when Switzerland\u0026rsquo;s situation allowed a cautious return. They went back to the Alte Kaserne, required vaccination and testing, and sold out immediately. The feedback was overwhelming: people had missed the in-person community connection.\nA Trend of Selling Out Faster # The pattern since the return has been striking:\n2022: Sold out, two weeks before the event 2023: Sold out, seven weeks in advance 2024: Sold out, nine weeks in advance, with a waiting list of over 100 people Every year, the discussion within the organizer team comes up again: \u0026ldquo;We should scale. The universe expands, why don\u0026rsquo;t we?\u0026rdquo;\nWhy We Chose Not to Scale # Instead of going with a gut feeling, we did what DevOps people do: we applied a rigorous tradeoff analysis using the architectural tradeoff method. Two organizers spent an evening with two pizzas evaluating all options:\nStay at current size Choose a new, larger location Go back to the bigger venue Add live streaming Go hybrid Change the food concept Host the conference twice per year Scale out to multiple Swiss cities Each option was scored against weighted criteria. The result confirmed the gut feeling: don\u0026rsquo;t scale.\nThe Alte Kaserne offers critical advantages that are hard to replicate elsewhere:\nAffordable pricing as a city-owned venue Multiple rooms on three floors, ideal for Open Spaces and workshops Trusted partnership with the venue team who even cook the food and take care of the organizers Infrastructure investments like Wi-Fi repeaters and video connectors that stay in place year after year Community Comes First # The heart of the decision is the DevOpsDays Zürich vision:\n\u0026ldquo;DevOps community around 200 kilometers around Zürich who wants to learn, network, and share. The DevOpsDays is a two-day onsite, single-track conference that has top topics, networking opportunities, like-minded people, and is inspiring, motivating, intense, and holistic. Unlike commercial conferences, our conference has heart and soul.\u0026rdquo;\nThe ticket price has remained stable since the beginning: CHF 250 for a two-day conference including lunch, an evening event with food and drinks, workshops, and top international speakers. When the conference has money to spare, it goes to organizations that support refugees entering the IT industry or that bring underrepresented groups, especially girls, into contact with technology.\nAs Dirk put it:\n\u0026ldquo;We are not doing this for the money. This is what we do on our day jobs. This is what we do because it\u0026rsquo;s fun, for the kicks. It\u0026rsquo;s such an awesome conference and we have such an amazing team.\u0026rdquo;\nThe Stable Core Team # The organizer team has been stable for at least three years. Each core member has a clear responsibility, and there is a buddy concept where every new joiner has someone to guide them. Responsibilities can shift, giving people the chance to learn new roles while having support.\nPlanning starts right after the summer break. By the time the current conference ends, the date for the next edition is already confirmed and announced. This gives the team stability and a clear planning horizon.\nMitigating Without Scaling # The team is not ignoring the demand. Instead, they are exploring targeted mitigations:\nDay tickets so people who can only attend one day free up capacity Better early-bird timing to give everyone a fair chance Adjusted overbooking strategies to account for no-shows Key Takeaways # Bigger is not always better. A community conference can create more value by staying intimate and focused than by chasing scale. Use data, not gut feelings. The tradeoff analysis confirmed the intuitive decision, giving the team confidence and a shared understanding. Community over commercialization. Keeping ticket prices affordable and donating surplus to good causes builds trust and loyalty. Invest in your venue relationship. Long-term partnerships with a trusted venue reduce risk and improve quality year after year. Stability in the core team enables institutional knowledge and smooth operations, even as new members join. The DevOpsDays Zürich is proof that you can be sold out nine weeks in advance and still choose quality over quantity. ","date":"24 October 2024","externalUrl":null,"permalink":"/en/blogs/devopsdays-zurich-bigger-is-not-always-better/","section":"Blogs","summary":"On October 4, 2024, the global DevOpsDays Organizer Summit took place in Antwerp, bringing together organizers from DevOpsDays events around the world. Our team from DevOpsDays Zürich delivered a presentation titled “Bigger is Not Always Better.” I was not able to attend in person due to another conference, but my co-organizers Nadine and Dirk absolutely rocked the stage. Here is the story of why we decided not to scale our sold-out conference.\n","title":"DevOpsDays Zürich: Bigger is Not Always Better","type":"blogs"},{"content":"Am 4. Oktober 2024 fand in Antwerpen der globale DevOpsDays Organizer Summit statt, bei dem Organisatoren von DevOpsDays-Veranstaltungen aus der ganzen Welt zusammenkamen. Unser Team von den DevOpsDays Zürich hielt eine Präsentation mit dem Titel «Bigger is Not Always Better». Ich konnte leider nicht persönlich dabei sein wegen einer anderen Konferenz, aber meine Mitorganisatoren Nadine und Dirk haben die Bühne grossartig gemeistert. Hier ist die Geschichte, warum wir uns bewusst dagegen entschieden haben, unsere ausverkaufte Konferenz zu skalieren.\nDie Geschichte der DevOpsDays Zürich # Die DevOpsDays Zürich begannen 2017, angestossen von Leuten aus der DevOps-Meetup-Gruppe, die sagten: «Lasst uns auch DevOpsDays in der Schweiz machen.» Sie stellten fest, dass Veranstaltungsorte in der Zürcher Innenstadt teuer waren, weshalb die erste Ausgabe in der Alten Kaserne in Winterthur stattfand, etwa 20 Minuten mit dem Zug von Zürich entfernt. Der Veranstaltungsort war perfekt: der richtige Preis, Nebenräume für Open Spaces und Platz für rund 250 Personen.\nMit 12 Organisatoren und 4 Helfern zog die erste Ausgabe rund 200 Teilnehmende an. 2018 war die Konferenz mit 250 Personen ausverkauft, und das Team entschied, dass es Zeit war zu skalieren.\nDas Skalierungsexperiment von 2019 # 2019 zog die Veranstaltung in die Arena in Spreitenbach um, einen viel grösseren Veranstaltungsort, der für 600 Personen gebucht war. Über 500 Teilnehmende kamen. Aber die Zahlen erzählen die eigentliche Geschichte: Das Kernteam wuchs auf 16 Organisatoren, und die Helfer vor Ort stiegen von 4 auf 19. Diese Helfer zu finden bedeutete, Freunde und Familie zu fragen. Personen, die weder mit Konferenzorganisation noch mit DevOps etwas zu tun hatten, aber gebraucht wurden, um Teilnehmende zu leiten, die Registrierung zu managen und den Betrieb aufrechtzuerhalten.\nEs war allen Organisatoren klar: Das war Stress. Ein neuer Veranstaltungsort bedeutet nicht nur, WLAN, Catering und Logistik neu zu evaluieren. Die schiere Grösse erfordert, viel mehr Personen zu finden und einzuweisen.\nDer COVID-Schwenk und die Rückkehr # Dann kam COVID. 2020 organisierte das Team fünf Online-Sessions an den Dienstagabenden im September. Trotz vieler Anmeldungen war die Teilnahme enttäuschend. Noch wichtiger: Das Online-Format verfehlte komplett, was die DevOpsDays besonders macht: den Geist der Vernetzung, die Open Spaces und das Gemeinschaftsgefühl.\nDas Team pausierte bis Ende 2021, als die Situation in der Schweiz eine vorsichtige Rückkehr ermöglichte. Man ging zurück in die Alte Kaserne, forderte Impfung und Tests und war sofort ausverkauft. Das Feedback war überwältigend: Die Leute hatten den persönlichen Community-Kontakt vermisst.\nEin Trend: Immer schneller ausverkauft # Das Muster seit der Rückkehr ist bemerkenswert:\n2022: Ausverkauft, zwei Wochen vor der Veranstaltung 2023: Ausverkauft, sieben Wochen im Voraus 2024: Ausverkauft, neun Wochen im Voraus, mit einer Warteliste von über 100 Personen Jedes Jahr kommt die Diskussion im Organisationsteam wieder auf: «Wir sollten skalieren. Das Universum expandiert, warum wir nicht?»\nWarum wir uns gegen Skalierung entschieden haben # Anstatt nach Bauchgefühl zu gehen, haben wir das getan, was DevOps-Leute tun: eine rigorose Tradeoff-Analyse mit der architekturellen Tradeoff-Methode durchgeführt. Zwei Organisatoren verbrachten einen Abend mit zwei Pizzas und bewerteten alle Optionen:\nBei der aktuellen Grösse bleiben Einen neuen, grösseren Veranstaltungsort wählen Zurück zum grösseren Veranstaltungsort gehen Livestreaming hinzufügen Hybrid werden Das Essenskonzept ändern Die Konferenz zweimal pro Jahr durchführen Auf mehrere Schweizer Städte ausweiten Jede Option wurde gegen gewichtete Kriterien bewertet. Das Ergebnis bestätigte das Bauchgefühl: Nicht skalieren.\nDie Alte Kaserne bietet entscheidende Vorteile, die anderswo schwer zu replizieren sind:\nGünstiger Preis als städtischer Veranstaltungsort Mehrere Räume auf drei Stockwerken, ideal für Open Spaces und Workshops Vertrauensvolle Partnerschaft mit dem Venue-Team, das sogar das Essen kocht und sich um die Organisatoren kümmert Infrastrukturinvestitionen wie WLAN-Repeater und Videoverbindungen, die von Jahr zu Jahr bestehen bleiben Community zuerst # Das Herzstück der Entscheidung ist die Vision der DevOpsDays Zürich:\n«DevOps-Community im Umkreis von 200 Kilometern um Zürich, die lernen, netzwerken und teilen möchte. Die DevOpsDays sind eine zweitägige Vor-Ort-Konferenz mit einem Track, die Top-Themen, Networking-Möglichkeiten, Gleichgesinnte bietet und inspirierend, motivierend, intensiv und ganzheitlich ist. Anders als kommerzielle Konferenzen hat unsere Konferenz Herz und Seele.»\nDer Ticketpreis ist seit dem Anfang stabil geblieben: CHF 250 für eine zweitägige Konferenz inklusive Mittagessen, Abendveranstaltung mit Essen und Getränken, Workshops und internationalen Top-Speakern. Wenn Geld übrig bleibt, geht es an Organisationen, die Geflüchteten den Einstieg in die IT-Branche ermöglichen oder unterrepräsentierte Gruppen, insbesondere Mädchen, mit Technologie in Kontakt bringen.\nWie Dirk es formulierte:\n«Wir machen das nicht für das Geld. Geld verdienen wir in unseren Hauptjobs. Das hier machen wir, weil es Spass macht. Es ist eine fantastische Konferenz und wir haben ein grossartiges Team.»\nDas stabile Kernteam # Das Organisationsteam ist seit mindestens drei Jahren stabil. Jedes Kernmitglied hat eine klare Verantwortung, und es gibt ein Buddy-Konzept, bei dem jeder Neueinsteiger eine Ansprechperson hat. Verantwortlichkeiten können rotieren, sodass Personen neue Rollen lernen können und dabei Unterstützung erhalten.\nDie Planung beginnt direkt nach den Sommerferien. Bis die aktuelle Konferenz endet, ist das Datum für die nächste Ausgabe bereits bestätigt und angekündigt. Das gibt dem Team Stabilität und einen klaren Planungshorizont.\nMassnahmen ohne Skalierung # Das Team ignoriert die Nachfrage nicht. Stattdessen werden gezielte Massnahmen geprüft:\nTagestickets, damit Personen, die nur einen Tag kommen können, Kapazität freigeben Besseres Early-Bird-Timing, um allen eine faire Chance zu geben Angepasste Überbuchungsstrategien, um No-Shows zu berücksichtigen Kernaussagen # Grösser ist nicht immer besser. Eine Community-Konferenz kann mehr Wert schaffen, indem sie intim und fokussiert bleibt, statt nach Grösse zu streben. Daten statt Bauchgefühl nutzen. Die Tradeoff-Analyse bestätigte die intuitive Entscheidung und gab dem Team Sicherheit und ein gemeinsames Verständnis. Community vor Kommerzialisierung. Erschwingliche Ticketpreise und Spenden an gute Zwecke bauen Vertrauen und Loyalität auf. In die Venue-Beziehung investieren. Langfristige Partnerschaften mit einem vertrauenswürdigen Veranstaltungsort reduzieren Risiko und verbessern die Qualität Jahr für Jahr. Stabilität im Kernteam ermöglicht institutionelles Wissen und reibungslosen Betrieb, auch wenn neue Mitglieder dazukommen. Die DevOpsDays Zürich sind der Beweis dafür, dass man neun Wochen im Voraus ausverkauft sein kann und trotzdem Qualität über Quantität wählt. ","date":"24. October 2024","externalUrl":null,"permalink":"/de/blogs/devopsdays-zuerich-groesser-ist-nicht-immer-besser/","section":"Blogs","summary":"Am 4. Oktober 2024 fand in Antwerpen der globale DevOpsDays Organizer Summit statt, bei dem Organisatoren von DevOpsDays-Veranstaltungen aus der ganzen Welt zusammenkamen. Unser Team von den DevOpsDays Zürich hielt eine Präsentation mit dem Titel «Bigger is Not Always Better». Ich konnte leider nicht persönlich dabei sein wegen einer anderen Konferenz, aber meine Mitorganisatoren Nadine und Dirk haben die Bühne grossartig gemeistert. Hier ist die Geschichte, warum wir uns bewusst dagegen entschieden haben, unsere ausverkaufte Konferenz zu skalieren.\n","title":"DevOpsDays Zürich: Grösser ist nicht immer besser","type":"blogs"},{"content":"","date":"24. October 2024","externalUrl":null,"permalink":"/de/tags/konferenz/","section":"Tags","summary":"","title":"Konferenz","type":"tags"},{"content":"","date":"24 October 2024","externalUrl":null,"permalink":"/en/tags/scaling/","section":"Tags","summary":"","title":"Scaling","type":"tags"},{"content":"","date":"24. October 2024","externalUrl":null,"permalink":"/de/tags/skalierung/","section":"Tags","summary":"","title":"Skalierung","type":"tags"},{"content":"","date":"20 October 2024","externalUrl":null,"permalink":"/en/tags/enterprise-architecture/","section":"Tags","summary":"","title":"Enterprise Architecture","type":"tags"},{"content":"In today\u0026rsquo;s rapidly evolving digital landscape, enterprises must strategically leverage advanced technologies to stay competitive and drive innovation.\nEnterprise Architecture Meets AI # This presentation explores the intersection of Enterprise Architecture and Artificial Intelligence, focusing on how organizations can implement and benefit from robust platform strategies.\nWhat You Will Learn # The session provides actionable insights and real-world examples to help you lead your organization into the future.\n1. Platform Strategy How to develop and implement a successful platform strategy that aligns technology investments with business goals.\n2. Platform Engineering How to effectively leverage platform engineering to build the foundation for scalable, AI-ready systems.\n3. AI-Integrated DevOps How to integrate AI into your DevOps processes to drive efficiency and innovation across the entire software lifecycle.\nYou will leave with a clear understanding of how these three pillars work together to create strategic advantage.\n","date":"20 October 2024","externalUrl":null,"permalink":"/en/speaking/harnessing-enterprise-architecture-and-ai/","section":"Speaking","summary":"In today’s rapidly evolving digital landscape, enterprises must strategically leverage advanced technologies to stay competitive and drive innovation.\nEnterprise Architecture Meets AI # This presentation explores the intersection of Enterprise Architecture and Artificial Intelligence, focusing on how organizations can implement and benefit from robust platform strategies.\n","title":"Harnessing the Power of Enterprise Architecture and AI for Strategic Advantage","type":"speaking"},{"content":"","date":"25 September 2024","externalUrl":null,"permalink":"/en/tags/continuous-delivery/","section":"Tags","summary":"","title":"Continuous Delivery","type":"tags"},{"content":"","date":"25 September 2024","externalUrl":null,"permalink":"/en/tags/fast-flow/","section":"Tags","summary":"","title":"Fast Flow","type":"tags"},{"content":"","date":"25 September 2024","externalUrl":null,"permalink":"/en/tags/kubernetes/","section":"Tags","summary":"","title":"Kubernetes","type":"tags"},{"content":"What are the railroad tracks of your SAFe agile release trains? How are they built, and why do they matter so much? In this talk at the SAFe Leadership Forum, I explore how platform engineering creates the foundation that enables agile teams to continuously deliver value for fast flow.\nThe challenge: cognitive load in SAFe # When we look at the continuous delivery pipeline inside the SAFe framework, we see that it holds all the workflows, activities, and automation that agile teams need. That is already a lot. But it gets worse. In SAFe, teams practice \u0026ldquo;you build it, you run it,\u0026rdquo; which means every agile release train needs infrastructure (cloud or on-prem), runtime environments like Docker or Kubernetes, CI/CD tools like GitLab or CircleCI, monitoring with Prometheus or Dynatrace, security scanning with Snyk or SonarQube, and collaboration tools like Jira or Confluence.\nIn large organisations with multiple ARTs, each one maintains its own continuous delivery pipeline. This leads to inconsistencies, an exploding tool landscape, and a cognitive load that is simply too high for the teams. Their focus shifts from building solutions to managing infrastructure.\nTeam topologies meet SAFe # In 2019, Matthew Skelton and Manuel Pais published \u0026ldquo;Team Topologies,\u0026rdquo; which had a huge influence on how we think about organising teams. They identified four fundamental topologies: stream-aligned teams that work on a product domain, enabling teams that help others overcome obstacles, complicated subsystem teams, and platform teams that provide capabilities to all other teams.\nWhen we combine these topologies with SAFe, the picture becomes clear. Inside an agile release train, you have agile teams (stream-aligned), a system team (enabling), and a platform team. For larger organisations with multiple ARTs, it can even make sense to have a dedicated platform ART with 50 to 120 people.\nBuilding the platform: an internal product # The platform team builds an internal product. The customers of this product are the agile teams and ARTs. The platform provides all the tools and capabilities these teams need to build their solutions: observability, security, CI/CD, infrastructure provisioning, and more.\nA critical distinction: the platform team does not do the monitoring for the teams. They provide the capability of monitoring. The teams themselves use these tools to observe their solutions because they practice DevOps. They build it, they run it. The platform team generates value for the agile teams, and the agile teams generate value for their customers.\n\u0026ldquo;The platform team only gives the capability to the teams. The doing is within the teams because they are doing DevOps.\u0026rdquo;\nArchitecture principles: the floating platform # When architecting such a platform, two concepts are essential. First, use adapters for every tool you integrate. In my 22 years of career, I have seen tools come and go constantly. You never know how long GitLab, GitHub, or any other tool will be around. With adapters, you can easily swap tools without disrupting the teams.\nSecond, follow the \u0026ldquo;floating platform\u0026rdquo; concept from Gregor Hohpe\u0026rsquo;s books on platform strategy and cloud strategy. The idea: build a platform with an excellent developer experience, integrate all the tools and cloud providers, but never abstract them away. Do not duplicate features. If you do, your platform gets dragged into complexity and starts to sink. A floating platform floats on top of the tools, making them accessible in a governed, streamlined way.\nLive demo: the platform in action # During the talk, I demonstrated a platform we built together with LGT, a private bank from Liechtenstein. This platform, which we call the Zühlke Platform Plane, showcases what a modern internal developer platform looks like:\nSelf-service portal: Teams can create repositories, provision databases, and deploy applications without tickets or waiting. Single sign-on: One login gives access to all tools. No more juggling multiple accounts and passwords. Spaces: Each project or product gets its own space backed by a Kubernetes cluster. Owners can onboard and offboard team members in seconds. Partner concept: External partners bring their own identity, get integrated via Microsoft Entra, and can self-manage their teams. AI-powered features: An AI assistant answers documentation questions, analyzes Docker images, and helps with log analysis. When you have everything in one platform, creating these AI use cases becomes straightforward. FinOps: Cost tracking is built in so teams can see what their applications cost and optimise accordingly. Security scanning: All repositories and container images are continuously scanned for vulnerabilities with full provenance tracking. \u0026ldquo;When a developer deploys an application, they automatically get monitoring, logging, dashboards, everything. They don\u0026rsquo;t need to care about any of that. This is the power of such a platform.\u0026rdquo;\nWhy platform engineering matters for SAFe # Gartner identifies platform engineering as one of the top technology trends, and McKinsey and BCG agree. They predict that 75% of organisations will have such a platform in the future. In the context of SAFe, this platform is nothing less than your continuous delivery pipeline, the railroad tracks for your agile release trains.\nThe platform engineering team creates the platform as an internal product. It is a self-service portal with all the capabilities and tools agile teams need to build their solutions. With that, the platform becomes the foundation of your entire SAFe transformation.\nKey takeaways # Cognitive load is the bottleneck: When every ART manages its own tools and infrastructure, the complexity becomes unmanageable. Platform engineering solves this. Team topologies and SAFe fit together: Platform teams in SAFe provide the foundation that stream-aligned teams need to focus on delivering value. The platform is an internal product: Treat it like a product with internal customers. The platform team builds it, and the agile teams use it. Use adapters and build a floating platform: Integrate tools without abstracting them away. Stay flexible for the future. Self-service is essential: No ticket ops. Teams must be able to onboard people, create environments, and deploy applications on their own. AI becomes easy on a platform: When all tools, data, and capabilities are in one place, building AI use cases is like playing Lego. We are entering the age of industrialisation of software development: Platform engineering is the foundation that makes this possible. ","date":"25 September 2024","externalUrl":null,"permalink":"/en/blogs/safe-leadership-forum-empowering-safe-with-platform-engineering/","section":"Blogs","summary":"What are the railroad tracks of your SAFe agile release trains? How are they built, and why do they matter so much? In this talk at the SAFe Leadership Forum, I explore how platform engineering creates the foundation that enables agile teams to continuously deliver value for fast flow.\n","title":"SAFe Leadership Forum: Empowering SAFe with Platform Engineering for Fast Flow","type":"blogs"},{"content":"Was sind die Schienen Ihrer SAFe Agile Release Trains? Wie werden sie gebaut, und warum sind sie so entscheidend? In diesem Vortrag am SAFe Leadership Forum zeige ich, wie Platform Engineering das Fundament schafft, das agilen Teams ermöglicht, kontinuierlich Wert für Fast Flow zu liefern.\nDie Herausforderung: Kognitive Belastung in SAFe # Die Continuous Delivery Pipeline im SAFe-Framework enthält alle Workflows, Aktivitäten und Automatisierungen, die agile Teams benötigen. Das ist bereits sehr viel. Aber es wird noch schlimmer. In SAFe praktizieren Teams \u0026ldquo;You build it, you run it\u0026rdquo;, was bedeutet, dass jeder Agile Release Train Infrastruktur (Cloud oder On-Premise), Laufzeitumgebungen wie Docker oder Kubernetes, CI/CD-Tools wie GitLab oder CircleCI, Monitoring mit Prometheus oder Dynatrace, Security-Scanning mit Snyk oder SonarQube und Kollaborationstools wie Jira oder Confluence benötigt.\nIn grossen Organisationen mit mehreren ARTs unterhält jeder seinen eigenen Continuous Delivery Pipeline. Das führt zu Inkonsistenzen, einer explodierenden Tool-Landschaft und einer kognitiven Belastung, die für die Teams schlicht zu hoch ist. Ihr Fokus verschiebt sich vom Entwickeln von Lösungen zum Verwalten von Infrastruktur.\nTeam Topologies und SAFe zusammengedacht # 2019 veröffentlichten Matthew Skelton und Manuel Pais \u0026ldquo;Team Topologies\u0026rdquo;, was einen enormen Einfluss auf die Organisation von Teams hatte. Sie identifizierten vier grundlegende Topologien: Stream-aligned Teams, die an einer Produktdomäne arbeiten, Enabling Teams, die anderen helfen, Hindernisse zu überwinden, Complicated Subsystem Teams und Platform Teams, die Fähigkeiten für alle anderen Teams bereitstellen.\nWenn wir diese Topologien mit SAFe kombinieren, wird das Bild klar. Innerhalb eines Agile Release Trains gibt es agile Teams (Stream-aligned), ein System Team (Enabling) und ein Platform Team. Für grössere Organisationen mit mehreren ARTs kann es sogar sinnvoll sein, einen dedizierten Platform ART mit 50 bis 120 Personen aufzubauen.\nDie Plattform als internes Produkt # Das Platform Team entwickelt ein internes Produkt. Die Kunden dieses Produkts sind die agilen Teams und ARTs. Die Plattform stellt alle Werkzeuge und Fähigkeiten bereit, die diese Teams zum Erstellen ihrer Lösungen brauchen: Observability, Security, CI/CD, Infrastruktur-Provisionierung und mehr.\nEine entscheidende Unterscheidung: Das Platform Team macht nicht das Monitoring für die Teams. Es stellt die Fähigkeit des Monitorings bereit. Die Teams selbst nutzen diese Werkzeuge, um ihre Lösungen zu überwachen, weil sie DevOps praktizieren. Sie bauen es, sie betreiben es. Das Platform Team generiert Wert für die agilen Teams, und die agilen Teams generieren Wert für ihre Kunden.\n\u0026ldquo;Das Platform Team gibt den Teams nur die Fähigkeit. Das Ausführen liegt bei den Teams, weil sie DevOps praktizieren.\u0026rdquo;\nArchitekturprinzipien: Die schwebende Plattform # Beim Aufbau einer solchen Plattform sind zwei Konzepte entscheidend. Erstens: Verwenden Sie Adapter für jedes Tool, das Sie integrieren. In meinen 22 Jahren Karriere habe ich ständig gesehen, wie Tools kamen und gingen. Man weiss nie, wie lange GitLab, GitHub oder ein anderes Tool bestehen bleibt. Mit Adaptern können Sie Tools einfach austauschen, ohne die Teams zu beeinträchtigen.\nZweitens: Folgen Sie dem \u0026ldquo;Floating Platform\u0026rdquo;-Konzept von Gregor Hohpe aus seinen Büchern über Plattformstrategie und Cloud-Strategie. Die Idee: Bauen Sie eine Plattform mit ausgezeichneter Developer Experience, integrieren Sie alle Tools und Cloud-Anbieter, aber abstrahieren Sie sie niemals weg. Duplizieren Sie keine Features. Wenn Sie das tun, wird Ihre Plattform in die Tiefe gezogen und beginnt zu sinken. Eine schwebende Plattform schwebt über den Tools und macht sie auf eine kontrollierte, strukturierte Weise zugänglich.\nLive-Demo: Die Plattform in Aktion # Während des Vortrags habe ich eine Plattform demonstriert, die wir gemeinsam mit der LGT aufgebaut haben, einer Privatbank aus Liechtenstein. Diese Plattform, die wir Zühlke Platform Plane nennen, zeigt, wie eine moderne interne Entwicklerplattform aussieht:\nSelf-Service-Portal: Teams können Repositories erstellen, Datenbanken bereitstellen und Anwendungen deployen, ganz ohne Tickets oder Wartezeiten. Single Sign-On: Ein Login gibt Zugang zu allen Tools. Kein Jonglieren mehr mit verschiedenen Konten und Passwörtern. Spaces: Jedes Projekt oder Produkt erhält seinen eigenen Space, hinterlegt mit einem Kubernetes-Cluster. Eigentümer können Teammitglieder in Sekunden onboarden und offboarden. Partner-Konzept: Externe Partner bringen ihre eigene Identität mit, werden über Microsoft Entra integriert und können ihre Teams selbst verwalten. KI-gestützte Features: Ein KI-Assistent beantwortet Dokumentationsfragen, analysiert Docker-Images und hilft bei der Log-Analyse. Wenn alles auf einer Plattform vereint ist, wird die Erstellung solcher KI-Anwendungsfälle einfach. FinOps: Kostenverfolgung ist integriert, damit Teams sehen, was ihre Anwendungen kosten, und entsprechend optimieren können. Security-Scanning: Alle Repositories und Container-Images werden kontinuierlich auf Schwachstellen gescannt, mit vollständiger Nachverfolgbarkeit. \u0026ldquo;Wenn ein Entwickler eine Anwendung deployt, bekommt er automatisch Monitoring, Logging, Dashboards, einfach alles. Er muss sich um nichts davon kümmern. Das ist die Kraft einer solchen Plattform.\u0026rdquo;\nWarum Platform Engineering für SAFe wichtig ist # Gartner identifiziert Platform Engineering als einen der Top-Technologietrends, und McKinsey sowie BCG stimmen zu. Sie prognostizieren, dass 75 % der Organisationen in Zukunft eine solche Plattform haben werden. Im Kontext von SAFe ist diese Plattform nichts weniger als Ihre Continuous Delivery Pipeline: die Schienen für Ihre Agile Release Trains.\nDas Platform Engineering Team erstellt die Plattform als internes Produkt. Es ist ein Self-Service-Portal mit allen Fähigkeiten und Werkzeugen, die agile Teams brauchen, um ihre Lösungen zu erstellen. Damit wird die Plattform zum Fundament Ihrer gesamten SAFe-Transformation.\nKernaussagen # Kognitive Belastung ist der Engpass: Wenn jeder ART seine eigenen Tools und Infrastruktur verwaltet, wird die Komplexität unbeherrschbar. Platform Engineering löst dieses Problem. Team Topologies und SAFe passen zusammen: Platform Teams in SAFe liefern das Fundament, das Stream-aligned Teams brauchen, um sich auf die Wertschöpfung zu konzentrieren. Die Plattform ist ein internes Produkt: Behandeln Sie sie wie ein Produkt mit internen Kunden. Das Platform Team baut sie, die agilen Teams nutzen sie. Adapter und schwebende Plattform: Integrieren Sie Tools, ohne sie zu abstrahieren. Bleiben Sie flexibel für die Zukunft. Self-Service ist unverzichtbar: Kein Ticket-Ops. Teams müssen eigenständig Leute onboarden, Umgebungen erstellen und Anwendungen deployen können. KI wird auf einer Plattform einfach: Wenn alle Tools, Daten und Fähigkeiten an einem Ort sind, ist das Erstellen von KI-Anwendungsfällen wie Lego spielen. Wir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein: Platform Engineering macht dies möglich. ","date":"25. September 2024","externalUrl":null,"permalink":"/de/blogs/safe-leadership-forum-safe-mit-platform-engineering-staerken/","section":"Blogs","summary":"Was sind die Schienen Ihrer SAFe Agile Release Trains? Wie werden sie gebaut, und warum sind sie so entscheidend? In diesem Vortrag am SAFe Leadership Forum zeige ich, wie Platform Engineering das Fundament schafft, das agilen Teams ermöglicht, kontinuierlich Wert für Fast Flow zu liefern.\n","title":"SAFe Leadership Forum: SAFe mit Platform Engineering für Fast Flow stärken","type":"blogs"},{"content":"","date":"25 September 2024","externalUrl":null,"permalink":"/en/tags/team-topologies/","section":"Tags","summary":"","title":"Team Topologies","type":"tags"},{"content":"","date":"24 September 2024","externalUrl":null,"permalink":"/en/tags/architecture/","section":"Tags","summary":"","title":"Architecture","type":"tags"},{"content":"","date":"24. September 2024","externalUrl":null,"permalink":"/de/tags/architektur/","section":"Tags","summary":"","title":"Architektur","type":"tags"},{"content":"In September 2024, I had the privilege of delivering a keynote at the Roche DevOps Conference in Poland. The topic: how to architect for continuous delivery. This is a subject close to my heart, because after more than two decades of working in software delivery, I keep seeing the same fundamental patterns that separate high-performing organizations from those that struggle.\nThe Broken Value Stream # When I visit companies, I often encounter the same picture. The business has big ideas and writes them into Jira tickets and Word documents. Then they throw them over a wall of confusion to the development team. The developers implement something and throw it over to testing. The testers look at what was specified, compare it to what was built (which is never quite the same), test something, and throw it over to operations. Operations asks \u0026ldquo;How can we operate that?\u0026rdquo; and somehow, with many late nights, they get it running. Then the business or the customer sees the result and says: \u0026ldquo;What is that? We cannot use it.\u0026rdquo;\nThis pattern is driven by silo organizations with different goals, no alignment, and legacy systems. The value stream is completely broken by these walls of confusion. DevOps is the answer: a mindset, a culture, and a set of technical practices that allows teams to organize across the entire value stream, moving from project thinking to product thinking.\nBuild the Right Thing Right # One principle I always emphasize: DevOps is not just about building things faster. It is about building the right thing right. Building the right thing is about effectiveness. Building the thing right is about efficiency. You need both.\nThe science backs this up. The book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim identifies 24 key capabilities that drive software delivery performance, organized into five categories: continuous delivery, architecture, product and process, culture, and lean management. What makes this research powerful is the map showing how these capabilities influence each other. When you want to achieve the outcomes on the right side of that map, you need to invest in the capabilities on the left side. For decision makers, this is an invaluable guide.\nMeasuring Software Delivery Performance with DORA # The DORA metrics are the only scientifically proven KPIs for measuring software delivery performance:\nLead Time for Changes: How long from code commit to production. Elite performers do this in less than an hour. Deployment Frequency: How often you deploy to production. Elite teams deploy on demand, multiple times per day. Time to Restore Service: How quickly you recover from a failure. Elite teams recover within an hour. Change Failure Rate: What percentage of deployments cause a failure. Elite teams stay between 0 and 15%. The important thing: you do not need to be elite. Think about your context, define what matters for your products, and measure accordingly.\nValue Stream Mapping: See the Whole System # Before optimizing anything, you need to understand your whole value stream. Value stream mapping is a simple but powerful technique. Bring all the people working on a product into a room, give them Post-its, and ask them to lay out every step from idea to production. Then identify who is responsible for each step, and measure three things:\nProcess Time (PT): The actual value-adding work time Lead Time (LT): The total elapsed time including all waiting Percentage Complete and Accurate (%C\u0026amp;A): The quality output of each step When you do this, bottlenecks become visible immediately. For example, a testing step might have 8 hours of actual work but 336 hours of lead time, meaning massive waiting. With the whole system visible, teams can improve the entire stream rather than optimizing one part at the expense of another.\nShift Left: Quality and Security # Building quality in means shifting left. Instead of the traditional V-model with delayed feedback cycles of three to six months, you want Behavior Driven Development (BDD) with testable acceptance criteria from the start, and Test Driven Development (TDD) where tests are written before code. This flips the testing pyramid: many fast, cheap unit tests at the base, fewer integration tests in the middle, and only a small number of slow, expensive end-to-end tests at the top.\n\u0026ldquo;50% of the money a Musk company invests in a new product is in automated testing.\u0026rdquo; Think about your own product. Is it even close to 10%?\nThe same shift-left principle applies to security. Your continuous delivery pipeline should include static code analysis, software composition analysis, container scanning, secret detection, and dynamic application security testing. And even when nothing changes in your code, scheduled pipelines must regularly check for newly discovered vulnerabilities.\nArchitect for Observability # As systems evolve from two-tier applications to distributed microservice architectures, monitoring evolves into full observability. You need tracing, metrics, and logs, all built into the application from the start. This means architecting for observability, not bolting it on after deployment.\nInfrastructure as code, staging environments congruent to production, feature toggles for canary releases, and cross-team collaboration on monitoring are all essential components.\nPlatform Engineering: The Enabler # All of this creates significant cognitive load for teams. This is why the industry is moving toward platform engineering. Gartner predicts that by 2027, 75% of organizations will have created an internal platform.\nThe model is straightforward: a platform team builds and maintains an internal developer platform as a product. The customers of that product are the product teams. The platform provides the tools and capabilities that product teams need to practice DevOps. The platform team enables; the product teams build, run, and maintain their products.\nFor example, the platform team provides observability capabilities. The product teams use those capabilities to monitor their own applications. The platform team does not monitor the applications for them. This clear separation of concerns generates value at every level.\nKey Takeaways # Build the right thing right. Do not focus only on speed. Ensure you are building what customers actually need, and building it with quality. Map your value stream. Understand the entire flow from idea to production before optimizing any single part. Use DORA metrics wisely. They are proven KPIs, but apply them to your context rather than chasing elite status blindly. Shift left on quality and security. Invest in test automation, BDD, TDD, and pipeline security from the start. Architect for observability. Build telemetry into your applications, do not add it as an afterthought. Invest in platform engineering. Enable your teams to do DevOps by providing them with a self-service platform that reduces cognitive load. We are clearly entering the age of industrialized software development. Platform engineering is the key enabler, and architecting for continuous delivery is how we get there.\n","date":"24 September 2024","externalUrl":null,"permalink":"/en/blogs/how-to-architect-for-continuous-delivery/","section":"Blogs","summary":"In September 2024, I had the privilege of delivering a keynote at the Roche DevOps Conference in Poland. The topic: how to architect for continuous delivery. This is a subject close to my heart, because after more than two decades of working in software delivery, I keep seeing the same fundamental patterns that separate high-performing organizations from those that struggle.\n","title":"How to Architect for Continuous Delivery","type":"blogs"},{"content":"Im September 2024 durfte ich eine Keynote an der Roche DevOps Conference in Polen halten. Das Thema: Wie man für Continuous Delivery die richtige Architektur schafft. Dieses Thema liegt mir besonders am Herzen, denn nach über zwei Jahrzehnten in der Software-Delivery sehe ich immer wieder dieselben Muster, die leistungsstarke Organisationen von jenen unterscheiden, die kämpfen.\nDer gebrochene Value Stream # Wenn ich Unternehmen besuche, begegne ich oft dem gleichen Bild. Das Business hat grosse Ideen und schreibt sie in Jira-Tickets und Word-Dokumente. Dann werden sie über eine Mauer der Verwirrung zum Entwicklungsteam geworfen. Die Entwickler implementieren etwas und werfen es zum Testing weiter. Die Tester schauen auf die Spezifikation, vergleichen sie mit dem Gebauten (was nie ganz übereinstimmt), testen etwas und werfen es zum Betrieb weiter. Der Betrieb fragt: \u0026ldquo;Wie sollen wir das betreiben?\u0026rdquo; Und irgendwie, mit vielen Nachtschichten, bringen sie es zum Laufen. Dann sieht das Business oder der Kunde das Ergebnis und sagt: \u0026ldquo;Was ist das? Damit können wir nichts anfangen.\u0026rdquo;\nDieses Muster wird durch Silo-Organisationen mit unterschiedlichen Zielen, fehlender Abstimmung und Legacy-Systemen angetrieben. Der Value Stream ist durch diese Mauern der Verwirrung komplett gebrochen. DevOps ist die Antwort: ein Mindset, eine Kultur und ein Set von technischen Praktiken, das es Teams ermöglicht, sich über den gesamten Value Stream zu organisieren und von Projekt-Denken zu Produkt-Denken zu wechseln.\nDas Richtige richtig bauen # Ein Prinzip, das ich immer betone: Bei DevOps geht es nicht nur darum, Dinge schneller zu bauen. Es geht darum, das Richtige richtig zu bauen. Das Richtige zu bauen bedeutet Effektivität. Es richtig zu bauen bedeutet Effizienz. Man braucht beides.\nDie Wissenschaft bestätigt das. Das Buch Accelerate von Nicole Forsgren, Jez Humble und Gene Kim identifiziert 24 Schlüsselfähigkeiten, die die Software-Delivery-Performance antreiben, organisiert in fünf Kategorien: Continuous Delivery, Architektur, Produkt und Prozess, Kultur sowie Lean Management. Was diese Forschung so wertvoll macht, ist die Landkarte, die zeigt, wie diese Fähigkeiten sich gegenseitig beeinflussen. Wenn man die Ergebnisse auf der rechten Seite erreichen will, muss man in die Fähigkeiten auf der linken Seite investieren. Für Entscheidungsträger ist das ein unschätzbarer Leitfaden.\nSoftware-Delivery-Performance messen mit DORA # Die DORA-Metriken sind die einzigen wissenschaftlich bewiesenen KPIs zur Messung der Software-Delivery-Performance:\nLead Time for Changes: Wie lange dauert es vom Code-Commit bis zur Produktion. Elite-Performer schaffen das in weniger als einer Stunde. Deployment Frequency: Wie oft wird in die Produktion deployed. Elite-Teams deployen on demand, mehrmals täglich. Time to Restore Service: Wie schnell erholt man sich von einem Ausfall. Elite-Teams schaffen das innerhalb einer Stunde. Change Failure Rate: Welcher Prozentsatz der Deployments verursacht einen Ausfall. Elite-Teams liegen zwischen 0 und 15%. Das Wichtige dabei: Man muss nicht Elite sein. Man sollte über den eigenen Kontext nachdenken, definieren, was für die eigenen Produkte wichtig ist, und entsprechend messen.\nValue Stream Mapping: Das ganze System sehen # Bevor man irgendetwas optimiert, muss man den gesamten Value Stream verstehen. Value Stream Mapping ist eine einfache, aber wirkungsvolle Technik. Man bringt alle Personen, die an einem Produkt arbeiten, in einen Raum, gibt ihnen Post-its und bittet sie, jeden Schritt von der Idee bis zur Produktion aufzulisten. Dann identifiziert man, wer für jeden Schritt verantwortlich ist, und misst drei Dinge:\nProcess Time (PT): Die tatsächliche wertschöpfende Arbeitszeit Lead Time (LT): Die gesamte verstrichene Zeit inklusive aller Wartezeiten Percentage Complete and Accurate (%C\u0026amp;A): Die Qualität des Outputs jedes Schritts Wenn man das tut, werden Engpässe sofort sichtbar. Zum Beispiel könnte ein Test-Schritt 8 Stunden tatsächliche Arbeit zeigen, aber 336 Stunden Lead Time, was massive Wartezeiten bedeutet. Mit dem sichtbaren Gesamtsystem können Teams den gesamten Stream verbessern, statt einen Teil auf Kosten eines anderen zu optimieren.\nShift Left: Qualität und Sicherheit # Qualität einbauen bedeutet Shift Left. Statt des traditionellen V-Modells mit verzögerten Feedback-Zyklen von drei bis sechs Monaten will man Behavior Driven Development (BDD) mit testbaren Akzeptanzkriterien von Anfang an und Test Driven Development (TDD), bei dem Tests vor dem Code geschrieben werden. Das dreht die Testpyramide um: viele schnelle, günstige Unit-Tests an der Basis, weniger Integrationstests in der Mitte und nur eine kleine Anzahl langsamer, teurer End-to-End-Tests an der Spitze.\n\u0026ldquo;50% des Geldes, das ein Musk-Unternehmen in ein neues Produkt investiert, geht in automatisiertes Testen.\u0026rdquo; Denkt einmal an euer eigenes Produkt. Kommt ihr auch nur annähernd an 10%?\nDasselbe Shift-Left-Prinzip gilt für die Sicherheit. Die Continuous-Delivery-Pipeline sollte statische Code-Analyse, Software Composition Analysis, Container-Scanning, Secret Detection und Dynamic Application Security Testing beinhalten. Und selbst wenn sich nichts am Code ändert, müssen geplante Pipelines regelmässig auf neu entdeckte Schwachstellen prüfen.\nArchitektur für Observability # Wenn Systeme sich von Zwei-Schicht-Anwendungen zu verteilten Microservice-Architekturen entwickeln, wird Monitoring zu vollständiger Observability. Man braucht Tracing, Metriken und Logs, alles von Anfang an in die Anwendung eingebaut. Das bedeutet: für Observability architekturieren, nicht nachträglich draufschrauben.\nInfrastructure as Code, Staging-Umgebungen, die der Produktion entsprechen, Feature Toggles für Canary Releases und teamübergreifende Zusammenarbeit beim Monitoring sind alle essentielle Bestandteile.\nPlatform Engineering: Der Enabler # All das erzeugt eine erhebliche kognitive Belastung für Teams. Deshalb bewegt sich die Industrie in Richtung Platform Engineering. Gartner prognostiziert, dass bis 2027 75% der Organisationen eine interne Plattform aufgebaut haben werden.\nDas Modell ist klar: Ein Platform-Team baut und pflegt eine interne Developer-Plattform als Produkt. Die Kunden dieses Produkts sind die Produkt-Teams. Die Plattform stellt die Werkzeuge und Fähigkeiten bereit, die Produkt-Teams brauchen, um DevOps zu praktizieren. Das Platform-Team befähigt; die Produkt-Teams bauen, betreiben und warten ihre Produkte.\nZum Beispiel stellt das Platform-Team Observability-Fähigkeiten bereit. Die Produkt-Teams nutzen diese Fähigkeiten, um ihre eigenen Applikationen zu überwachen. Das Platform-Team überwacht nicht die Applikationen für sie. Diese klare Aufgabenteilung erzeugt Wert auf jeder Ebene.\nKernaussagen # Das Richtige richtig bauen. Nicht nur auf Geschwindigkeit fokussieren. Sicherstellen, dass man baut, was Kunden wirklich brauchen, und das in guter Qualität. Den Value Stream visualisieren. Den gesamten Fluss von der Idee bis zur Produktion verstehen, bevor man einzelne Teile optimiert. DORA-Metriken klug einsetzen. Sie sind bewiesene KPIs, aber man sollte sie auf den eigenen Kontext anwenden statt blind den Elite-Status anzustreben. Qualität und Sicherheit nach links verschieben. In Testautomatisierung, BDD, TDD und Pipeline-Sicherheit von Anfang an investieren. Für Observability architekturieren. Telemetrie in die Applikationen einbauen, nicht erst nachträglich hinzufügen. In Platform Engineering investieren. Teams befähigen, DevOps zu praktizieren, indem man ihnen eine Self-Service-Plattform bereitstellt, die die kognitive Belastung reduziert. Wir betreten eindeutig das Zeitalter der industrialisierten Softwareentwicklung. Platform Engineering ist der zentrale Enabler, und die richtige Architektur für Continuous Delivery ist der Weg dorthin.\n","date":"24. September 2024","externalUrl":null,"permalink":"/de/blogs/wie-man-fuer-continuous-delivery-architektur-schafft/","section":"Blogs","summary":"Im September 2024 durfte ich eine Keynote an der Roche DevOps Conference in Polen halten. Das Thema: Wie man für Continuous Delivery die richtige Architektur schafft. Dieses Thema liegt mir besonders am Herzen, denn nach über zwei Jahrzehnten in der Software-Delivery sehe ich immer wieder dieselben Muster, die leistungsstarke Organisationen von jenen unterscheiden, die kämpfen.\n","title":"Wie man für Continuous Delivery Architektur schafft","type":"blogs"},{"content":"Is DevOps dead? That claim keeps appearing on the internet, with people arguing that platform engineering is taking over. In this talk, which I gave at the Developer Experience Conference at Roche in Poznan, Poland, I explain why DevOps is absolutely not dead and why platform engineering is the key to making it actually work at scale.\nThe real problem with DevOps # We all know the benefits of DevOps: increased deployment frequency, faster lead time, faster time to restore services, and lower change failure rates. Science confirms this through the annual State of DevOps reports. Companies doing DevOps achieve faster time to market, higher quality, better customer satisfaction, and attract top talent.\nBut there is a problem. Modern software development with DevOps comes with a massive technical stack. Our battle cry is \u0026ldquo;you build it, you run it,\u0026rdquo; which sounds great until you realise what that actually means. Every team needs infrastructure (cloud and on-prem), runtime environments (Docker, Kubernetes), CI/CD tools (GitLab, GitHub), monitoring (Prometheus, Grafana, Dynatrace), security scanning (Snyk, SonarQube), collaboration tools (Jira, Confluence), and cost management on top of everything. And somewhere in there, the team also needs to build an actual application.\nIn larger companies, you get multiple of these stacks across different products or silos. The result: inconsistencies, lack of operational experience, tool complexity, and cognitive load that crushes developer productivity. The rate of new features goes down.\n\u0026ldquo;Think about bigger companies. There you have multiple of these stacks for potentially each one of the products. The cognitive load for the developers is just too high.\u0026rdquo;\nThe digital factory: connecting strategy to execution # Before diving into the solution, I want to paint a picture of what modern companies should look like. Imagine a drone company. The board has a vision to increase market share. They create a portfolio of ideas: maintenance drones, fast drones, drones that carry high loads. They prioritise and pass the best idea down to product management. Product managers break it into features: better battery, better motors, software updates. Teams pick up the work.\nNow the new motor team needs to start immediately. Without a platform, they would spend weeks setting up their development environment. With a platform team providing a standardised continuous delivery pipeline, they start within minutes.\nBut the story does not end at delivery. Telemetry data from the product flows back to the teams for continuous improvement and back to the board for strategic decisions: are we gaining market share? Should we invest more or pivot? This feedback loop from strategy through execution and back is what I call the Digital Factory.\nPlatform engineering: the foundation # Where we are today in many companies: different teams use different tools, build their own local environments, and bring non-standardised solutions into production. The tool landscape is enormous, and every team picks what is currently trendy.\nWhere we need to go: platform engineering. Teams work on a standardised platform and bring software into production in a standardised way. The platform provides a defined set of services and tools. This is what I call the industrialisation of software engineering.\nThe target operating model is clear. Product teams focus on feature delivery. The platform team creates a self-service platform with all the skills needed to support the product teams. A large chunk of the technology stack moves to the platform team, while the product-relevant stack stays with the product team.\nHow the platform actually works # The platform team builds an internal product. The customers are the product teams. The platform provides capabilities like observability, security, CI/CD, identity management, and infrastructure provisioning.\nHere is the critical distinction. If the platform provides monitoring capabilities, that means the platform team delivers self-service tools for standardised monitoring. The product teams then use those tools to monitor their own applications. The product teams still practice DevOps. The platform team does not run the products, that would take us back to the old world of separated development and operations.\n\u0026ldquo;The platform team will not run or maintain the products of the product teams. That\u0026rsquo;s a very important distinction to the old IT model.\u0026rdquo;\nArchitecture: floating platforms and adapters # Two architecture principles are essential. First, use adapters for every integrated tool. In 22 years, I have seen many tools come and go. With adapters, you can swap GitLab for GitHub or vice versa without disrupting developers.\nSecond, build a floating platform following Gregor Hohpe\u0026rsquo;s concept. Integrate tools and cloud providers but never abstract them away. Do not duplicate features. If you do, your platform starts to sink under its own weight. A floating platform sits on top of the tools, making them accessible in a governed, streamlined way.\nAnd here is something important: AI is not separate from this. It is a capability of the platform. When you have such a platform, AI and ML capabilities are governed, standardised, and available enterprise-wide. Without this, everyone just uses whatever tools are out there, ungoverned and unstandardised.\nThe platform in action # I demonstrated the Zühlke Platform Plane, which we built together with LGT. Here is what it delivers:\nSelf-service everything: Create repositories, deploy applications, provision databases, all without tickets. Single sign-on: One identity across all tools. Onboard a developer in the morning, offboard in the evening. Access to everything is managed centrally. Partner integration: External companies bring their own identity, get integrated via Microsoft Entra, and manage their own people. Standardised services: Need a MySQL database, MongoDB, or Kafka? One click gives you a governed instance with correct naming, backups, logging, and monitoring already configured. Security by default: All repositories and container images are continuously scanned. Provenance tracking shows exactly who introduced which change. AI-powered tools: Documentation chatbot, Docker image analysis, log analysis. When everything is in one platform, creating AI use cases is like playing Lego. FinOps and emissions tracking: Teams see their costs and carbon footprint right in the platform. Pipelines and runners: Self-hosted runners, high-performance pools, and even virtual machines for mobile development. API explorer: All OpenAPI specifications across the enterprise in one place. \u0026ldquo;When a developer deploys an application, monitoring, logging, dashboards, everything is automatically provided. The cognitive load on the development side goes down.\u0026rdquo;\nKey takeaways # DevOps is not dead: It needs a platform to work at scale. Platform engineering is the enabler, not the replacement. Build a self-service portal: No ticket ops. Enable teams to do everything they need on their own. The platform is an internal product: With internal customers (the product teams) and a dedicated platform team that builds and maintains it. Architect for change: Use adapters and the floating platform concept to stay flexible. AI is a platform capability: Govern it, standardise it, and offer it through the platform instead of letting everyone go their own way. Developer experience matters: When developers get monitoring, security, and infrastructure out of the box, they can focus on what actually creates business value. Platform engineering is the foundation of the digital factory: It enables teams to do DevOps and continuously deliver value. We are entering the age of industrialisation of software development. ","date":"23 September 2024","externalUrl":null,"permalink":"/en/blogs/developer-experience-and-platform-engineering/","section":"Blogs","summary":"Is DevOps dead? That claim keeps appearing on the internet, with people arguing that platform engineering is taking over. In this talk, which I gave at the Developer Experience Conference at Roche in Poznan, Poland, I explain why DevOps is absolutely not dead and why platform engineering is the key to making it actually work at scale.\n","title":"Developer Experience and Platform Engineering: The Foundation of Modern Software Delivery","type":"blogs"},{"content":"Ist DevOps tot? Diese Behauptung taucht immer wieder im Internet auf, mit dem Argument, dass Platform Engineering übernimmt. In diesem Vortrag, den ich an der Developer Experience Conference bei Roche in Poznan, Polen, gehalten habe, erkläre ich, warum DevOps absolut nicht tot ist und warum Platform Engineering der Schlüssel ist, um DevOps in grossem Massstab zum Funktionieren zu bringen.\nDas wahre Problem mit DevOps # Wir alle kennen die Vorteile von DevOps: erhöhte Deployment-Frequenz, schnellere Lead Time, schnellere Wiederherstellung von Services und niedrigere Change Failure Rate. Die Wissenschaft bestätigt dies durch die jährlichen State of DevOps Reports. Unternehmen, die DevOps praktizieren, erreichen schnellere Time-to-Market, höhere Qualität, bessere Kundenzufriedenheit und ziehen Top-Talente an.\nAber es gibt ein Problem. Moderne Softwareentwicklung mit DevOps bringt einen massiven technischen Stack mit sich. Unser Schlachtruf lautet \u0026ldquo;You build it, you run it\u0026rdquo;, was grossartig klingt, bis man realisiert, was das tatsächlich bedeutet. Jedes Team braucht Infrastruktur (Cloud und On-Premise), Laufzeitumgebungen (Docker, Kubernetes), CI/CD-Tools (GitLab, GitHub), Monitoring (Prometheus, Grafana, Dynatrace), Security-Scanning (Snyk, SonarQube), Kollaborationstools (Jira, Confluence) und Cost Management obendrauf. Und irgendwo dazwischen muss das Team auch noch eine Anwendung bauen.\nIn grösseren Unternehmen gibt es dann mehrere dieser Stacks über verschiedene Produkte oder Silos hinweg. Das Ergebnis: Inkonsistenzen, mangelnde operative Erfahrung, Tool-Komplexität und eine kognitive Belastung, die die Entwicklerproduktivität erdrückt. Die Rate neuer Features sinkt.\n\u0026ldquo;In grösseren Unternehmen hat man mehrere dieser Stacks für potenziell jedes einzelne Produkt. Die kognitive Belastung für die Entwickler ist einfach zu hoch.\u0026rdquo;\nDie Digital Factory: Strategie mit Ausführung verbinden # Bevor wir zur Lösung kommen, möchte ich ein Bild zeichnen, wie moderne Unternehmen aussehen sollten. Stellen Sie sich ein Drohnenunternehmen vor. Der Vorstand hat die Vision, den Marktanteil zu erhöhen. Sie erstellen ein Portfolio von Ideen: Wartungsdrohnen, schnelle Drohnen, Drohnen mit hoher Traglast. Sie priorisieren und geben die beste Idee an das Produktmanagement weiter. Produktmanager zerlegen sie in Features: bessere Batterie, bessere Motoren, Software-Updates. Teams beginnen mit der Arbeit.\nDas neue Motor-Team muss sofort starten. Ohne Plattform würden sie Wochen mit dem Aufsetzen ihrer Entwicklungsumgebung verbringen. Mit einem Platform Team, das eine standardisierte Continuous Delivery Pipeline bereitstellt, starten sie innerhalb von Minuten.\nAber die Geschichte endet nicht mit der Auslieferung. Telemetriedaten vom Produkt fliessen zurück zu den Teams für kontinuierliche Verbesserung und zurück zum Vorstand für strategische Entscheidungen: Gewinnen wir Marktanteile? Sollen wir mehr investieren oder umschwenken? Diese Feedback-Schleife von der Strategie über die Ausführung und zurück nenne ich die Digital Factory.\nPlatform Engineering: Das Fundament # Der Zustand in vielen Unternehmen heute: Verschiedene Teams nutzen verschiedene Tools, bauen ihre eigenen lokalen Umgebungen und bringen nicht-standardisierte Lösungen in Produktion. Die Tool-Landschaft ist enorm, und jedes Team wählt, was gerade im Trend liegt.\nWohin wir müssen: Platform Engineering. Teams arbeiten auf einer standardisierten Plattform und bringen Software auf standardisierte Weise in Produktion. Die Plattform bietet ein definiertes Set von Services und Tools. Das nenne ich die Industrialisierung der Softwareentwicklung.\nDas Ziel-Betriebsmodell ist klar: Produktteams konzentrieren sich auf Feature-Delivery. Das Platform Team erstellt eine Self-Service-Plattform mit allen Fähigkeiten, die die Produktteams brauchen. Ein grosser Teil des Technologie-Stacks wandert zum Platform Team, während der produktrelevante Stack bei den Produktteams bleibt.\nWie die Plattform tatsächlich funktioniert # Das Platform Team baut ein internes Produkt. Die Kunden sind die Produktteams. Die Plattform stellt Fähigkeiten bereit wie Observability, Security, CI/CD, Identity Management und Infrastruktur-Provisionierung.\nDie entscheidende Unterscheidung: Wenn die Plattform Monitoring-Fähigkeiten bereitstellt, bedeutet das, dass das Platform Team Self-Service-Werkzeuge für standardisiertes Monitoring liefert. Die Produktteams nutzen dann diese Werkzeuge, um ihre eigenen Anwendungen zu überwachen. Die Produktteams praktizieren weiterhin DevOps. Das Platform Team betreibt nicht die Produkte. Das wäre ein Rückfall in die alte Welt der Trennung von Entwicklung und Betrieb.\n\u0026ldquo;Das Platform Team wird nicht die Produkte der Produktteams betreiben oder warten. Das ist eine sehr wichtige Unterscheidung zum alten IT-Modell.\u0026rdquo;\nArchitektur: Schwebende Plattformen und Adapter # Zwei Architekturprinzipien sind essentiell. Erstens: Verwenden Sie Adapter für jedes integrierte Tool. In 22 Jahren habe ich viele Tools kommen und gehen sehen. Mit Adaptern können Sie GitLab gegen GitHub tauschen oder umgekehrt, ohne die Entwickler zu beeinträchtigen.\nZweitens: Bauen Sie eine schwebende Plattform nach dem Konzept von Gregor Hohpe. Integrieren Sie Tools und Cloud-Anbieter, aber abstrahieren Sie sie niemals weg. Duplizieren Sie keine Features. Wenn Sie das tun, beginnt Ihre Plattform unter ihrem eigenen Gewicht zu sinken. Eine schwebende Plattform sitzt über den Tools und macht sie auf kontrollierte, strukturierte Weise zugänglich.\nUnd ein wichtiger Punkt: KI ist kein separates Thema. Sie ist eine Fähigkeit der Plattform. Wenn man eine solche Plattform hat, sind KI- und ML-Fähigkeiten kontrolliert, standardisiert und unternehmensweit verfügbar. Ohne das nutzt jeder einfach die Tools, die gerade verfügbar sind, unkontrolliert und nicht standardisiert.\nDie Plattform in Aktion # Ich habe die Zühlke Platform Plane demonstriert, die wir gemeinsam mit der LGT aufgebaut haben. Folgendes bietet sie:\nSelf-Service für alles: Repositories erstellen, Anwendungen deployen, Datenbanken bereitstellen, alles ohne Tickets. Single Sign-On: Eine Identität für alle Tools. Morgens einen Entwickler onboarden, abends offboarden. Der Zugang wird zentral verwaltet. Partner-Integration: Externe Unternehmen bringen ihre eigene Identität mit, werden über Microsoft Entra integriert und verwalten ihre Leute selbst. Standardisierte Services: Brauchen Sie eine MySQL-Datenbank, MongoDB oder Kafka? Ein Klick gibt Ihnen eine kontrollierte Instanz mit korrekter Namensgebung, Backups, Logging und Monitoring, bereits fertig konfiguriert. Security by Default: Alle Repositories und Container-Images werden kontinuierlich gescannt. Provenance-Tracking zeigt genau, wer welche Änderung eingeführt hat. KI-gestützte Tools: Dokumentations-Chatbot, Docker-Image-Analyse, Log-Analyse. Wenn alles auf einer Plattform ist, wird das Erstellen von KI-Anwendungsfällen wie Lego spielen. FinOps und Emissionserfassung: Teams sehen ihre Kosten und ihren CO2-Fussabdruck direkt in der Plattform. Pipelines und Runner: Self-hosted Runner, Hochleistungs-Pools und sogar virtuelle Maschinen für Mobile-Entwicklung. API Explorer: Alle OpenAPI-Spezifikationen des Unternehmens an einem Ort. \u0026ldquo;Wenn ein Entwickler eine Anwendung deployt, werden Monitoring, Logging, Dashboards, einfach alles automatisch bereitgestellt. Die kognitive Belastung auf Entwicklerseite sinkt.\u0026rdquo;\nKernaussagen # DevOps ist nicht tot: Es braucht eine Plattform, um in grossem Massstab zu funktionieren. Platform Engineering ist der Enabler, nicht der Ersatz. Bauen Sie ein Self-Service-Portal: Kein Ticket-Ops. Ermöglichen Sie Teams, alles Nötige eigenständig zu erledigen. Die Plattform ist ein internes Produkt: Mit internen Kunden (den Produktteams) und einem dedizierten Platform Team, das sie baut und wartet. Architektur für Wandel: Nutzen Sie Adapter und das Floating-Platform-Konzept, um flexibel zu bleiben. KI ist eine Plattform-Fähigkeit: Kontrollieren Sie sie, standardisieren Sie sie und bieten Sie sie über die Plattform an, anstatt jeden seinen eigenen Weg gehen zu lassen. Developer Experience zählt: Wenn Entwickler Monitoring, Security und Infrastruktur out-of-the-box erhalten, können sie sich auf das konzentrieren, was tatsächlich Business Value schafft. Platform Engineering ist das Fundament der Digital Factory: Es ermöglicht Teams, DevOps zu praktizieren und kontinuierlich Wert zu liefern. Wir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein. ","date":"23. September 2024","externalUrl":null,"permalink":"/de/blogs/developer-experience-und-platform-engineering/","section":"Blogs","summary":"Ist DevOps tot? Diese Behauptung taucht immer wieder im Internet auf, mit dem Argument, dass Platform Engineering übernimmt. In diesem Vortrag, den ich an der Developer Experience Conference bei Roche in Poznan, Polen, gehalten habe, erkläre ich, warum DevOps absolut nicht tot ist und warum Platform Engineering der Schlüssel ist, um DevOps in grossem Massstab zum Funktionieren zu bringen.\n","title":"Developer Experience und Platform Engineering: Das Fundament moderner Softwareentwicklung","type":"blogs"},{"content":"","date":"23 September 2024","externalUrl":null,"permalink":"/en/tags/self-service/","section":"Tags","summary":"","title":"Self-Service","type":"tags"},{"content":"When the CEO or CIO comes to you and says \u0026ldquo;We need AI in our development process,\u0026rdquo; the right response is not to start implementing immediately. The right response is to ask: why? In this talk at Conf42 Platform Engineering, I walk through the complete journey from identifying value stream bottlenecks to implementing AI-augmented DevOps on a real platform, including a live demo.\nStart with the Value Stream, Not with AI # When management asks for AI, the real goals behind that request are usually: faster time to market, more value for money, and higher quality. These are legitimate goals. But to achieve them, you first need to understand your value stream.\nValue stream mapping is the essential starting point. Bring all the people working across a value stream into a room, lay out every step from idea to production, identify who is responsible for each step, and measure three things: lead time (total elapsed time), process time (actual value-adding work), and percentage complete and accurate (quality of output).\nWhen you have this picture, bottlenecks become immediately visible. For example, a testing step might show 8 hours of actual work but 336 hours of lead time, and a 50% quality rate meaning half the work needs to be redone. These are the spots where improvement will have the biggest impact.\nNot everything needs to be solved with AI. Sometimes it is far better to just improve the process or rethink it entirely.\nWhere AI Can Help Across the DevOps Lifecycle # Once you have identified genuine bottlenecks, AI can be applied strategically across the entire DevOps lifecycle:\nPlan: Analyze historic project data, predict risks, resource needs, and delivery timelines Code: Generate, refactor, debug, and explain code with copilots Build: Auto-remediate security vulnerabilities Test: Impact analysis of changes and intelligent test selection Deploy: Predict deployment impact, monitor health, auto-trigger rollbacks Release: Continuous release verification and impact analysis Operate: Detect and fix configuration drift automatically Monitor: Pattern recognition, anomaly detection, event correlation, root cause analysis, and self-healing (this is often called AIOps) These are powerful capabilities, but they all require the right foundation.\nPlatform Engineering: The Foundation for AI at Scale # Without standardization, AI-augmented DevOps does not scale. When every team has its own local development environment and its own tool landscape, there is no consistent foundation to build on.\nPlatform engineering solves this. You create one platform where tools and capabilities are standardized. The target operating model has two types of teams: product teams that are smaller and focused, and a platform team that provides self-service capabilities through an internal developer platform.\nThe architectural principle I always emphasize is to build a floating platform. This means you plug in services and tools (GitHub, GitLab, Kubernetes, cloud providers) and provide a developer experience layer on top. You never duplicate features from the tools below. You integrate them through adapters so they can be swapped when needed. If you start hiding, abstracting, or duplicating features, your platform will sink.\nAI as a Platform Capability # In the platform architecture, AI is just another capability, but a powerful one. When you zoom into that AI capability, the layers look like this:\nDeveloper Portal and APIs at the top, exposing AI services to product teams Application Layer with chatbots, AI coding assistants, and knowledge management Tooling Layer with prompt engineering, RAG systems, and vector databases Model Layer with a model hub, enterprise-specific models, and fine-tuned configurations Infrastructure Layer integrating Gen AI APIs from cloud providers Live Demo: AI in Action on a Real Platform # During the talk, I demonstrated the platform we built together with LGT, a bank in Liechtenstein. The platform, called Zühlke Plane, is used both internally at Zühlke and by LGT with their own instance. Here are some of the AI features in production:\nAI Chat: A ChatGPT-like interface deployed at Zühlke in a standardized, governed way. Employees do not need to know which LLM is running behind it, and the underlying service can be replaced transparently.\nContainer Image Analysis: Developers can view container image layers and click a button to get an AI analysis. The LLM is optimized for container image analysis and provides actionable insights. The feedback from developers has been extremely positive.\nLog File Analysis: With all logs flowing through the platform, developers can analyze entire Kubernetes namespaces using AI. The system examines log patterns and provides structured insights, saving significant time in troubleshooting.\nSelf-Service AI Capabilities: Product teams can add Azure OpenAI or a full LLM platform to their applications through the service catalog. Teams have built applications like a project reference finder and a bidding process optimizer using specialized AI agents with custom system prompts. These were built in minimal time because the platform provided all the infrastructure.\nThe Floating Platform Principle # One of the most important lessons from this work: the platform must float. It must sit on top of all the tools and cloud providers without trying to replace them. When tools release new features, you benefit automatically. When you need to swap a tool (for example, replacing GitLab with GitHub), the adapter pattern makes this possible without disrupting the platform.\nThe moment you abstract away or duplicate a feature from the underlying tools, your platform starts to sink. This is the single biggest architectural mistake I see in platform engineering.\nKey Takeaways # Start with value stream mapping, not with AI. Understand your bottlenecks before reaching for technology solutions. AI is not always the answer. Sometimes process improvement is simpler and more effective. Platform engineering is the foundation for AI-augmented DevOps at scale. Without standardization, nothing scales. Build a floating platform. Integrate tools through adapters, never duplicate their features. AI is a platform capability. Provide it as a self-service to product teams so they can build their own use cases. Enable the business, not just engineering. The platform\u0026rsquo;s AI capabilities can power business applications like reference finders and process optimizers, not just developer tools. We are entering the age of industrialized software development. Platform teams build the platform that enables development teams to do AI-augmented DevOps, and that also enables the business to innovate with AI.\n","date":"19 September 2024","externalUrl":null,"permalink":"/en/blogs/ai-augmented-devops-with-platform-engineering/","section":"Blogs","summary":"When the CEO or CIO comes to you and says “We need AI in our development process,” the right response is not to start implementing immediately. The right response is to ask: why? In this talk at Conf42 Platform Engineering, I walk through the complete journey from identifying value stream bottlenecks to implementing AI-augmented DevOps on a real platform, including a live demo.\n","title":"AI-Augmented DevOps with Platform Engineering","type":"blogs"},{"content":"Wenn der CEO oder CIO kommt und sagt \u0026ldquo;Wir brauchen KI in unserem Entwicklungsprozess,\u0026rdquo; ist die richtige Reaktion nicht, sofort loszulegen. Die richtige Reaktion ist zu fragen: Warum? In diesem Vortrag an der Conf42 Platform Engineering zeige ich den kompletten Weg: von der Identifikation von Value-Stream-Engpässen bis zur Implementierung von KI-augmentiertem DevOps auf einer echten Plattform, inklusive Live-Demo.\nMit dem Value Stream beginnen, nicht mit KI # Wenn das Management KI fordert, sind die eigentlichen Ziele dahinter meist: schnellere Time to Market, mehr Wert für das Geld und höhere Qualität. Das sind legitime Ziele. Aber um sie zu erreichen, muss man zuerst seinen Value Stream verstehen.\nValue Stream Mapping ist der essentielle Startpunkt. Man bringt alle Personen, die über einen Value Stream hinweg arbeiten, in einen Raum, legt jeden Schritt von der Idee bis zur Produktion auf, identifiziert, wer für jeden Schritt verantwortlich ist, und misst drei Dinge: Lead Time (verstrichene Gesamtzeit), Process Time (tatsächliche wertschöpfende Arbeit) und Percentage Complete and Accurate (Qualität des Outputs).\nWenn man dieses Bild hat, werden Engpässe sofort sichtbar. Zum Beispiel könnte ein Test-Schritt 8 Stunden tatsächliche Arbeit zeigen, aber 336 Stunden Lead Time, und eine 50%-Qualitätsrate, was bedeutet, dass die Hälfte der Arbeit wiederholt werden muss. Das sind die Stellen, an denen Verbesserungen die grösste Wirkung haben.\nNicht alles muss mit KI gelöst werden. Manchmal ist es viel besser, einfach den Prozess zu verbessern oder komplett neu zu denken.\nWo KI im DevOps-Lebenszyklus helfen kann # Sobald man echte Engpässe identifiziert hat, kann KI strategisch über den gesamten DevOps-Lebenszyklus eingesetzt werden:\nPlan: Historische Projektdaten analysieren, Risiken, Ressourcenbedarf und Liefertermine vorhersagen Code: Code generieren, refactoren, debuggen und erklären mit Copilots Build: Sicherheitslücken automatisch beheben Test: Impact-Analyse von Änderungen und intelligente Testauswahl Deploy: Auswirkungen des Deployments vorhersagen, Gesundheit überwachen, automatische Rollbacks auslösen Release: Kontinuierliche Release-Verifizierung und Impact-Analyse Operate: Konfigurationsabweichungen automatisch erkennen und beheben Monitor: Mustererkennung, Anomalie-Erkennung, Event-Korrelation, Root-Cause-Analyse und Self-Healing (oft als AIOps bezeichnet) Das sind mächtige Fähigkeiten, aber sie alle brauchen die richtige Grundlage.\nPlatform Engineering: Die Grundlage für KI im grossen Massstab # Ohne Standardisierung skaliert KI-augmentiertes DevOps nicht. Wenn jedes Team seine eigene lokale Entwicklungsumgebung und seine eigene Tool-Landschaft hat, gibt es keine konsistente Grundlage zum Aufbauen.\nPlatform Engineering löst dieses Problem. Man schafft eine Plattform, auf der Tools und Fähigkeiten standardisiert sind. Das Zielbetriebsmodell hat zwei Typen von Teams: Produkt-Teams, die kleiner und fokussierter sind, und ein Platform-Team, das Self-Service-Fähigkeiten über eine interne Developer-Plattform bereitstellt.\nDas architektonische Prinzip, das ich immer betone, ist eine Floating Platform zu bauen. Das bedeutet: Services und Tools (GitHub, GitLab, Kubernetes, Cloud-Anbieter) einstecken und eine Developer-Experience-Schicht darüber bereitstellen. Niemals Features der darunterliegenden Tools duplizieren. Sie über Adapter integrieren, damit sie bei Bedarf ausgetauscht werden können. Sobald man anfängt, Features zu verstecken, zu abstrahieren oder zu duplizieren, beginnt die Plattform zu sinken.\nKI als Plattform-Fähigkeit # In der Plattformarchitektur ist KI einfach eine weitere Fähigkeit, aber eine mächtige. Wenn man in diese KI-Fähigkeit hineinzoomt, sehen die Schichten so aus:\nDeveloper Portal und APIs oben, die KI-Services für Produkt-Teams bereitstellen Anwendungsschicht mit Chatbots, KI-Coding-Assistenten und Wissensmanagement Tooling-Schicht mit Prompt Engineering, RAG-Systemen und Vektor-Datenbanken Modell-Schicht mit einem Model Hub, unternehmensspezifischen Modellen und feinjustierten Konfigurationen Infrastrukturschicht mit Integration der Gen-KI-APIs der Cloud-Anbieter Live-Demo: KI in Aktion auf einer echten Plattform # Im Vortrag demonstrierte ich die Plattform, die wir zusammen mit LGT gebaut haben, einer Bank in Liechtenstein. Die Plattform namens Zühlke Plane wird sowohl intern bei Zühlke als auch von LGT mit einer eigenen Instanz genutzt. Hier einige der KI-Features in Produktion:\nKI-Chat: Eine ChatGPT-ähnliche Oberfläche, die bei Zühlke standardisiert und gouverniert ausgerollt wurde. Mitarbeitende müssen nicht wissen, welches LLM dahinter läuft, und der zugrundeliegende Service kann transparent ausgetauscht werden.\nContainer-Image-Analyse: Entwickler können Container-Image-Schichten einsehen und per Knopfdruck eine KI-Analyse erhalten. Das LLM ist für Container-Image-Analyse optimiert und liefert handlungsrelevante Einblicke. Das Feedback der Entwickler war äusserst positiv.\nLog-Analyse: Da alle Logs durch die Plattform fliessen, können Entwickler ganze Kubernetes-Namespaces mittels KI analysieren. Das System untersucht Log-Muster und liefert strukturierte Einblicke, was erheblich Zeit bei der Fehlersuche spart.\nSelf-Service-KI-Fähigkeiten: Produkt-Teams können Azure OpenAI oder eine vollständige LLM-Plattform über den Service-Katalog ihren Applikationen hinzufügen. Teams haben Anwendungen wie einen Projektreferenz-Finder und einen Angebotsoptimierungsprozess mit spezialisierten KI-Agenten und massgeschneiderten System-Prompts gebaut. Diese wurden in kürzester Zeit erstellt, weil die Plattform die gesamte Infrastruktur bereitstellte.\nDas Floating-Platform-Prinzip # Eine der wichtigsten Lektionen aus dieser Arbeit: Die Plattform muss schwimmen. Sie muss auf allen Tools und Cloud-Anbietern aufliegen, ohne zu versuchen, sie zu ersetzen. Wenn Tools neue Features veröffentlichen, profitiert man automatisch. Wenn man ein Tool austauschen muss (zum Beispiel GitLab durch GitHub ersetzen), macht das Adapter-Pattern dies möglich, ohne die Plattform zu stören.\nIn dem Moment, in dem man ein Feature der darunterliegenden Tools abstrahiert oder dupliziert, beginnt die Plattform zu sinken. Das ist der grösste architektonische Fehler, den ich im Platform Engineering sehe.\nKernaussagen # Mit Value Stream Mapping beginnen, nicht mit KI. Die Engpässe verstehen, bevor man nach Technologielösungen greift. KI ist nicht immer die Antwort. Manchmal ist Prozessverbesserung einfacher und wirkungsvoller. Platform Engineering ist die Grundlage für KI-augmentiertes DevOps im grossen Massstab. Ohne Standardisierung skaliert nichts. Eine Floating Platform bauen. Tools über Adapter integrieren, niemals ihre Features duplizieren. KI ist eine Plattform-Fähigkeit. Sie als Self-Service den Produkt-Teams bereitstellen, damit diese ihre eigenen Anwendungsfälle bauen können. Das Business befähigen, nicht nur das Engineering. Die KI-Fähigkeiten der Plattform können Business-Anwendungen wie Referenzfinder und Prozessoptimierer antreiben, nicht nur Entwickler-Tools. Wir betreten das Zeitalter der industrialisierten Softwareentwicklung. Platform-Teams bauen die Plattform, die Entwicklungsteams KI-augmentiertes DevOps ermöglicht, und die gleichzeitig dem Business ermöglicht, mit KI zu innovieren.\n","date":"19. September 2024","externalUrl":null,"permalink":"/de/blogs/ki-augmentiertes-devops-mit-platform-engineering/","section":"Blogs","summary":"Wenn der CEO oder CIO kommt und sagt “Wir brauchen KI in unserem Entwicklungsprozess,” ist die richtige Reaktion nicht, sofort loszulegen. Die richtige Reaktion ist zu fragen: Warum? In diesem Vortrag an der Conf42 Platform Engineering zeige ich den kompletten Weg: von der Identifikation von Value-Stream-Engpässen bis zur Implementierung von KI-augmentiertem DevOps auf einer echten Plattform, inklusive Live-Demo.\n","title":"KI-augmentiertes DevOps mit Platform Engineering","type":"blogs"},{"content":"","date":"5 August 2024","externalUrl":null,"permalink":"/en/tags/data-science/","section":"Tags","summary":"","title":"Data Science","type":"tags"},{"content":"Haben Sie sich jemals gefragt, wie Unternehmen diese beeindruckenden KI-Anwendungen bauen und zuverlässig in Produktion betreiben? In diesem Video tauche ich tief in MLOps ein, die Disziplin, die es ermöglicht, Machine-Learning-Lösungen auf Unternehmensebene kontinuierlich zu entwickeln, bereitzustellen und zu verbessern.\nDie KI-Landschaft verstehen # Bevor wir in MLOps eintauchen, ist es entscheidend, die Begriffe zu verstehen. KI ist der grosse Überbegriff: Programme mit der Fähigkeit, wie Menschen zu lernen und zu schlussfolgern. Machine Learning ist eine Unterkategorie, in der Algorithmen lernen, ohne explizit programmiert zu werden. Deep Learning nutzt neuronale Netzwerke, die aus massiven Datenmengen lernen. Und Generative KI, die Technologie hinter den aktuell angesagten Tools, ist eine weitere Unterkategorie, die Modelle mit nahezu dem gesamten Internet trainiert.\nAlle sprechen von \u0026ldquo;KI\u0026rdquo;, aber in den meisten Fällen reden wir tatsächlich über eine sehr spezifische Unterkategorie. Diese Unterscheidungen zu verstehen ist wichtig, weil MLOps einen breiteren Teil der Landschaft abdeckt als nur generative KI.\nEin praktisches Beispiel: Retrieval Augmented Generation # Um die Dinge greifbar zu machen, verwende ich im gesamten Video einen Retrieval Augmented Generation (RAG) Anwendungsfall. Das Szenario: Ein Unternehmen hat viele Compliance-Regeln, Governance-Dokumente und internes Wissen. Sie möchten einen Chatbot, der Fragen präzise auf Basis dieser Dokumente beantworten kann.\nDie Architektur ist einfach. Alle Dokumente werden in eine Vektordatenbank geladen. Wenn ein Benutzer eine Frage stellt, wird die Datenbank nach relevanten Dokumenten durchsucht, diese werden als Kontext an ein LLM übergeben, und man erhält eine präzise Antwort. Im Konzept einfach, aber die wahre Herausforderung beginnt, wenn man das in Produktion bringen, Feedback sammeln, das Modell kontinuierlich verbessern und für die gesamte Organisation skalieren muss.\nDer MLOps-Lifecycle: In Zyklen denken, nicht linear # Der wichtigste Perspektivwechsel: Weg vom linearen Denken, hin zum zyklischen. Der MLOps-Lifecycle hat vier Kernphasen:\nEntwicklung: Neue Ideen sammeln und Anwendungsfälle lokal entwickeln. Training: Das Modelltraining operationalisieren, sodass es automatisch läuft, zum Beispiel nächtlich, mit kontinuierlich verbesserten Daten. Deployment: Modelle in zugängliche, skalierbare Umgebungen deployen. Wenn sich ein Anwendungsfall bewährt, muss man schnell skalieren können. Monitoring: Kontinuierlich verfolgen, wie Benutzer mit dem Modell interagieren, welche Anfragen eingehen und wie das Modell performt. Diese Daten fliessen zurück ins Retraining. \u0026ldquo;Tatsächlicher Business-Value entsteht erst, wenn etwas in Produktion ist. Nein, wir werden nicht Ihre Maschine an die Benutzer ausliefern.\u0026rdquo;\nMLOps, LLMOps, DevOps: Im Kern identisch # Eine Erkenntnis, die viele überrascht: Die Definitionen von MLOps und LLMOps sind im Wesentlichen identisch. Beide zielen darauf ab, die End-to-End-Entwicklung, das Testen, die Validierung, das Deployment und das Monitoring von Modellen zu optimieren. Es gibt Nuancen, aber im Kern teilen sie die gleiche DNA mit DevOps. Es geht immer darum, Menschen, Prozesse und Technologie zusammenzubringen, um kontinuierlich Wert zu liefern.\nDer Begriff \u0026ldquo;MLOps\u0026rdquo; betrifft nicht nur Data Scientists und Operations. Er umfasst alle, die entlang des Wertstroms arbeiten: Entwickler, Architekten, Security-Experten, Business-Stakeholder und mehr.\nDer Business Case für MLOps # Aus geschäftlicher Perspektive liefert MLOps vier zentrale Vorteile:\nSchnellere Time-to-Market: Modelle schneller in Produktion bringen und früher Wert liefern. Schnellere Experimente: Standardisierte Prozesse bedeuten, dass man vom Proof of Concept viel schneller zur Produktion kommt. Die klassische Falle, dass ein PoC auf dem Laptop funktioniert, aber in Produktion scheitert, wird vermieden. Operative Effizienz: Die richtigen Fähigkeiten machen es einfacher, Modelle in Produktion zu deployen, zu aktualisieren und zu betreiben. Reproduzierbarkeit und Compliance: Besonders in regulierten Umgebungen braucht man die vollständige Nachverfolgbarkeit: Welches Modell, trainiert mit welchen Daten, hat welche Antwort produziert? Essentielle MLOps-Fähigkeiten # Um diese Vorteile zu realisieren, braucht man spezifische Fähigkeiten:\nExperimentierumgebungen: Skalierbare, erweiterbare Räume, in denen Data Scientists Ad-hoc-Experimente durchführen können. Experiment-Tracking: Die Fähigkeit, Experimente zu vergleichen, Eingaben nachzuverfolgen und die Modell-Performance zu bewerten. Daten- und ML-Pipelines: Automatisierte Pipelines, die Modelle auf reproduzierbare Weise generieren. Model Registry: Ein zentraler Ort, um Modelle zu versionieren und Metadaten über deren Training zu speichern. Serving-Umgebung: Wo Modelle deployt und für Konsumenten verfügbar gemacht werden. Observability: Logging und Monitoring, um zu verstehen, wie Modelle genutzt werden und wie sie performen. Fundament: Versionskontrolle, CI/CD, Plattformen, Automatisierung und Zugriffskontrolle. Das MLOps-Reifegradmodell # Organisationen durchlaufen typischerweise vier Reifegrade:\nLevel 0 (Ad-hoc): Individuelle, manuelle, lokale Entwicklung. Keine Nachverfolgbarkeit. Schwer, etwas in Produktion zu bringen. Level 1 (Aufkeimend): ML-Pipelines mit erster Automatisierung und Standardisierung. Erste Nachverfolgbarkeit. Level 2 (Operativ): Vollständige CI/CD-Pipelines, Monitoring, Skalierbarkeit. Fähigkeit, robuste, skalierbare KI-Anwendungen zu bauen. Level 3 (Strategisch): Eine zentralisierte, standardisierte, unternehmensweite Plattform, die alle MLOps-Fähigkeiten in kontrollierter Weise bereitstellt. Die Plattform: Wo alles zusammenkommt # Auf der strategischen Ebene braucht man eine Plattform, die ML-Anwendungsfälle unterstützt. Diese Plattform bietet alle benötigten Werkzeuge und Fähigkeiten: Application Runtime, Serving-Umgebungen, Observability, Identity und Access Management, CI/CD und dedizierte KI/ML-Capabilities.\nWenn man in die KI/ML-Capability-Box hineinzoomt, ist sie keineswegs klein. Sie umfasst:\nPlattform-Interfaces: Portal, CLI und APIs Anwendungen: Chatbots, Werkzeuge für synthetische Daten, KI-Coding-Assistenten, Produktivitätstools Werkzeuge: Prompt Engineering, Vektordatenbanken, RAG, Fine-Tuning-Lösungen Model Lifecycle Management: MLOps-Tooling im Zentrum Model Hub: Registry für selbst trainierte Modelle und LLMs mit vollständiger Versionierung Infrastruktur: Compute, Storage, Netzwerk plus Schnittstellen zu OpenAI, AWS, Google Cloud und Azure Ich habe dies mit der Zühlke Platform Plane demonstriert, die wir gemeinsam mit LGT aufgebaut haben. KI-Anwendungsfälle auf dieser Plattform zu bauen, ist wie Lego spielen: Man steckt Vektordatenbanken, LLM-APIs und Monitoring-Tools zusammen und erstellt in kürzester Zeit Anwendungsfälle wie Dokumentationsassistenten, Referenzfinder oder Unternehmensanalyse-Tools.\n\u0026ldquo;Wenn man eine solche Plattform hat, sind alle Daten auf dieser Plattform. Man hat die Logdateien, die CI/CD-Pipelines, alle Fähigkeiten direkt griffbereit, und das ermöglicht, viel schneller in der Entwicklung zu sein.\u0026rdquo;\nKernaussagen # MLOps, LLMOps und DevOps teilen den gleichen Kern: Es geht immer darum, Menschen, Prozesse und Technologie zusammenzubringen, um kontinuierlich Wert zu liefern. In Zyklen denken, nicht linear: Der MLOps-Lifecycle ist kontinuierlich: Entwickeln, Trainieren, Deployen, Monitoren, Retrainieren. Nicht auf dem Laptop bleiben: Echter Wert entsteht in Produktion. Operationalisieren Sie Ihre Modelle von Tag eins an. Die Tool-Landschaft ist riesig: Ohne Standardisierung endet man in einem heterogenen Durcheinander. Wählen Sie einen gemeinsamen ML-Stack vorab aus. Eine Plattformstrategie ist der strategische Hebel: Auf Reifegrad 3 verschafft eine zentralisierte Plattform mit kontrollierten KI/ML-Fähigkeiten einen massiven Wettbewerbsvorteil. Eine Plattform macht KI-Anwendungsfälle einfach: Wenn alles integriert ist, wird der Bau neuer KI-Anwendungen schnell und unkompliziert. Monitoring ist unverzichtbar: Besonders bei ML muss man verfolgen, was hineingeht, was herauskommt und wie das Modell performt, um kontinuierlich zu verbessern. ","date":"5. August 2024","externalUrl":null,"permalink":"/de/blogs/die-kraft-von-ki-entfesseln-ein-deep-dive-in-mlops/","section":"Blogs","summary":"Haben Sie sich jemals gefragt, wie Unternehmen diese beeindruckenden KI-Anwendungen bauen und zuverlässig in Produktion betreiben? In diesem Video tauche ich tief in MLOps ein, die Disziplin, die es ermöglicht, Machine-Learning-Lösungen auf Unternehmensebene kontinuierlich zu entwickeln, bereitzustellen und zu verbessern.\n","title":"Die Kraft von KI entfesseln: Ein Deep Dive in MLOps, Machine Learning und KI-Plattformen","type":"blogs"},{"content":"","date":"5 August 2024","externalUrl":null,"permalink":"/en/tags/generative-ai/","section":"Tags","summary":"","title":"Generative AI","type":"tags"},{"content":"","date":"5. August 2024","externalUrl":null,"permalink":"/de/tags/generative-ki/","section":"Tags","summary":"","title":"Generative KI","type":"tags"},{"content":"","date":"5 August 2024","externalUrl":null,"permalink":"/en/tags/llm/","section":"Tags","summary":"","title":"LLM","type":"tags"},{"content":"","date":"5 August 2024","externalUrl":null,"permalink":"/en/tags/machine-learning/","section":"Tags","summary":"","title":"Machine Learning","type":"tags"},{"content":"","date":"5 August 2024","externalUrl":null,"permalink":"/en/tags/mlops/","section":"Tags","summary":"","title":"MLOps","type":"tags"},{"content":"Have you ever wondered how companies build those impressive AI applications and keep them running reliably in production? In this video, I take a deep dive into MLOps, the discipline that makes it possible to continuously develop, deploy, and improve machine learning solutions at enterprise scale.\nUnderstanding the AI landscape # Before diving into MLOps, it is crucial to understand the terminology. AI is the big umbrella: programs with the ability to learn and reason like humans. Machine Learning is a subset where algorithms learn without being explicitly programmed. Deep Learning uses neural networks that learn from massive amounts of data. And Generative AI, the technology behind today\u0026rsquo;s trending tools, is a further subset that trains models on nearly the entire internet.\nEveryone talks about \u0026ldquo;AI,\u0026rdquo; but in most cases we are actually talking about a very specific subset. Understanding these distinctions matters because MLOps covers a broader part of the landscape than just generative AI.\nA practical example: Retrieval Augmented Generation # To make things tangible, I use a Retrieval Augmented Generation (RAG) use case throughout the video. The scenario: a company has many compliance rules, governance documents, and internal knowledge. They want a chatbot that can answer questions accurately based on these documents.\nThe architecture is straightforward. You load all documents into a vector database. When a user asks a question, you search the database for relevant documents, pass them as context to an LLM, and get a precise answer. Simple in concept, but the real challenge begins when you need to deploy this into production, gather feedback, continuously improve the model, and scale it for the entire organisation.\nThe MLOps lifecycle: think in cycles, not lines # The most important shift in thinking is to move from linear processes to cycles. The MLOps lifecycle has four key phases:\nDevelopment: Gather new ideas and develop use cases locally. Training: Operationalise model training so it runs automatically, for example on a nightly basis, with continuously improving data. Deployment: Deploy models to accessible, scalable environments. When a use case proves its value, you need to scale fast. Monitoring: Continuously track how users interact with your model, what queries come in, and how the model performs. This data feeds back into retraining. \u0026ldquo;Actual value or business value is only generated when something is in production. No, we are not going to ship your machine to the users.\u0026rdquo;\nMLOps, LLMOps, DevOps: all the same at heart # Here is something that surprises many people: the definitions of MLOps and LLMOps are essentially identical. Both aim to streamline the end-to-end development, testing, validation, deployment, and monitoring of models. There are nuances, but at their core, they share the same DNA with DevOps. It is all about bringing people, process, and technology together to continuously deliver value.\nThe term \u0026ldquo;MLOps\u0026rdquo; is not just about data scientists and operations. It involves everyone across the value stream: developers, architects, security experts, business stakeholders, and more.\nThe business case for MLOps # From a business perspective, MLOps delivers four key benefits:\nFaster time to market: Bring models into production faster and deliver value sooner. Faster experimentation: Standardised processes mean you can move from proof of concept to production much more quickly, avoiding the classic trap where a PoC works on a laptop but fails in production. Operational efficiency: Having the right capabilities makes it easier to deploy, update, and operate models in production. Reproducibility and compliance: Especially in regulated environments, you need full traceability of which model, trained on which data, produced which answer. Essential MLOps capabilities # To achieve these benefits, you need a specific set of capabilities:\nExperimentation environments: Scalable, extensible spaces where data scientists can run ad-hoc experiments. Experiment tracking: The ability to compare experiments, track inputs, and evaluate model performance. Data and ML pipelines: Automated pipelines that regenerate models in a reproducible way. Model registry: A central place to version models and store metadata about how they were trained. Serving environment: Where models are deployed and made available to consumers. Observability: Logging and monitoring to understand how models are used and how they perform. Foundation: Version control, CI/CD, platforms, automation, and access control. The MLOps maturity model # Organisations typically progress through four maturity levels:\nLevel 0 (Ad-hoc): Individual, manual, local development. No traceability. Hard to get anything into production. Level 1 (Emerging): ML pipelines with some automation and standardisation. First traceability. Level 2 (Operational): Full CI/CD pipelines, monitoring, scalability. Ability to build robust, scalable AI applications. Level 3 (Strategic): A centralised, standardised, company-wide platform that provides all MLOps capabilities in a governed way. The platform: where it all comes together # At the strategic level, you need a platform that supports ML use cases. This platform offers all the tools and capabilities needed: application runtime, serving environments, observability, identity and access management, CI/CD, and dedicated AI/ML capabilities.\nWhen you zoom into that AI/ML capability box, it is not small at all. It includes:\nPlatform interfaces: Portal, CLI, and APIs Applications: Chatbots, synthetic data tools, AI coding assistants, productivity tools Tools: Prompt engineering, vector databases, RAG, fine-tuning solutions Model lifecycle management: MLOps tooling at the centre Model hub: Registry for self-trained models and large language models with full versioning Infrastructure: Compute, storage, network, plus interfaces to OpenAI, AWS, Google Cloud, and Azure I demonstrated this with the Zühlke Platform Plane, which we built together with LGT. Building AI use cases on this platform is like playing Lego: you plug together vector databases, LLM APIs, and monitoring tools to create use cases like documentation assistants, reference finders, or company analysers in no time.\n\u0026ldquo;When you have such a platform, all of the data is in that platform. You have the log files, the CI/CD pipelines, all of the capabilities at your fingertips, and this enables you to be much faster in development.\u0026rdquo;\nKey takeaways # MLOps, LLMOps, and DevOps share the same core: It is all about bringing people, process, and technology together to continuously deliver value. Think in cycles, not lines: The MLOps lifecycle is continuous: develop, train, deploy, monitor, retrain. Don\u0026rsquo;t stay on the laptop: Real value comes from production. Operationalise your models from day one. The tool landscape is massive: Without standardisation, you end up with a heterogeneous mess. Pre-select a common ML stack. A platform strategy is the strategic lever: At maturity level 3, a centralised platform with governed AI/ML capabilities gives you a massive competitive advantage. Having a platform makes AI use cases easy: When everything is integrated, building new AI applications becomes fast and straightforward. Monitoring is essential: Especially in ML, you need to track what goes in, what comes out, and how the model performs to continuously improve. ","date":"5 August 2024","externalUrl":null,"permalink":"/en/blogs/unlocking-the-power-of-ai-deep-dive-into-mlops/","section":"Blogs","summary":"Have you ever wondered how companies build those impressive AI applications and keep them running reliably in production? In this video, I take a deep dive into MLOps, the discipline that makes it possible to continuously develop, deploy, and improve machine learning solutions at enterprise scale.\n","title":"Unlocking the Power of AI: Deep Dive into MLOps, Machine Learning, and AI Platforms","type":"blogs"},{"content":"Enterprise Architektur ist ein grosses Wort, das schwer in der Luft liegt. Was bedeutet es tatsächlich für Ihre Organisation, und wie passt KI ins Bild? In diesem Vortrag, den ich an der HSLU (Hochschule Luzern) in Zusammenarbeit mit der Digital Veterans Association gehalten habe, zeige ich, wie Enterprise Architektur, Platform Engineering und KI als strategischer Hebel für moderne Organisationen zusammenwirken.\nWas ist Enterprise Architektur? # Zunächst, was es nicht ist: Es hat nichts mit dem Raumschiff Enterprise oder Star Wars zu tun. Enterprise Architektur bedeutet, einen ganzheitlichen Blick auf eine Organisation zu werfen. Gartner definiert es als eine Disziplin, die proaktiv und ganzheitlich die Reaktion eines Unternehmens auf disruptive Kräfte steuert, indem sie die Umsetzung von Veränderungen hin zu einer gewünschten Geschäftsvision und gewünschten Ergebnissen identifiziert und analysiert.\nIch visualisiere Enterprise Architektur als Schichtenmodell. An der Spitze steht die Unternehmensvision, die in eine Geschäftsstrategie überführt wird, dann in eine Geschäftsarchitektur. Die Geschäftsarchitektur verbindet sich über Geschäftsservices mit der Anwendungsarchitektur. Darunter liegt die technische Architektur, unterstützt von Methoden, Fähigkeiten, Werkzeugen, Prozessen und Organisationskultur.\nNehmen wir eine Schweizer Bank als Beispiel. Die Bank hat eine Vision und Geschäftsstrategie. Sie bietet Geschäftsservices über ein E-Banking-System an. Dahinter steht die Anwendungsarchitektur (die E-Banking-Software), und darunter die technische Architektur (das Kernbankensystem und die Backends). Dieser geschichtete Blick über das gesamte Unternehmen ist das, was Enterprise Architektur liefert.\nGregor Hohpe formuliert es wunderbar und prägnant:\n\u0026ldquo;Enterprise Architektur ist der Klebstoff zwischen Business- und IT-Architektur.\u0026rdquo;\nDer Enterprise Architect: Vom Elfenbeinturm zur Werkshalle # Das Stereotyp eines Enterprise Architects, der in seinem Elfenbeinturm sitzt und hübsche Diagramme zeichnet, die niemanden interessieren, ist leider noch immer verbreitet. Aber so sollte es nicht funktionieren.\nEin effektiver Enterprise Architect fährt den Architektur-Aufzug, ein Konzept von Gregor Hohpe. Man geht nach oben zum C-Level, um über Geschäftsstrategie, Vision und IT-Strategie zu sprechen. Dann geht man ganz nach unten in die Werkshalle, um mit den Leuten zu arbeiten, die tatsächlich Dinge bauen. Diese ständige Bewegung zwischen strategischer Vision und operativer Realität macht Enterprise Architektur effektiv.\nDie Kernverantwortungen: Die Geschäftsstrategie verstehen, sie gemeinsam mit dem CIO in eine IT-Strategie überführen, das \u0026ldquo;Ist-Bild\u0026rdquo; erstellen (welche Fähigkeiten und Anwendungen existieren heute), das \u0026ldquo;Soll-Bild\u0026rdquo; definieren (wie die Zukunft aussehen soll) und eine Roadmap bauen, um dorthin zu gelangen.\nEnterprise Architektur ist ein kontinuierlicher Prozess, kein Projekt # Hier kommt ein kritischer Punkt: Mehr als 66 % der Enterprise-Architektur-Initiativen scheitern. Ein wahrscheinlicher Grund ist das Wort \u0026ldquo;Initiative\u0026rdquo;. Es klingt nach einem Projekt mit Start und Ende. Aber Enterprise Architektur endet nie. Es ist ein kontinuierlicher Zyklus.\nMan versteht Vision und Ziele, extrahiert die Geschäftsstrategie, leitet mit dem CIO die IT-Strategie ab, erstellt das Ist-Bild, definiert das Soll-Bild, baut die Roadmap und steuert, verfeinert und coacht dann. Aber dann passiert etwas: Ein globaler Konflikt, eine Pandemie, ein Crowdstrike-Vorfall. Die Geschäftsstrategie passt sich an, die IT-Strategie muss folgen, und die Roadmaps verschieben sich.\nDas ist kein Projekt. Das ist ein kontinuierlicher Prozess, der niemals aufhört. Richtig umgesetzt reduziert Enterprise Architektur Kosten, beschleunigt die Lieferung, senkt Risiken und macht die Organisation agiler.\nDie Digital Factory: Von der Strategie zur Ausführung # Um zu zeigen, wie Enterprise Architektur in der Praxis funktioniert, verwende ich das Beispiel eines Drohnenunternehmens. Der Vorstand hat eine Vision: Von kleinen Drohnen zu einer Produktpalette für höheren Marktanteil expandieren. Sie führen ein Portfolio-Backlog mit priorisierten Ideen. Eine Idee, Drohnen mit hoher Traglast, wird an das Produktmanagement weitergegeben. Produktmanager zerlegen sie in Features: grössere Batterie, bessere Motoren, Software-Updates. Teams beginnen mit der Arbeit.\nDas entscheidende Element: Ein Platform Team stellt standardisierte Entwicklungs- und Delivery-Umgebungen bereit. Neue Teams können in Minuten statt Wochen starten. Nach der Auslieferung fliessen Telemetriedaten zurück zu den Teams für kontinuierliche Verbesserung und zum Vorstand für strategische Investitionsentscheidungen.\nDas ist die Digital Factory: Lean Portfolio Management verbindet Strategie mit Ausführung, Produktmanagement organisiert die Arbeit, Produktteams praktizieren DevOps, und das Platform Team liefert das Fundament.\nPlattformen: Wo Enterprise Architektur greifbar wird # Hier wird es für Enterprise Architects spannend. Das CNCF Platform White Paper beschreibt, wie Plattformen Fähigkeiten bereitstellen: Compute, Netzwerk, Daten, Identity Management, Workloads, Storage und mehr. Darüber sitzt eine Schnittstelle mit Dokumentation, Projektvorlagen, Golden-Path-Templates, grafischer Oberfläche, APIs und CLI.\nDie Schlüsselerkenntnis für Enterprise Architects: Mit einer solchen Plattform kann man seine Richtlinien, Regeln und Policies direkt in die Infrastruktur codifizieren. Entwickler müssen Ihre Governance-Dokumente nicht lesen, weil die Governance bereits in die Plattform eingebaut ist. Wenn ein Entwickler eine Datenbank anfordert, wird sie mit dem richtigen Namensschema, der richtigen Dimensionierung, korrekten Backups, Logging und Monitoring erstellt, mit einem einzigen Klick.\n\u0026ldquo;Mit einer solchen Plattform kann man alle Policies, alle Richtlinien und Regeln codifizieren. Niemand muss sie lesen, weil sie bereits codifiziert und einsatzbereit sind.\u0026rdquo;\nDeshalb sind Plattformen strategisch so wichtig für Enterprise Architektur. Gartner und andere Beratungsunternehmen prognostizieren, dass bis 2027 alle grossen Unternehmen ihre eigenen Plattformen aufbauen werden.\nKI im Bild der Enterprise Architektur # Wo passt KI hin? KI ist eine Fähigkeit der Plattform. Sie sitzt in einer Box der Architektur, aber wenn man hineinzoomt, ist diese Box keineswegs klein.\nSie enthält:\nPlattform-Interfaces: Entwicklerportal, Chatbots, CLI, APIs Anwendungen: Unternehmens-Chatbots, Werkzeuge für synthetische Daten, KI-Coding-Assistenten, Wissensmanagement, Produktivitätsassistenten Werkzeuge: Prompt Engineering, Vektordatenbanken, RAG-Lösungen, Model Lifecycle Management (MLOps) Model Hub: Model Registry mit versionierten Modellen, sowohl selbst trainiert als auch LLMs von Anbietern Infrastruktur: Compute, Storage und Schnittstellen zu AWS, Azure, Google Cloud und OpenAI APIs Ich habe dies mit der Zühlke Platform Plane demonstriert, die wir gemeinsam mit der LGT aufgebaut haben. Auf der Plattform haben wir KI-Anwendungsfälle integriert, die unsere Entwickler lieben: einen Dokumentationsassistenten (ein RAG-Anwendungsfall über die Plattform-Dokumentation), Docker-Image-Analyse mit einem spezialisierten Red Hat LLM und Log-Analyse mit einem dafür optimierten LLM. Jeder dieser Fälle wurde schnell umgesetzt, weil wenn man eine Plattform mit allen Fähigkeiten hat, das Erstellen von KI-Anwendungsfällen wie Lego spielen ist.\nGartner prognostiziert, dass bis 2027 40 % der Plattformen KI in ihren Software-Delivery-Lifecycle integriert haben werden. Wir sind bereits dort.\nKernaussagen # Enterprise Architektur ist der Klebstoff zwischen Business und IT: Sie stellt sicher, dass die IT-Strategie mit der Geschäftsstrategie übereinstimmt. Es ist ein kontinuierlicher Prozess, kein Projekt: Enterprise Architektur hört nie auf. Das geschäftliche Umfeld ändert sich ständig, und die Architektur muss sich anpassen. Der Architektur-Aufzug ist unverzichtbar: Enterprise Architects müssen sich zwischen Vorstandsetage und Werkshalle bewegen. Elfenbeinturm-Architektur scheitert. Plattformen codifizieren Governance: Mit einer Plattform werden Ihre Richtlinien, Regeln und Policies Teil der Infrastruktur. Das ist weit effektiver als Dokumente, die niemand liest. KI ist eine Fähigkeit der Plattform: Sie ist wichtig, aber immer noch eine Fähigkeit unter vielen. Kontrollieren und standardisieren Sie sie über die Plattform. Self-Service ist der Schlüssel: Keine Ticketsysteme. Ermöglichen Sie Teams einen One-Stop-Shop, an dem sie alles haben, was sie brauchen. Enterprise Architektur, Plattformen und KI bilden zusammen einen strategischen Hebel: Das steigert die Leistung, ermöglicht Innovation und positioniert Ihre Organisation, um kontinuierlich Wert zu liefern. ","date":"28. July 2024","externalUrl":null,"permalink":"/de/blogs/enterprise-architektur-und-ki-als-strategischer-hebel/","section":"Blogs","summary":"Enterprise Architektur ist ein grosses Wort, das schwer in der Luft liegt. Was bedeutet es tatsächlich für Ihre Organisation, und wie passt KI ins Bild? In diesem Vortrag, den ich an der HSLU (Hochschule Luzern) in Zusammenarbeit mit der Digital Veterans Association gehalten habe, zeige ich, wie Enterprise Architektur, Platform Engineering und KI als strategischer Hebel für moderne Organisationen zusammenwirken.\n","title":"Die Kraft von Enterprise Architektur und KI für strategischen Nutzen","type":"blogs"},{"content":"","date":"28. July 2024","externalUrl":null,"permalink":"/de/tags/enterprise-architektur/","section":"Tags","summary":"","title":"Enterprise Architektur","type":"tags"},{"content":"Enterprise Architecture is a big word that hangs heavy in the air. What does it actually mean for your organisation, and how does AI fit into the picture? In this talk, which I gave at the HSLU (Lucerne University of Applied Sciences and Arts) in association with the Digital Veterans Association, I explore how Enterprise Architecture, platform engineering, and AI come together as a strategic lever for modern organisations.\nWhat is Enterprise Architecture? # Let me start with what it is not: it has nothing to do with the Starship Enterprise or Star Wars. Enterprise Architecture is about taking a holistic view of an organisation. Gartner defines it as a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business outcomes.\nI visualise Enterprise Architecture as a layered model. At the top sits the Enterprise Vision, which translates into Business Strategy, then Business Architecture. The Business Architecture connects to the Application Architecture through business services. Below that lies the Technical Architecture, supported by methods, skills, tooling, processes, and organisational culture.\nTake a Swiss bank as an example. The bank has a vision and business strategy. They offer business services through an e-banking system. Behind that sits the application architecture (the e-banking software), and below that the technical architecture (the core banking system and backends). This layered view across the entire enterprise is what Enterprise Architecture provides.\nGregor Hohpe puts it beautifully and concisely:\n\u0026ldquo;Enterprise Architecture is the glue between Business and IT Architecture.\u0026rdquo;\nThe Enterprise Architect: from ivory tower to factory floor # The stereotype of an Enterprise Architect sitting in an ivory tower, drawing pretty diagrams that nobody cares about, is unfortunately still common. But that is not how it should work.\nAn effective Enterprise Architect rides the architect elevator, a concept from Gregor Hohpe. You go up to the C-level to discuss business strategy, vision, and IT strategy. Then you go all the way down to the factory floor to work with the people who actually build things. This constant movement between strategic vision and operational reality is what makes Enterprise Architecture effective.\nThe core responsibilities are: understand the business strategy, translate it into IT strategy together with the CIO, create the \u0026ldquo;As-Is\u0026rdquo; picture (what capabilities and applications exist today), define the \u0026ldquo;To-Be\u0026rdquo; picture (what the future should look like), and build a roadmap to get there.\nEnterprise Architecture is a continuous process, not a project # Here is something critical: more than 66% of Enterprise Architecture initiatives fail. One likely reason is the word \u0026ldquo;initiative.\u0026rdquo; It sounds like a project with a start and an end. But Enterprise Architecture never ends. It is a continuous cycle.\nYou understand the vision and goals, extract the business strategy, derive the IT strategy with the CIO, create the As-Is picture, define the To-Be picture, build the roadmap, and then govern, refine, and coach. But then something happens. A global conflict, a pandemic, a Crowdstrike incident. The business strategy adapts, which means the IT strategy must follow, and the roadmaps shift.\nThis is not a project. This is a continuous process that never stops. When done right, Enterprise Architecture reduces cost, accelerates delivery, reduces risk, and makes the organisation more agile.\nThe digital factory: from strategy to execution # To show how Enterprise Architecture works in practice, I use the example of a drone company. The board has a vision: expand from small drones to a range of products for higher market share. They maintain a portfolio backlog of prioritised ideas. One idea, drones that carry high loads, gets passed to product management. Product managers break it into features: bigger battery, better motors, software updates. Teams start working.\nThe critical element: a platform team provides standardised development and delivery environments. New teams can start within minutes instead of spending weeks on setup. After delivery, telemetry data flows back to the teams for continuous improvement and back to the board for strategic decisions about investment.\nThis is the Digital Factory: lean portfolio management connecting strategy with execution, product management organising work, product teams doing DevOps, and the platform team providing the foundation.\nPlatforms: where Enterprise Architecture becomes real # Here is where it gets exciting for Enterprise Architects. The CNCF Platform White Paper describes how platforms provide capabilities: compute, networking, data, identity management, workloads, storage, and more. On top of these capabilities sits an interface with documentation, project templates, golden path templates, a graphical interface, APIs, and CLI.\nThe key insight for Enterprise Architects: with such a platform, you can codify your guidelines, rules, and policies directly into the infrastructure. Developers do not need to read your governance documents because the governance is already built into the platform. When a developer requests a database, it gets created with the correct naming scheme, the right sizing, proper backups, logging, and monitoring, all with one click.\n\u0026ldquo;With such a platform, you can codify all of your policies, all of your guidelines and rules. Nobody needs to read them because they are already codified and ready to be used.\u0026rdquo;\nThis is why platforms are so strategically important for Enterprise Architecture. Gartner and other consulting firms predict that by 2027, all large companies will create their own platforms.\nAI in the Enterprise Architecture picture # Now, where does AI fit? AI is a capability of the platform. It sits in one box of the architecture, but when you zoom in, that box is not small at all.\nIt contains:\nPlatform interfaces: Developer portal, chatbots, CLI, APIs Applications: Enterprise chatbots, synthetic data tools, AI coding assistants, knowledge management, productivity assistants Tools: Prompt engineering, vector databases, RAG solutions, model lifecycle management (MLOps) Model hub: Model registry with versioned models, both self-trained and large language models from providers Infrastructure: Compute, storage, and interfaces to AWS, Azure, Google Cloud, and OpenAI APIs I demonstrated this with the Zühlke Platform Plane, built together with LGT. On the platform, we integrated AI use cases that our developers love: a documentation assistant (a RAG use case over the platform docs), Docker image analysis using a specialised Red Hat LLM, and log analysis using an LLM optimised for that purpose. Each of these was built quickly because when you have a platform with all capabilities in place, creating AI use cases is like playing Lego.\nGartner predicts that by 2027, 40% of platforms will have AI integrated into their software delivery lifecycle. We are already there.\nKey takeaways # Enterprise Architecture is the glue between business and IT: It ensures the IT strategy is aligned with the business strategy. It is a continuous process, not a project: Enterprise Architecture never stops. The business environment keeps changing, and the architecture must adapt. The architect elevator is essential: Enterprise Architects must move between the boardroom and the factory floor. Ivory tower architecture fails. Platforms codify governance: With a platform, your guidelines, rules, and policies become part of the infrastructure. This is far more effective than documents nobody reads. AI is a capability of the platform: It is important, but it is still one capability among many. Govern it and standardise it through the platform. Self-service is key: No ticketing systems. Enable teams with a one-stop shop where they have everything they need. By combining Enterprise Architecture, platforms, and AI, you create a strategic lever: This boosts performance, enables innovation, and positions your organisation to continuously deliver value. ","date":"28 July 2024","externalUrl":null,"permalink":"/en/blogs/harnessing-enterprise-architecture-and-ai-for-strategic-benefit/","section":"Blogs","summary":"Enterprise Architecture is a big word that hangs heavy in the air. What does it actually mean for your organisation, and how does AI fit into the picture? In this talk, which I gave at the HSLU (Lucerne University of Applied Sciences and Arts) in association with the Digital Veterans Association, I explore how Enterprise Architecture, platform engineering, and AI come together as a strategic lever for modern organisations.\n","title":"Harnessing the Power of Enterprise Architecture and AI for Strategic Benefit","type":"blogs"},{"content":"","date":"28 July 2024","externalUrl":null,"permalink":"/en/tags/togaf/","section":"Tags","summary":"","title":"TOGAF","type":"tags"},{"content":"On July 19, 2024, the world witnessed one of the largest IT outages in history. A sensor configuration update from CrowdStrike, pushed to all Windows systems at 4:09 UTC, caused 8.5 million Microsoft Windows PCs to crash worldwide. Airlines, banks, hospitals, government agencies, stock exchanges, and countless other organizations were brought to a standstill. In this video, I break down what happened and, more importantly, what you can do to prevent something like this from happening in your organization.\nWhat Happened at CrowdStrike # CrowdStrike is an American cybersecurity firm founded in 2011 with a market capitalization of roughly $83 billion. Their Falcon software is an Endpoint Detection and Response (EDR) system that organizations install on their computers to detect malware and suspicious activity. On that Friday morning, a configuration update pushed between 4:09 and 5:27 UTC immediately crashed every Windows 7 and Windows 11 (or above) system that downloaded it. The result: a global wave of blue screens.\nWhen you looked at Down Detector that day, the picture was staggering. Company after company reporting outages. And CrowdStrike\u0026rsquo;s own share price dropped significantly as soon as the world identified them as the source.\nPlan Your Deployment and Release Strategy # The first principle I want to emphasize is to plan your deployment and release strategy. In DevOps, we make a critical distinction between deployment and release. A deployment is bringing compiled code into production with feature toggles switched off. A release is the act of switching those feature toggles on for users. This separation gives you enormous control over when and how new functionality reaches your users.\nQuality During Development # During development, several practices help ensure code quality before anything reaches production:\nPair Programming: Two developers working together means a second brain constantly reviewing the code. This is a powerful way to spot errors, including the kind of null pointer exception that potentially caused the CrowdStrike crash. Code Reviews and Merge Requests: Even after pair programming, a second person reviews your code during the merge request process. Another checkpoint to catch issues. Smart Pointers in C++: Since CrowdStrike\u0026rsquo;s system was implemented in C++, where you manage your own memory, tools like Smart Pointers are essential to prevent null pointer exceptions. Continuous Integration and Test Automation # After committing code to the repository, the Continuous Integration system kicks in. This is where your new code gets reintegrated with the rest of the codebase. During this phase:\nStatic Analysis (for example, CppCheck for C++) scans the code for errors and potential null pointer exceptions. Unit Tests and Integration Tests verify that the software works correctly on different Windows versions, including reboot mechanisms. Dynamic Analysis (for example, Valgrind for C++) executes the code and detects runtime issues, memory leaks, and exceptions. After these steps, you have a deployable artifact that has been reviewed, statically analyzed, and dynamically analyzed.\nStaging, Blue-Green Deployments, and Rollback # The reviewed artifact gets deployed to a staging environment where feature toggles allow you to test the software. Blue-green deployments are particularly valuable here: you maintain two environments, one live and one idle. You deploy to the idle environment, switch traffic over, and if something fails, you switch back instantly. This principle also applies to production. Rollback mechanisms, whether through blue-green switching or simply uninstalling and reverting to the previous version, are non-negotiable.\nAt this point, you have not yet released the software. In the CrowdStrike scenario, you would have deployed it but not released it.\nCanary Releases and Dark Launches # This is where I believe CrowdStrike could have made the biggest difference. Canary releases mean you release to a small user group first, typically beta users who want the newest features. If something goes wrong, the blast radius stays small. I am convinced that this principle would have helped massively in the CrowdStrike outage.\nDark launches are a variant: you continuously deploy new versions to production, but feature toggles remain off. You only enable them selectively on test systems to verify everything works. Normal users never see the new features until you are confident.\nA/B testing follows the same logic: one group (A) gets the new feature, the other (B) does not. You compare results before rolling out broadly.\nThese are all release strategies, and planning for them upfront is essential.\nProactive Detection and Monitoring # You never want your clients to discover a problem before you do. CrowdStrike\u0026rsquo;s clients found out about the crash before CrowdStrike did. To prevent this, you need:\nProactive Detection: Find bugs before your customers do. Alerting: Based on proactive detection, automated alerts must notify you immediately. Continuous Monitoring: Observe all systems, gather feedback, and enable proactive detection so you can react before users are impacted. Key Takeaways # We cannot prevent all incidents, but we can reduce the blast radius. We live in a highly connected world where software runs everything. We must learn from failures. Pair programming and code reviews catch errors early, including potential null pointer exceptions. Static and dynamic analysis provide automated safety nets for code quality. Unit and integration tests should verify the software on different system versions, including reboot mechanisms. Canary releases are critical. New versions should always go to a small beta group first to limit the impact of potential failures. Build resilient systems. As an industry, we need to ask hard questions. Why did Microsoft not build a more resilient Windows system that cannot be fully brought down by a single third-party update? We need to properly engineer our systems for resilience. Have a proper post-mortem. Analyze the root cause, improve based on findings, and apply DevOps principles consistently. ","date":"22 July 2024","externalUrl":null,"permalink":"/en/blogs/crowdstrike-disaster-causes-impact-prevention/","section":"Blogs","summary":"On July 19, 2024, the world witnessed one of the largest IT outages in history. A sensor configuration update from CrowdStrike, pushed to all Windows systems at 4:09 UTC, caused 8.5 million Microsoft Windows PCs to crash worldwide. Airlines, banks, hospitals, government agencies, stock exchanges, and countless other organizations were brought to a standstill. In this video, I break down what happened and, more importantly, what you can do to prevent something like this from happening in your organization.\n","title":"CrowdStrike Disaster: Causes, Impact, and How to Prevent Future Outages","type":"blogs"},{"content":"Am 19. Juli 2024 erlebte die Welt einen der grössten IT-Ausfälle der Geschichte. Ein Sensor-Konfigurationsupdate von CrowdStrike, das um 4:09 UTC an alle Windows-Systeme ausgeliefert wurde, brachte 8,5 Millionen Microsoft-Windows-PCs weltweit zum Absturz. Fluggesellschaften, Banken, Krankenhäuser, Behörden, Börsen und unzählige weitere Organisationen standen still. In diesem Video analysiere ich, was passiert ist und, noch wichtiger, was man tun kann, um so etwas in der eigenen Organisation zu verhindern.\nWas bei CrowdStrike passiert ist # CrowdStrike ist ein amerikanisches Cybersecurity-Unternehmen, gegründet 2011, mit einer Marktkapitalisierung von rund 83 Milliarden Dollar. Ihre Falcon-Software ist ein Endpoint-Detection-and-Response-System (EDR), das Organisationen auf ihren Computern installieren, um Malware und verdächtige Aktivitäten zu erkennen. An jenem Freitagmorgen verursachte ein Konfigurationsupdate, das zwischen 4:09 und 5:27 UTC verteilt wurde, den sofortigen Absturz jedes Windows-7- und Windows-11-Systems (oder höher), das es heruntergeladen hatte. Das Ergebnis: eine globale Welle von Bluescreens.\nEin Blick auf Down Detector an jenem Tag war erschreckend. Unternehmen um Unternehmen meldeten Ausfälle. Und der Aktienkurs von CrowdStrike fiel deutlich, sobald die Welt sie als Ursache identifizierte.\nDeployment- und Release-Strategie planen # Das erste Prinzip, das ich betonen möchte: Planen Sie Ihre Deployment- und Release-Strategie. In DevOps unterscheiden wir klar zwischen Deployment und Release. Ein Deployment bringt kompilierten Code mit ausgeschalteten Feature Toggles in die Produktion. Ein Release schaltet diese Feature Toggles für die Nutzer ein. Diese Trennung gibt enorme Kontrolle darüber, wann und wie neue Funktionalität die Nutzer erreicht.\nQualität während der Entwicklung # Während der Entwicklung helfen mehrere Praktiken, die Code-Qualität sicherzustellen, bevor irgendetwas die Produktion erreicht:\nPair Programming: Zwei Entwickler arbeiten zusammen, ein zweites Gehirn überprüft ständig den Code. Das ist eine wirkungsvolle Methode, um Fehler zu erkennen, einschliesslich der Art von Null-Pointer-Exception, die den CrowdStrike-Absturz möglicherweise verursacht hat. Code Reviews und Merge Requests: Auch nach dem Pair Programming überprüft eine zweite Person den Code beim Merge Request. Ein weiterer Kontrollpunkt. Smart Pointers in C++: Da das CrowdStrike-System in C++ implementiert war, wo man das Memory Management selbst übernimmt, sind Tools wie Smart Pointers unverzichtbar, um Null-Pointer-Exceptions zu verhindern. Continuous Integration und Testautomatisierung # Nach dem Commit in das Repository greift das Continuous-Integration-System. Hier wird der neue Code mit dem Rest der Codebasis reintegriert. In dieser Phase kommen zum Einsatz:\nStatische Analyse (z.B. CppCheck für C++) scannt den Code auf Fehler und potenzielle Null-Pointer-Exceptions. Unit Tests und Integrationstests prüfen, ob die Software auf verschiedenen Windows-Versionen korrekt funktioniert, einschliesslich Reboot-Mechanismen. Dynamische Analyse (z.B. Valgrind für C++) führt den Code aus und erkennt Laufzeitprobleme, Speicherlecks und Exceptions. Nach diesen Schritten hat man ein deploymenttaugliches Artefakt, das reviewt, statisch und dynamisch analysiert wurde.\nStaging, Blue-Green Deployments und Rollback # Das geprüfte Artefakt wird auf eine Staging-Umgebung deployed, wo Feature Toggles das Testen der Software ermöglichen. Blue-Green Deployments sind hier besonders wertvoll: Man betreibt zwei Umgebungen, eine aktive und eine inaktive. Man deployed auf die inaktive Umgebung, leitet den Traffic um, und falls etwas schiefgeht, schaltet man sofort zurück. Rollback-Mechanismen sind unverzichtbar, egal ob durch Blue-Green-Switching oder durch Deinstallation und Rückkehr zur vorherigen Version.\nZu diesem Zeitpunkt hat man die Software noch nicht released. Im CrowdStrike-Szenario hätte man sie deployed, aber nicht released.\nCanary Releases und Dark Launches # Hier hätte CrowdStrike meiner Meinung nach den grössten Unterschied machen können. Canary Releases bedeuten, dass man zuerst an eine kleine Nutzergruppe ausliefert, typischerweise Beta-Nutzer, die die neuesten Features haben möchten. Falls etwas schiefgeht, bleibt der Blast Radius klein. Ich bin überzeugt, dass dieses Prinzip beim CrowdStrike-Ausfall massiv geholfen hätte.\nDark Launches sind eine Variante: Man deployed kontinuierlich neue Versionen in die Produktion, aber die Feature Toggles bleiben ausgeschaltet. Man aktiviert sie nur gezielt auf Testsystemen, um zu verifizieren, dass alles funktioniert. Normale Nutzer sehen die neuen Features nie, bis man sicher ist.\nA/B Testing folgt derselben Logik: Eine Gruppe (A) bekommt das neue Feature, die andere (B) nicht. Man vergleicht die Ergebnisse, bevor man breit ausrollt.\nDas alles sind Release-Strategien, und die vorausschauende Planung dafür ist essenziell.\nProaktive Erkennung und Monitoring # Man möchte nie, dass die eigenen Kunden ein Problem vor einem selbst entdecken. CrowdStrikes Kunden erfuhren vom Absturz vor CrowdStrike selbst. Um das zu verhindern, braucht man:\nProaktive Erkennung: Bugs finden, bevor die Kunden sie finden. Alerting: Basierend auf der proaktiven Erkennung müssen automatisierte Alerts sofort benachrichtigen. Kontinuierliches Monitoring: Alle Systeme beobachten, Feedback sammeln und die proaktive Erkennung ermöglichen, damit man reagieren kann, bevor Nutzer betroffen sind. Kernaussagen # Wir können nicht alle Vorfälle verhindern, aber wir können den Blast Radius reduzieren. Wir leben in einer hochvernetzten Welt, in der Software alles steuert. Wir müssen aus Fehlern lernen. Pair Programming und Code Reviews finden Fehler früh, einschliesslich potenzieller Null-Pointer-Exceptions. Statische und dynamische Analyse bieten automatisierte Sicherheitsnetze für die Code-Qualität. Unit- und Integrationstests sollten die Software auf verschiedenen Systemversionen verifizieren, einschliesslich Reboot-Mechanismen. Canary Releases sind entscheidend. Neue Versionen sollten immer zuerst an eine kleine Beta-Gruppe gehen, um die Auswirkungen potenzieller Fehler zu begrenzen. Resiliente Systeme bauen. Als Industrie müssen wir unbequeme Fragen stellen. Warum hat Microsoft kein resilienteres Windows-System gebaut, das nicht von einem einzigen Drittanbieter-Update komplett lahmgelegt werden kann? Wir müssen unsere Systeme konsequent für Resilienz entwickeln. Ein gründliches Post-Mortem durchführen. Die Root Cause analysieren, auf Basis der Erkenntnisse verbessern und DevOps-Prinzipien konsequent anwenden. ","date":"22. July 2024","externalUrl":null,"permalink":"/de/blogs/crowdstrike-desaster-ursachen-auswirkungen-praevention/","section":"Blogs","summary":"Am 19. Juli 2024 erlebte die Welt einen der grössten IT-Ausfälle der Geschichte. Ein Sensor-Konfigurationsupdate von CrowdStrike, das um 4:09 UTC an alle Windows-Systeme ausgeliefert wurde, brachte 8,5 Millionen Microsoft-Windows-PCs weltweit zum Absturz. Fluggesellschaften, Banken, Krankenhäuser, Behörden, Börsen und unzählige weitere Organisationen standen still. In diesem Video analysiere ich, was passiert ist und, noch wichtiger, was man tun kann, um so etwas in der eigenen Organisation zu verhindern.\n","title":"CrowdStrike-Desaster: Ursachen, Auswirkungen und wie man künftige Ausfälle verhindert","type":"blogs"},{"content":"","date":"22 July 2024","externalUrl":null,"permalink":"/en/tags/cybersecurity/","section":"Tags","summary":"","title":"Cybersecurity","type":"tags"},{"content":"Many organizations build machine learning prototypes that never make it into production. MLOps provides the practices, culture, and architecture to bridge this gap.\nWhat This Talk Covers # This presentation outlines how MLOps helps organizations move machine learning from isolated prototypes into reliable production systems. It frames MLOps as more than a technical setup: a mindset, culture, and set of practices that unify development and operations across the full ML lifecycle, including experimentation, training, deployment, serving, monitoring, and retraining.\nKey Messages # 1. Business Drivers for MLOps Reproducibility, auditability, faster iteration, operational reliability, and improved maintainability. These are the reasons organizations need MLOps, not just technical curiosity.\n2. Core Capabilities of an MLOps Architecture Experimentation environments, pipelines, model registry, serving infrastructure, and observability. Understanding these building blocks is essential for a successful MLOps setup.\n3. Platform Foundation for Sustainable MLOps Sustainable MLOps depends on a strong platform foundation that delivers machine learning capabilities as a service to product teams across the organization. The talk introduces an MLOps maturity model to help organizations assess and plan their journey.\n","date":"22 July 2024","externalUrl":null,"permalink":"/en/speaking/mlops-from-prototypes-to-production/","section":"Speaking","summary":"Many organizations build machine learning prototypes that never make it into production. MLOps provides the practices, culture, and architecture to bridge this gap.\nWhat This Talk Covers # This presentation outlines how MLOps helps organizations move machine learning from isolated prototypes into reliable production systems. It frames MLOps as more than a technical setup: a mindset, culture, and set of practices that unify development and operations across the full ML lifecycle, including experimentation, training, deployment, serving, monitoring, and retraining.\n","title":"MLOps: From ML Prototypes to Production Through Platform-Based Operationalization","type":"speaking"},{"content":"","date":"22 July 2024","externalUrl":null,"permalink":"/en/tags/resilience/","section":"Tags","summary":"","title":"Resilience","type":"tags"},{"content":"","date":"22. July 2024","externalUrl":null,"permalink":"/de/tags/resilienz/","section":"Tags","summary":"","title":"Resilienz","type":"tags"},{"content":"Banking software must be secure, reliable, and trustworthy. But many banks still rely on traditional development methods that are slow, risky, and inefficient. In this video, I explore three modern software development practices that are fundamentally changing how banks build and deliver software: continuous deployment, test-driven development, and feature flags.\nWhy Modern Practices Matter for Banks # Modern software development practices achieve two critical outcomes for banks. First, they massively reduce risk. Continuous deployment brings small changes into production with small risk. Test-driven development ensures the quality of what you build. Feature flags let you easily switch features on and off. Together, these practices significantly improve the bank\u0026rsquo;s security posture, making applications more resilient against attacks.\nSecond, they foster enhanced customer trust and satisfaction by demonstrating a commitment to protecting customer data and privacy. In banking, trust is everything. Modern development practices are not just about speed. They are about building a foundation of security and reliability.\nContinuous Integration and Continuous Deployment # To understand continuous deployment, we first need to understand the pipeline. In continuous integration, a developer commits source code into the repository to integrate their code with the rest of the codebase. A CI server builds the code, runs static code analysis, executes unit tests, and produces a deployable artifact.\nContinuous deployment takes that artifact and automatically deploys it to a staging environment where additional tests verify the system still works. If everything is green, the artifact gets automatically deployed into production.\n\u0026ldquo;The benefit of continuous deployment is that you can bring small changes very fast into production, which leads to smaller risk.\u0026rdquo;\nFor banks, the security implications are profound. When vulnerabilities are discovered, the bank can respond immediately, deploying security patches much faster than through traditional methods. This agility enhances application security and ensures that customer data remains protected against emerging threats.\nTest-Driven Development: Quality from the Start # Test-driven development (TDD) is a test-first approach where you write tests before writing the actual code. The cycle works like this: first, think about the feature. Then think about how to test it. Then write the first test. Of course, the test fails because there is no implementation yet (the \u0026ldquo;red\u0026rdquo; phase). Then implement the functionality so the test turns green. With a passing test in place, you can safely refactor your code. Then write the next test, and repeat.\nThis approach catches flaws in the code very early in the development process. You are not discovering problems months later during a separate testing phase. You are preventing them at the point of creation. For banks, where a single bug in financial calculations or security logic can have serious consequences, this early detection is invaluable.\nFeature Flags: Separating Deployment from Release # Feature flags create a powerful distinction between deployment and release. A deployment brings compiled code into production with the feature toggle switched off. A release is the act of switching the toggle on, enabling the feature for users.\nThis separation is what makes continuous deployment truly safe. You can continuously deploy new functionality into production with the feature toggle off, so users cannot access it while it is still under development. When the feature is ready, you switch the toggle on for a selected group of users, monitor performance, and make adjustments before rolling it out to everyone.\n\u0026ldquo;Feature flags allow us to do continuous deployment. We can continuously deploy functionality into production but with the feature toggle off, so users cannot yet use the feature while it is still under development.\u0026rdquo;\nFor banking security, this is invaluable. Banks can roll out new security features to a selected group of users first, monitoring performance and making necessary adjustments. This controlled approach enables A/B testing and ensures that security enhancements are effective and seamless before reaching all customers.\nThe Challenge of Adoption # Integrating these modern methodologies, especially with legacy systems, is not trivial. Shifting away from traditional development processes requires a cultural change that can meet resistance in organizations. People are comfortable with what they know, and change is hard.\nBut in my opinion, there is no way around it. Banks need to adopt these modern software development practices because staying static is no longer an option. The threat landscape evolves daily. Customer expectations grow continuously. Competitors who adopt modern practices will deliver better, safer products faster.\nThe investment is worth it. Continuous value delivery to customers. Better customer experience. Higher quality. More value for money. Improved time to market. These are not theoretical benefits. They are measurable outcomes that I have seen in real banking projects.\nThe Role of Leadership # Dealing with the resistance to change is the job of the leadership team. A DevOps transformation in a bank is not just a technical initiative. It is a cultural transformation that requires clear direction and sustained commitment from the top.\nLeaders need to communicate why the change is necessary, create the conditions for teams to experiment and learn, and provide the patience required for a meaningful transformation. Without leadership support, even the best technical practices will struggle to take root.\nKey Takeaways # Small changes mean small risk. Continuous deployment brings incremental updates to production, making each change easy to verify and quick to roll back if needed.\nTest first, code second. TDD catches bugs at the point of creation rather than months later. In banking, where errors can have serious financial and security consequences, this is essential.\nSeparate deployment from release. Feature flags let you deploy continuously without exposing unfinished features to users, enabling safe, gradual rollouts.\nSecurity is a continuous practice. Modern development practices are not a one-time security investment. They build security into every step of the development process.\nLeadership drives the transformation. Adopting modern practices requires cultural change, and that starts at the top. Without leadership commitment, technical improvements alone are not enough.\n","date":"20 May 2024","externalUrl":null,"permalink":"/en/blogs/app-solutely-safe-modern-banking-software/","section":"Blogs","summary":"Banking software must be secure, reliable, and trustworthy. But many banks still rely on traditional development methods that are slow, risky, and inefficient. In this video, I explore three modern software development practices that are fundamentally changing how banks build and deliver software: continuous deployment, test-driven development, and feature flags.\n","title":"App-Solutely Safe: How Banks Use Modern Software Development","type":"blogs"},{"content":"Banksoftware muss sicher, zuverlässig und vertrauenswürdig sein. Aber viele Banken verlassen sich noch auf traditionelle Entwicklungsmethoden, die langsam, riskant und ineffizient sind. In diesem Video betrachte ich drei moderne Softwareentwicklungspraktiken, die grundlegend verändern, wie Banken Software bauen und liefern: Continuous Deployment, testgetriebene Entwicklung und Feature Flags.\nWarum moderne Praktiken für Banken wichtig sind # Moderne Softwareentwicklungspraktiken erreichen zwei kritische Ergebnisse für Banken. Erstens reduzieren sie massiv das Risiko. Continuous Deployment bringt kleine Änderungen mit kleinem Risiko in Produktion. Testgetriebene Entwicklung stellt die Qualität des Gebauten sicher. Feature Flags ermöglichen es, Features einfach ein- und auszuschalten. Zusammen verbessern diese Praktiken die Sicherheitslage der Bank erheblich und machen Applikationen widerstandsfähiger gegen Angriffe.\nZweitens fördern sie gesteigertes Kundenvertrauen und Zufriedenheit, indem sie das Engagement zum Schutz von Kundendaten und Privatsphäre demonstrieren. Im Bankwesen ist Vertrauen alles. Moderne Entwicklungspraktiken gehen nicht nur um Geschwindigkeit. Sie bauen ein Fundament aus Sicherheit und Zuverlässigkeit.\nContinuous Integration und Continuous Deployment # Um Continuous Deployment zu verstehen, müssen wir zuerst die Pipeline verstehen. Bei der Continuous Integration committed ein Entwickler Quellcode ins Repository, um seinen Code mit dem Rest der Codebasis zu integrieren. Ein CI-Server baut den Code, führt statische Codeanalyse durch, führt Unit-Tests aus und erzeugt ein deployables Artefakt.\nContinuous Deployment nimmt dieses Artefakt und deployed es automatisch in eine Staging-Umgebung, wo zusätzliche Tests verifizieren, dass das System noch funktioniert. Wenn alles grün ist, wird das Artefakt automatisch in die Produktionsumgebung deployed.\n\u0026ldquo;Der Vorteil von Continuous Deployment ist, dass Sie kleine Änderungen sehr schnell in Produktion bringen können, was zu einem kleineren Risiko führt.\u0026rdquo;\nFür Banken sind die Sicherheitsimplikationen tiefgreifend. Wenn Schwachstellen entdeckt werden, kann die Bank sofort reagieren und Sicherheitspatches viel schneller deployen als durch traditionelle Methoden. Diese Agilität verbessert die Applikationssicherheit und stellt sicher, dass Kundendaten gegen aufkommende Bedrohungen geschützt bleiben.\nTestgetriebene Entwicklung: Qualität von Anfang an # Testgetriebene Entwicklung (TDD) ist ein Test-first-Ansatz, bei dem Sie Tests schreiben, bevor Sie den eigentlichen Code schreiben. Der Zyklus funktioniert so: Zuerst über das Feature nachdenken. Dann überlegen, wie es getestet werden soll. Dann den ersten Test schreiben. Natürlich schlägt der Test fehl, weil es noch keine Implementierung gibt (die \u0026ldquo;rote\u0026rdquo; Phase). Dann die Funktionalität implementieren, damit der Test grün wird. Mit einem bestandenen Test können Sie Ihren Code sicher refactoren. Dann den nächsten Test schreiben und wiederholen.\nDieser Ansatz findet Fehler im Code sehr früh im Entwicklungsprozess. Sie entdecken Probleme nicht Monate später in einer separaten Testphase. Sie verhindern sie am Entstehungsort. Für Banken, wo ein einzelner Bug in Finanzberechnungen oder Sicherheitslogik schwerwiegende Folgen haben kann, ist diese frühe Erkennung unbezahlbar.\nFeature Flags: Deployment und Release trennen # Feature Flags schaffen eine wichtige Unterscheidung zwischen Deployment und Release. Ein Deployment bringt kompilierten Code in Produktion mit dem Feature Toggle ausgeschaltet. Ein Release ist der Akt des Einschaltens, der das Feature für Nutzer aktiviert.\nDiese Trennung macht Continuous Deployment wirklich sicher. Sie können kontinuierlich neue Funktionalität in Produktion deployen, während das Feature Toggle ausgeschaltet ist, sodass Nutzer nicht darauf zugreifen können, solange es noch in Entwicklung ist. Wenn das Feature bereit ist, schalten Sie den Toggle für eine ausgewählte Nutzergruppe ein, überwachen die Performance und nehmen Anpassungen vor, bevor es an alle ausgerollt wird.\n\u0026ldquo;Feature Flags ermöglichen uns Continuous Deployment. Wir können kontinuierlich Funktionalität in Produktion deployen, aber mit dem Feature Toggle ausgeschaltet, sodass Nutzer das Feature noch nicht verwenden können, während es noch in Entwicklung ist.\u0026rdquo;\nFür die Banksicherheit ist dies unschätzbar. Banken können neue Sicherheitsfeatures zuerst an eine ausgewählte Nutzergruppe ausrollen, die Performance überwachen und notwendige Anpassungen vornehmen. Dieser kontrollierte Ansatz ermöglicht A/B-Testing und stellt sicher, dass Sicherheitsverbesserungen effektiv und nahtlos sind, bevor sie alle Kunden erreichen.\nDie Herausforderung der Einführung # Die Integration dieser modernen Methoden, besonders mit Legacy-Systemen, ist nicht trivial. Der Wechsel von traditionellen Entwicklungsprozessen erfordert einen kulturellen Wandel, der in Organisationen auf Widerstand stossen kann. Menschen fühlen sich wohl mit dem, was sie kennen, und Veränderung ist schwer.\nAber meiner Meinung nach führt kein Weg daran vorbei. Banken müssen diese modernen Softwareentwicklungspraktiken übernehmen, weil Stillstand keine Option mehr ist. Die Bedrohungslandschaft entwickelt sich täglich weiter. Kundenerwartungen wachsen kontinuierlich. Wettbewerber, die moderne Praktiken übernehmen, werden bessere, sicherere Produkte schneller liefern.\nDie Investition lohnt sich. Kontinuierliche Wertlieferung an Kunden. Bessere Kundenerfahrung. Höhere Qualität. Mehr Wert fürs Geld. Verbesserte Time-to-Market. Das sind keine theoretischen Vorteile. Es sind messbare Ergebnisse, die ich in echten Bankprojekten gesehen habe.\nDie Rolle der Führung # Mit dem Widerstand gegen Veränderung umzugehen ist die Aufgabe des Führungsteams. Eine DevOps-Transformation in einer Bank ist nicht nur eine technische Initiative. Es ist eine kulturelle Transformation, die klare Richtung und anhaltendes Engagement von oben erfordert.\nFührungskräfte müssen kommunizieren, warum die Veränderung notwendig ist, die Bedingungen schaffen, damit Teams experimentieren und lernen können, und die Geduld aufbringen, die eine bedeutungsvolle Transformation erfordert. Ohne Unterstützung der Führung werden selbst die besten technischen Praktiken Mühe haben, Fuss zu fassen.\nKernaussagen # Kleine Änderungen bedeuten kleines Risiko. Continuous Deployment bringt inkrementelle Updates in Produktion, sodass jede Änderung leicht zu verifizieren und schnell zurückzurollen ist.\nErst testen, dann programmieren. TDD findet Bugs am Entstehungsort statt Monate später. Im Bankwesen, wo Fehler schwerwiegende finanzielle und sicherheitsrelevante Konsequenzen haben können, ist das essenziell.\nDeployment und Release trennen. Feature Flags ermöglichen kontinuierliches Deployment, ohne unfertige Features den Nutzern auszusetzen, und erlauben sichere, schrittweise Rollouts.\nSicherheit ist eine kontinuierliche Praxis. Moderne Entwicklungspraktiken sind keine einmalige Sicherheitsinvestition. Sie bauen Sicherheit in jeden Schritt des Entwicklungsprozesses ein.\nFührung treibt die Transformation. Die Einführung moderner Praktiken erfordert kulturellen Wandel, und der beginnt an der Spitze. Ohne Engagement der Führung reichen technische Verbesserungen allein nicht aus.\n","date":"20. May 2024","externalUrl":null,"permalink":"/de/blogs/app-solutely-safe-moderne-banksoftware/","section":"Blogs","summary":"Banksoftware muss sicher, zuverlässig und vertrauenswürdig sein. Aber viele Banken verlassen sich noch auf traditionelle Entwicklungsmethoden, die langsam, riskant und ineffizient sind. In diesem Video betrachte ich drei moderne Softwareentwicklungspraktiken, die grundlegend verändern, wie Banken Software bauen und liefern: Continuous Deployment, testgetriebene Entwicklung und Feature Flags.\n","title":"App-Solutely Safe: Wie Banken moderne Softwareentwicklung nutzen","type":"blogs"},{"content":"","date":"20 May 2024","externalUrl":null,"permalink":"/en/tags/software-quality/","section":"Tags","summary":"","title":"Software Quality","type":"tags"},{"content":"","date":"20. May 2024","externalUrl":null,"permalink":"/de/tags/softwarequalit%C3%A4t/","section":"Tags","summary":"","title":"Softwarequalität","type":"tags"},{"content":"","date":"20 May 2024","externalUrl":null,"permalink":"/en/tags/test-driven-development/","section":"Tags","summary":"","title":"Test-Driven Development","type":"tags"},{"content":"","date":"20. May 2024","externalUrl":null,"permalink":"/de/tags/testgetriebene-entwicklung/","section":"Tags","summary":"","title":"Testgetriebene Entwicklung","type":"tags"},{"content":"","date":"29 March 2024","externalUrl":null,"permalink":"/en/tags/cloud-computing/","section":"Tags","summary":"","title":"Cloud Computing","type":"tags"},{"content":"","date":"29 March 2024","externalUrl":null,"permalink":"/en/tags/compliance/","section":"Tags","summary":"","title":"Compliance","type":"tags"},{"content":"Einführung in das eBook Moving to Modern Development Practices in Banking: A Playbook\nWillkommen zum «Modern Banking eBook», einem umfassenden Leitfaden für Bankinstitute, die sich auf die entscheidende Reise zur Modernisierung ihrer Softwareentwicklungsprozesse begeben. Ich bin Romano Roth, und es ist mir eine Ehre, Sie durch die transformativen Schritte zu führen, die die Arbeitsweise von Banken im digitalen Zeitalter neu gestalten können.\nIn der heutigen hart umkämpften Bankenlandschaft ist der Antrieb zur Modernisierung stärker denn je. Dieser Antrieb wird durch das Bedürfnis nach schnellerer Time-to-Market, höherem Wert für investiertes Geld und vor allem nach gesteigerter Kundenzufriedenheit geschürt. Diese Säulen sind grundlegend, um in einem Umfeld zu bestehen, in dem Customer Experience nicht nur eine Kennzahl, sondern das Herzstück der Differenzierung ist. Das moderne Banken-Ökosystem verlangt Agilität, Innovation und einen unermüdlichen Fokus auf das Bereitstellen aussergewöhnlicher Nutzererlebnisse. Doch was veranlasst Banken, diese Modernisierung einzuleiten?\nDas Bestreben, Produkte schneller, effizienter und mit massgeschneiderten Kundenerlebnissen an erster Stelle auf den Markt zu bringen,\nist der primäre Katalysator. Moderne Softwareentwicklungspraktiken wie Continuous Deployment, Feature Flags und Test-Driven Development sind nicht nur technische Upgrades; sie sind strategische Enabler. Diese Praktiken ermöglichen es Banken, kleine, risikoarme Änderungen auszurollen, Features bei Bedarf an bestimmten Standorten oder für Untergruppen von Nutzern freizugeben und A/B-Tests durchzuführen. Dieser Ansatz verbessert nicht nur die Developer Experience erheblich, sondern beschleunigt auch den Release-Zyklus.\nDiese Reise ist jedoch nicht frei von Herausforderungen. Banken stehen vor Hürden wie strengen Compliance- und regulatorischen Anforderungen, traditionell längeren Entwicklungszyklen und der Trägheit von Legacy-Systemen. Diese Hindernisse zu überwinden erfordert einen durchdachten Ansatz, beginnend mit der Förderung einer Modernisierungskultur, der Einführung von Cloud- und Hybrid-Infrastrukturen sowie der Adoption von Praktiken wie DevSecOps, um Qualitätssicherung und Sicherheit nach links zu verschieben.\nDie ersten Schritte zur Modernisierung beinhalten Strategien, die das Entkoppeln der Anwendungslandschaften ermöglichen und in Richtung einer komponierbaren und ereignisgesteuerten Architektur führen. Dieser Ansatz, gestützt durch APIs und eine Trennung von den Kernbankensystemen, ebnet den Weg für eine agilere und reaktionsfähigere Bankenumgebung.\nDie Vorteile dieser Modernisierungsreise sind tiefgreifend. Teams werden eine gesteigerte Effizienz, eine kollaborativere Entwicklungskultur und die Fähigkeit erleben, innovative Lösungen zu liefern, die die Customer Experience direkt verbessern. Darüber hinaus wird die strategische Implementierung eines Internal Developer Portal (IDP) und von Platform-Engineering-Prinzipien entscheidend sein. Diese Elemente bilden das Fundament für die Transformation eines Bankinstituts in eine digitale Fabrik, in der alles mit Kundenkontakt individuell auf einer Plattform aufgebaut wird, die darauf ausgelegt ist, Teams zu befähigen und zu stärken.\nMit Blick in die Zukunft ist die Zukunft der Bankenprozesse vielversprechend mit AI, Multi-Cloud-Strategien, verteilten Teams und einem Wandel hin zum Denken in Produkten und Wertströmen. Das Ziel ist ein Bankensektor, der nicht nur anpassungsfähig und effizient ist, sondern auch genau auf die sich entwickelnden Anforderungen des Marktes und seiner Kunden eingestimmt ist.\nDieses eBook zeichnet eine Roadmap für die Modernisierung der Banken-Softwareentwicklung und deckt kritische Bereiche wie Feature Flags, Observability, CI/CD, Autorisierung und Plattform-Management ab. Durch die Linse einer Fallstudie über die Komerční Banka und Diskussionen über Open Source und Modernisierungsstrategien möchten wir Ihnen das Wissen und die Werkzeuge an die Hand geben, um Ihren Bankbetrieb zu transformieren.\nAlles, was Kundenkontakt hat, ist ein Differenzierungsmerkmal und muss massgeschneidert gebaut werden. Um dies zu erreichen, brauchen Banken eine Plattform, die ihre Teams befähigt, diese zu bauen. Im Wesentlichen werden Banken zu digitalen Fabriken: innovativ, effizient und kundenzentriert. Lassen Sie uns\ngemeinsam diese Reise antreten und die Grundlagen für eine Zukunft legen, in der Banken nicht nur Finanzinstitute, sondern digitale Kraftzentren sind, die Wirtschaftswachstum und Kundenzufriedenheit antreiben.\nLaden Sie das vollständige eBook herunter: Modern Development Practices in Banking: A Playbook\n","date":"29. March 2024","externalUrl":null,"permalink":"/de/blogs/einfuehrung-moderne-entwicklungspraktiken-im-banking-playbook/","section":"Blogs","summary":"Einführung in das eBook Moving to Modern Development Practices in Banking: A Playbook\nWillkommen zum «Modern Banking eBook», einem umfassenden Leitfaden für Bankinstitute, die sich auf die entscheidende Reise zur Modernisierung ihrer Softwareentwicklungsprozesse begeben. Ich bin Romano Roth, und es ist mir eine Ehre, Sie durch die transformativen Schritte zu führen, die die Arbeitsweise von Banken im digitalen Zeitalter neu gestalten können.\n","title":"Einführung in moderne Entwicklungspraktiken im Banking: Ein Playbook","type":"blogs"},{"content":"","date":"29 March 2024","externalUrl":null,"permalink":"/en/tags/fintech/","section":"Tags","summary":"","title":"FinTech","type":"tags"},{"content":"Intdiuction the the eBook Moving to Modern Development Practices in Banking: A Playbook\nWelcome to the “Modern Banking eBook”, a comprehensive guide for banking institutions embarking on the crucial journey of modernising their software development processes. I’m Romano Roth, and it’s my privilege to walk you through the transformative steps that can reshape the way banks operate in the digital age.\nIn today’s fiercely competitive banking landscape, the impetus for modernisation is stronger than ever. This drive is fueled by the need for faster time to market, enhanced value for money, and, most importantly, elevated customer satisfaction. These pillars are foundational to thriving in an environment where customer experience is not just a metric but the heart of differentiation. The modern banking ecosystem demands agility, innovation, and a relentless focus on delivering exceptional user experiences. But what prompts banks to initiate this modernisation?\nThe quest to deliver products to market more swiftly, efficiently, and with tailored customer\nexperiences at the forefront is the primary catalyst. Modern software development practices, such as continuous deployment, feature flags, and test-driven development, are not merely technical upgrades; they are strategic enablers. These practices enable banks to deploy small, low-risk changes, release features on demand to specific locations or subsets of users, and conduct A/B testing. This approach not only significantly improves the developer experience but also accelerates the release cycle.\nHowever, this journey is not devoid of challenges. Banks face hurdles like stringent compliance and regulatory requirements, traditionally longer development cycles, and the inertia of legacy systems. Overcoming these obstacles requires a thoughtful approach, starting with fostering a culture of modernisation, embracing cloud and hybrid infrastructures, and adopting practices like DevSecOps to shift left on\nquality assurance and security.\nThe first steps towards modernisation involve embracing strategies that allow for the decoupling of application landscapes and moving towards a composable and event-driven architecture. This approach, underpinned by APIs and a separation from core banking systems, paves the way for a more agile, responsive banking environment.\nThe benefits of embarking on this modernisation journey are profound. Teams will experience heightened efficiency, a more collaborative development culture, and the ability to deliver innovative solutions that directly enhance the customer experience. Moreover, the strategic implementation of an Internal Developer Portal (IDP) and platform engineering principles will be instrumental. These elements serve as the bedrock for a banking institution’s transformation into a digital factory, where everything with customer exposure is custom-built on a platform designed to enable and empower teams.\nLooking ahead, the future of banking processes is bright with the promise of AI, multi-cloud strategies, distributed teams, and a shift towards thinking in products and value streams. The goal is a banking sector that is not just adaptable and efficient, but also acutely attuned to the evolving demands of the market and its customers.\nThis eBook lays out a roadmap for modernising banking software development, covering critical areas such as feature flags, observability, CI/CD, authorisation, and platform management. Through the lens of a case study on Komerční Banka and discussions on open source and modernisation strategies, we aim to provide you with the knowledge and tools to transform your banking operations.\nEverything that has customer exposure is a differentiator and must be custom-built. To achieve this, banks need a platform that enables their teams to build it. In essence, banks are becoming digital factories: innovative, efficient, and customer-centric. Let us embark\non this journey together, laying the foundations for a future where banks are not just financial institutions but digital powerhouses that drive economic growth and customer satisfaction.\nDownload the full eBook: Modern Development Practices in Banking: A Playbook\n","date":"29 March 2024","externalUrl":null,"permalink":"/en/blogs/introduction-to-modern-development-practices-in-banking-a-playbook/","section":"Blogs","summary":"Intdiuction the the eBook Moving to Modern Development Practices in Banking: A Playbook\nWelcome to the “Modern Banking eBook”, a comprehensive guide for banking institutions embarking on the crucial journey of modernising their software development processes. I’m Romano Roth, and it’s my privilege to walk you through the transformative steps that can reshape the way banks operate in the digital age.\n","title":"Introduction to Modern Development Practices in Banking: A Playbook","type":"blogs"},{"content":"","date":"29. March 2024","externalUrl":null,"permalink":"/de/tags/moderne-entwicklung/","section":"Tags","summary":"","title":"Moderne Entwicklung","type":"tags"},{"content":"","date":"3 March 2024","externalUrl":null,"permalink":"/en/tags/aiops/","section":"Tags","summary":"","title":"AIOps","type":"tags"},{"content":"","date":"3 March 2024","externalUrl":null,"permalink":"/en/tags/culture/","section":"Tags","summary":"","title":"Culture","type":"tags"},{"content":"","date":"3. March 2024","externalUrl":null,"permalink":"/de/tags/kultur/","section":"Tags","summary":"","title":"Kultur","type":"tags"},{"content":"In this episode of the Ship It podcast, Gerhard Lazu and I have a deep conversation about what good DevOps looks like in practice. We talk about the real challenges companies face during transformations, how to deal with middle management resistance, technology choices, and where the industry is heading with AIOps and hyper automation.\nMy Journey into DevOps # When I started my career in 2002 as a .NET developer at Zühlke, I was always curious about how to ensure the quality of what I was building. I was a bit lazy and wanted to automate things. So I moved into continuous integration and continuous deployment. As applications grew bigger and more distributed, I became an architect and shifted toward building continuous delivery pipelines. When the DevOps movement started, I jumped on it because continuously delivering value to the customer has always been at the heart of what I do.\nToday, as Head of DevOps at Zühlke, I lead a team of about 31 DevOps engineers and consultants, working with different customers across various industries on IT and DevOps transformations.\nWhat Good DevOps Looks Like in Practice # One of the best examples I shared was from a customer where we built an agile release train for their transformation. We had different teams focusing on governance, CI/CD pipelines, and containerization. The key learning came from how we handled delivery.\nIn the first sprints, we delivered to the customer, but the customer was not using what we delivered. So we changed the approach: the customer needed to actively take over and use what we built. We put it in the definition of done. But that was still not enough. So we went one step further: in our review meetings, our team no longer demonstrated the work. The customer had to demonstrate how they were using it.\n\u0026ldquo;Don\u0026rsquo;t just deliver to the customer. Let the customer show what you have delivered and how they are using it.\u0026rdquo;\nThis simple shift made a massive difference in adoption and value delivery.\nThe Biggest Obstacle: Middle Management # When Gerhard asked about the biggest obstacles to DevOps transformations, I was direct: it is the middle management. In many companies, there are units organized as silos, each with a head who has built that unit and chases specific goals. When you start an agile or DevOps transformation, you align people around the value stream and bring them together. Some of these leaders see that they are losing power, and they resist.\nThe solution starts at the top. The top management needs a clear vision and clear guidance. They need to change the goals of middle management. Only by changing goals can you change behavior. And if someone truly does not want to change? Then potentially that person needs to leave the company. It is a difficult but sometimes necessary conversation.\nShip Less, More Often # The core of good DevOps comes down to a simple principle: ship less, more often, and check if it works.\nBehind every business idea is a hypothesis. You need to identify this hypothesis and figure out the minimal thing you need to do to prove it. This is where you define your minimum viable product and your leading indicators. By doing this, you reduce batch sizes massively, and the work flowing through your value stream becomes focused and meaningful.\nYou don\u0026rsquo;t need to chase Google, Netflix, or Amazon. It can be perfectly fine to ship every day or every week. The point is to find the sweet spot for your context. Any code or feature that is built but not out there is inventory, and zero inventory is the best type of inventory.\n\u0026ldquo;Don\u0026rsquo;t be afraid to take decisions. Don\u0026rsquo;t be afraid to make a bad decision. Just constantly learn and react and constantly adapt.\u0026rdquo;\nTechnology Decisions Belong to the Team # When it comes to choosing technology, I believe the team that needs to work with a technology should make the decision. If someone else decides, the team does not stand behind it. My approach is to first understand the real need: what problem are we trying to solve? Then evaluate different options with a structured analysis, build prototypes to get hands dirty, and let the team decide.\nThe story I shared about switching from server-side rendering to Angular illustrates this well. We started with an old technology to move fast, learned what the customer really needed, hit the limits of the technology, and then made the tough decision to switch. It felt like a failure at the time, but it was the right call. The initial approach enabled us to learn quickly, and the sunk cost should never prevent you from making the correct decision.\nAIOps and the DevOps Trends # We discussed the growing role of AI in operations. I use tools like Dynatrace and Datadog, which leverage AI for pattern matching across distributed log files. At one client, we had been chasing performance problems for a long time. By using Dynatrace, it pinpointed the exact server with a configuration problem in minutes. That is the power of AIOps.\nLooking at the trends, I see three major directions:\nHyper automation: Going beyond simple automation to automating nearly everything in the delivery pipeline Cyber resilience: Combining DevSecOps with broader organizational resilience against attacks Observability: As automation increases, so does the data you need to monitor and understand Participatory Budgeting # One topic close to my heart is participatory budgeting. The traditional approach, where someone at the top divides the budget equally, is inefficient because budget holders often do not understand the true impact of each initiative.\nIn participatory budgeting, all value stream members come together, receive a budget pot, and pitch for their initiatives. They discuss impact, alignment with strategy, and value creation. This sparks entrepreneurial thinking and emotional ownership, resulting in better budget allocation that truly supports the company\u0026rsquo;s goals.\nKey Takeaways # Deliver value, not just features. Have customers demonstrate what you delivered and how they use it. Address middle management resistance head-on. Change their goals from the top to change their behavior. Ship less, more often. Identify hypotheses, reduce batch sizes, and validate early. Let teams choose their technology. They own it, they should decide it. Leverage AIOps. AI-powered observability tools can find problems in minutes that would take weeks manually. Invest in participatory budgeting. It aligns investment with strategy and creates ownership across the organization. ","date":"3 March 2024","externalUrl":null,"permalink":"/en/blogs/what-does-good-devops-look-like/","section":"Blogs","summary":"In this episode of the Ship It podcast, Gerhard Lazu and I have a deep conversation about what good DevOps looks like in practice. We talk about the real challenges companies face during transformations, how to deal with middle management resistance, technology choices, and where the industry is heading with AIOps and hyper automation.\n","title":"What Does Good DevOps Look Like?","type":"blogs"},{"content":"In dieser Episode des Ship-It-Podcasts unterhalte ich mich mit Gerhard Lazu ausführlich darüber, wie gutes DevOps in der Praxis aussieht. Wir sprechen über die echten Herausforderungen, mit denen Unternehmen bei Transformationen konfrontiert sind, den Umgang mit Widerstand im mittleren Management, Technologieentscheidungen und wohin sich die Branche mit AIOps und Hyper-Automatisierung entwickelt.\nMein Weg zu DevOps # Als ich 2002 als .NET-Entwickler bei Zühlke begann, war ich immer neugierig, wie ich die Qualität meiner Arbeit sicherstellen kann. Ich war etwas faul und wollte Dinge automatisieren. So bewegte ich mich in Richtung Continuous Integration und Continuous Deployment. Als die Applikationen grösser und verteilter wurden, wurde ich Architekt und konzentrierte mich auf den Aufbau von Continuous-Delivery-Pipelines. Als die DevOps-Bewegung startete, war ich sofort dabei, denn den Kunden kontinuierlich Wert zu liefern, war schon immer der Kern meiner Arbeit.\nHeute leite ich als Head of DevOps bei Zühlke ein Team von etwa 31 DevOps-Engineers und -Consultants, die mit verschiedenen Kunden in unterschiedlichen Branchen an IT- und DevOps-Transformationen arbeiten.\nWie gutes DevOps in der Praxis aussieht # Eines der besten Beispiele, die ich teilte, stammte von einem Kunden, bei dem wir einen Agile Release Train für die Transformation aufgebaut haben. Verschiedene Teams konzentrierten sich auf Governance, CI/CD-Pipelines und Containerisierung. Die entscheidende Erkenntnis kam durch unseren Umgang mit der Lieferung.\nIn den ersten Sprints lieferten wir an den Kunden, aber der Kunde nutzte das Gelieferte nicht. Also änderten wir den Ansatz: Der Kunde musste aktiv übernehmen und nutzen, was wir gebaut hatten. Wir nahmen das in die Definition of Done auf. Aber das reichte immer noch nicht. Also gingen wir einen Schritt weiter: In unseren Review-Meetings demonstrierte nicht mehr unser Team die Arbeit. Der Kunde musste zeigen, wie er das Gelieferte nutzt.\n„Liefere nicht nur an den Kunden. Lass den Kunden zeigen, was du geliefert hast und wie er es nutzt.\u0026quot;\nDiese einfache Veränderung machte einen enormen Unterschied bei der Akzeptanz und Wertschöpfung.\nDas grösste Hindernis: Das mittlere Management # Auf die Frage nach den grössten Hindernissen bei DevOps-Transformationen war ich direkt: Es ist das mittlere Management. In vielen Unternehmen gibt es Einheiten, die als Silos organisiert sind, jede mit einem Leiter, der diese Einheit aufgebaut hat und spezifische Ziele verfolgt. Wenn man eine agile oder DevOps-Transformation startet, richtet man die Menschen am Wertstrom aus und bringt sie zusammen. Manche dieser Führungskräfte sehen, dass sie Macht verlieren, und leisten Widerstand.\nDie Lösung beginnt an der Spitze. Das Top-Management braucht eine klare Vision und klare Leitlinien. Sie müssen die Ziele des mittleren Managements ändern. Nur durch Änderung der Ziele kann man das Verhalten ändern. Und wenn jemand sich wirklich nicht ändern will? Dann muss diese Person möglicherweise das Unternehmen verlassen. Das ist ein schwieriges, aber manchmal notwendiges Gespräch.\nWeniger liefern, häufiger liefern # Der Kern von gutem DevOps lässt sich auf ein einfaches Prinzip zusammenfassen: Weniger liefern, häufiger liefern und prüfen, ob es funktioniert.\nHinter jeder Geschäftsidee steckt eine Hypothese. Man muss diese Hypothese identifizieren und herausfinden, was das Minimale ist, das man tun muss, um sie zu beweisen. Hier definiert man das Minimum Viable Product und die Frühindikatoren. Dadurch reduziert man die Batchgrössen massiv, und die Arbeit, die durch den Wertstrom fliesst, wird fokussiert und bedeutungsvoll.\nMan muss nicht Google, Netflix oder Amazon hinterherjagen. Es kann völlig in Ordnung sein, täglich oder wöchentlich zu liefern. Es geht darum, den Sweet Spot für den eigenen Kontext zu finden. Jeder Code oder jedes Feature, das gebaut, aber nicht draussen ist, ist Inventar. Und null Inventar ist das beste Inventar.\n„Hab keine Angst, Entscheidungen zu treffen. Hab keine Angst, eine falsche Entscheidung zu treffen. Lerne, reagiere und passe dich einfach ständig an.\u0026quot;\nTechnologieentscheidungen gehören dem Team # Bei der Technologiewahl bin ich überzeugt: Das Team, das mit einer Technologie arbeiten muss, sollte die Entscheidung treffen. Wenn jemand anders entscheidet, steht das Team nicht dahinter. Mein Ansatz ist, zuerst den echten Bedarf zu verstehen: Welches Problem versuchen wir zu lösen? Dann die verschiedenen Optionen strukturiert analysieren, Prototypen bauen, um praktische Erfahrung zu sammeln, und das Team entscheiden lassen.\nDie Geschichte über den Wechsel von Server-Side Rendering zu Angular illustriert das gut. Wir starteten mit einer alten Technologie, um schnell zu sein, lernten, was der Kunde wirklich brauchte, stiessen an die Grenzen der Technologie und trafen dann die schwierige Entscheidung zu wechseln. Es fühlte sich im Moment wie ein Misserfolg an, aber es war die richtige Entscheidung. Der anfängliche Ansatz ermöglichte es uns, schnell zu lernen, und die versunkenen Kosten sollten nie verhindern, die richtige Entscheidung zu treffen.\nAIOps und die DevOps-Trends # Wir diskutierten die wachsende Rolle von KI im Betrieb. Ich nutze Tools wie Dynatrace und Datadog, die KI für Mustererkennung über verteilte Log-Dateien einsetzen. Bei einem Kunden hatten wir lange mit Performance-Problemen zu kämpfen. Mit Dynatrace wurde der exakte Server mit einem Konfigurationsproblem in Minuten identifiziert. Das ist die Stärke von AIOps.\nBei den Trends sehe ich drei grosse Richtungen:\nHyper-Automatisierung: Über einfache Automatisierung hinausgehen und nahezu alles in der Delivery-Pipeline automatisieren Cyber-Resilienz: DevSecOps mit umfassender organisatorischer Widerstandsfähigkeit gegen Angriffe kombinieren Observability: Mit zunehmender Automatisierung wächst auch die Datenmenge, die man überwachen und verstehen muss Partizipative Budgetierung # Ein Thema, das mir am Herzen liegt, ist die partizipative Budgetierung. Der traditionelle Ansatz, bei dem jemand an der Spitze das Budget gleichmässig verteilt, ist ineffizient, weil Budgetverantwortliche oft die tatsächliche Auswirkung jeder Initiative nicht verstehen.\nBei der partizipativen Budgetierung kommen alle Mitglieder des Wertstroms zusammen, erhalten einen Budgettopf und pitchen für ihre Initiativen. Sie diskutieren über Wirkung, Ausrichtung an der Strategie und Wertschöpfung. Das weckt unternehmerisches Denken und emotionale Eigenverantwortung, was zu einer besseren Budgetverteilung führt, die die Unternehmensziele wirklich unterstützt.\nKernaussagen # Liefere Wert, nicht nur Features. Lass den Kunden zeigen, was du geliefert hast und wie er es nutzt. Gehe den Widerstand des mittleren Managements direkt an. Ändere ihre Ziele von oben, um ihr Verhalten zu ändern. Liefere weniger, liefere häufiger. Identifiziere Hypothesen, reduziere Batchgrössen und validiere früh. Lass Teams ihre Technologie wählen. Sie verantworten sie, sie sollten sie auch entscheiden. Nutze AIOps. KI-gestützte Observability-Tools können in Minuten Probleme finden, die manuell Wochen dauern würden. Investiere in partizipative Budgetierung. Sie richtet Investitionen an der Strategie aus und schafft Verantwortung in der gesamten Organisation. ","date":"3. March 2024","externalUrl":null,"permalink":"/de/blogs/wie-sieht-gutes-devops-aus/","section":"Blogs","summary":"In dieser Episode des Ship-It-Podcasts unterhalte ich mich mit Gerhard Lazu ausführlich darüber, wie gutes DevOps in der Praxis aussieht. Wir sprechen über die echten Herausforderungen, mit denen Unternehmen bei Transformationen konfrontiert sind, den Umgang mit Widerstand im mittleren Management, Technologieentscheidungen und wohin sich die Branche mit AIOps und Hyper-Automatisierung entwickelt.\n","title":"Wie sieht gutes DevOps aus?","type":"blogs"},{"content":"","date":"24. February 2024","externalUrl":null,"permalink":"/de/tags/digitale-fabrik/","section":"Tags","summary":"","title":"Digitale Fabrik","type":"tags"},{"content":"","date":"24 February 2024","externalUrl":null,"permalink":"/en/tags/financial-sector/","section":"Tags","summary":"","title":"Financial Sector","type":"tags"},{"content":"","date":"24. February 2024","externalUrl":null,"permalink":"/de/tags/finanzsektor/","section":"Tags","summary":"","title":"Finanzsektor","type":"tags"},{"content":"","date":"24 February 2024","externalUrl":null,"permalink":"/en/tags/platform-plane/","section":"Tags","summary":"","title":"Platform Plane","type":"tags"},{"content":"This talk is a recording of my presentation at the FI-Forum in Frankfurt am Main in November 2023. The topic: the Platform Plane and how to develop high-quality software in record time. Platform engineering is the foundation of the digital factory and enables teams to truly practice DevOps.\nThe Challenges in the Financial Sector # In my daily work, I collaborate with clients across various industries and lead DevOps transformations. Especially in the financial sector, I consistently see the same top five challenges: legacy application landscapes and processes, budget constraints (delivering more with less money), talent management (how to attract top-qualified employees), culture and change management, and the alignment between IT and business goals.\nWhat I typically see at these companies is a broken value stream. The business has great plans and writes them into Jira tickets and Word documents. These get thrown over the wall of confusion to the development team, then to testing, then to operations, and in the end the customer receives something that does not match what was ordered at all. The value stream is interrupted by silo organizations with different goals.\nDevOps as the Answer # DevOps is a mindset, a culture, and a set of technical practices that allows us to organize along the value stream and continuously deliver value. It is not just about Development and Operations. The term DevOps is actually misleading. Whether DevSecOps, BizDevOps, or any other variation: it is about bringing all people, processes, and technologies together to continuously deliver value.\nWhat do companies want to achieve with DevOps? More value for money, faster time to market, higher quality, better customer satisfaction, and top-qualified employees. The research confirms this: the State of DevOps Report shows that companies with DevOps deploy up to 973 times more frequently to production. The numbers are impressive.\nThe Scaling Problem # When you do DevOps, the battle cry is \u0026ldquo;You build it, you run it, you own it.\u0026rdquo; That sounds simple, but the reality is complex. You need infrastructure (cloud or on-prem), runtime, a CI/CD pipeline, monitoring, security tools, collaboration tools, and you need to keep costs under control. All these tools need to be maintained, integrated, updated, and access needs to be secured. And at the top, you actually wanted to develop the application that delivers business value.\nIn large enterprises, you often see multiple such stacks being built in parallel. The wheel gets reinvented, inconsistencies and redundancies emerge, and developers struggle to maintain this stack. The complexity is simply too great. The cognitive load on teams is too high, and they can no longer focus on delivering software.\nThe Digital Factory # To solve this challenge, we need a clear structure. Imagine a company that builds drones (or in your case: software). At the portfolio level, leadership has a vision and pulls out the most promising ideas. At the product level, product managers take these ideas and extract features. At the team level, product owners and teams work on user stories and use their CI/CD pipeline.\nHere is where the platform level comes in: a platform team provides the CI/CD pipelines and tools so that product teams do not need to reinvent the wheel. They can build directly on a standardized platform and work productively.\nThe whole thing becomes a digital factory. You can see the three ways of DevOps here: fast value delivery to the customer, collecting feedback (telemetry data back to developers), and continuous learning (customer satisfaction and market data back to leadership). At the top, we have Lean Portfolio Management connecting strategy to execution. At the bottom, we have the platform team as the foundation.\nPlatform Engineering in Detail # The platform team creates an internal product: the platform. This platform contains everything the product teams need: environments, CI/CD pipelines, access rights, security, monitoring, and more. The platform is provided as self-service.\nImportant: the platform provides capabilities that are used by the product teams. For example, when it comes to monitoring, the platform team provides the monitoring solution. But the product teams monitor their own solutions. The platform team does not do it for them.\nProduct teams generate value for the customer. The platform team generates value for the teams. Platform engineering enables DevOps in the product teams.\nThe Zühlke Platform Plane # Gartner, BCG, and McKinsey clearly state: platform engineering is absolutely essential for the future. By 2027, 75% of organizations will have built such a platform.\nAt Zühlke, we built the Platform Plane together with LGT, a private bank from Liechtenstein. It includes:\nApplication Runtime: Kubernetes as a Service with excellent developer experience through a portal and application tunnels DevSecOps: Automatic license scanning, secret detection, and SAST Access Management: Onboard in the morning, offboard in the evening. All rights to repositories and tools are immediately revoked Security: Policy enforcement and network zones Observability: FinOps and the OpenTelemetry stack GitOps: For continuous value delivery The architecture follows a clear principle: at the top, people work with the tools (we do not abstract tools away). Next to it, the platform provides a self-service portal and CLI. At the bottom, we integrate the various tools through adapters, not directly with each other, so no \u0026ldquo;big ball of mud\u0026rdquo; emerges. Tools can easily be replaced or new ones integrated.\nWhat the Platform Plane Provides # The self-service portal allows onboarding partners, creating spaces (projects/products), and assigning rights. You can see the entire cluster listed, connect directly via CLI, and work within the cluster. There is a standardized catalog of software components that are created with automatic naming schemes, managed passwords, and automatic integration into the monitoring system.\nBuilt-in security is directly integrated: repositories, containers, and images are automatically scanned. The integration into the CI/CD landscape is deep, with automatic pipelines. The OpenTelemetry stack with logs, metrics, and dashboards is directly implemented. Every application that is added automatically gets dashboards and is automatically integrated.\nThe Platform Plane is available to everyone through the Open Platform Plane Association for those who become members.\nKey Takeaways # Platform engineering forms the foundation of the digital factory. It enables teams to practice DevOps and continuously deliver value. Cognitive load must be reduced. Product teams should be able to focus on value creation, not on maintaining infrastructure and tools. Self-service is critical. The platform must be provided as a product with a self-service portal and CLI, not as a ticket-based service. Do not abstract tools, integrate them. Developers continue working with the tools, but the platform provides them in a standardized and integrated way. Product teams generate value for customers, platform teams generate value for teams. This clear separation of concerns is the key to scaling. We are entering the age of industrialized software development. Platform engineering is the key enabler. ","date":"24 February 2024","externalUrl":null,"permalink":"/en/blogs/platform-plane-high-quality-software-fast/","section":"Blogs","summary":"This talk is a recording of my presentation at the FI-Forum in Frankfurt am Main in November 2023. The topic: the Platform Plane and how to develop high-quality software in record time. Platform engineering is the foundation of the digital factory and enables teams to truly practice DevOps.\n","title":"Platform Plane: High-Quality Software in Record Time","type":"blogs"},{"content":"Dieser Vortrag ist eine Aufzeichnung meines Vortrags vom FI-Forum in Frankfurt am Main im November 2023. Das Thema: die Platform Plane und wie man hochwertige Software innerhalb kürzester Zeit entwickeln kann. Platform Engineering ist das Fundament der digitalen Fabrik und befähigt Teams, DevOps wirklich zu leben.\nDie Herausforderungen im Finanzsektor # In meiner täglichen Arbeit arbeite ich mit Kunden in verschiedenen Industrien zusammen und führe DevOps-Transformationen durch. Besonders im Finanzsektor sehe ich immer wieder dieselben Top-5-Herausforderungen: die Legacy-Applikationslandschaft und -Prozesse, Budget Constraints (mehr liefern mit weniger Geld), Talent Management (wie bekommt man die topqualifizierten Mitarbeiter), Kultur und Change Management, sowie das Alignment zwischen IT und Business-Zielen.\nWas ich bei solchen Firmen normalerweise sehe, ist ein gebrochener Wertstrom. Das Business hat grossartige Pläne und schreibt sie in Jira-Tickets und Word-Dokumente. Diese werden über die Wall of Confusion zum Entwicklungsteam geworfen, dann zum Testing, dann zum Betrieb, und am Ende kommt beim Kunden etwas an, das gar nicht dem entspricht, was bestellt wurde. Der Wertstrom ist unterbrochen durch Silo-Organisationen mit unterschiedlichen Zielen.\nDevOps als Antwort # DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das uns erlaubt, uns entlang des Wertstroms zu organisieren und kontinuierlich Wert zu liefern. Dabei geht es nicht nur um Development und Operations. Der Begriff DevOps ist eigentlich irreführend. Ob DevSecOps, BizDevOps oder sonst eine Variante: es geht darum, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.\nWas wollen Unternehmen mit DevOps erreichen? Mehr Wert fürs Geld, schnelleren Time-to-Market, höhere Qualität, bessere Kundenzufriedenheit und topqualifizierte Mitarbeiter. Die Forschung bestätigt das: Der State of DevOps Report zeigt, dass Unternehmen mit DevOps bis zu 973-mal häufiger in die Produktion deployen. Die Zahlen sind beeindruckend.\nDas Problem der Skalierung # Wenn man DevOps macht, kommt der Schlachtruf \u0026ldquo;You build it, you run it, you own it.\u0026rdquo; Das klingt einfach, aber die Realität ist komplex. Man braucht Infrastruktur (Cloud oder On-Prem), Runtime, eine CI/CD-Pipeline, Monitoring, Security-Tools, Collaboration-Tools, und man muss die Kosten im Griff haben. All diese Tools müssen gewartet, integriert, aktualisiert und der Zugang gesichert werden. Und ganz oben wollte man ja eigentlich die Applikation entwickeln, die Geschäftswert liefert.\nIn grossen Unternehmen hat man häufig mehrere solcher Stacks, die parallel aufgebaut werden. Das Rad wird neu erfunden, Inkonsistenzen und Redundanzen entstehen, und die Entwickler haben Probleme, diesen Stack aufrechtzuerhalten. Die Komplexität ist schlichtweg zu gross. Der Cognitive Load auf die Teams ist zu hoch, und sie können sich nicht mehr auf das Liefern von Software konzentrieren.\nDie digitale Fabrik # Um diese Herausforderung zu lösen, brauchen wir eine klare Struktur. Stellen wir uns eine Firma vor, die Drohnen herstellt (oder in Ihrem Fall: Software). Auf dem Portfolio-Level hat die Geschäftsleitung eine Vision und zieht die vielversprechendsten Ideen heraus. Auf dem Produkt-Level nehmen Produktmanager diese Ideen und extrahieren Features. Auf dem Team-Level arbeiten die Product Owner und Teams an User Stories und nutzen ihre CI/CD-Pipeline.\nHier kommt der Platform-Level ins Spiel: Ein Platform-Team stellt die CI/CD-Pipelines und Tools zur Verfügung, damit die Produkt-Teams nicht das Rad neu erfinden müssen. Sie können direkt auf einer standardisierten Plattform aufbauen und produktiv arbeiten.\nDas Ganze wird zur digitalen Fabrik. Man sieht hier die drei Wege von DevOps: schnell Wert liefern zum Kunden, Feedback sammeln (Telemetriedaten zurück zu den Entwicklern) und kontinuierlich lernen (Kundenzufriedenheit und Marktdaten zurück zur Geschäftsleitung). Oben haben wir das Lean Portfolio Management, das Strategie mit Ausführung verbindet. Unten haben wir das Platform-Team als Fundament.\nPlatform Engineering im Detail # Das Platform-Team erstellt ein internes Produkt: die Plattform. Diese Plattform beinhaltet alles, was die Produkt-Teams brauchen: Umgebungen, CI/CD-Pipelines, Zugriffsrechte, Security, Monitoring und mehr. Die Plattform wird als Self-Service zur Verfügung gestellt.\nWichtig: Die Plattform stellt Fähigkeiten bereit, die von den Produkt-Teams genutzt werden. Wenn es zum Beispiel um Monitoring geht, stellt das Platform-Team die Monitoring-Lösung bereit. Aber die Produkt-Teams monitoren ihre eigenen Lösungen. Das Platform-Team übernimmt das nicht für sie.\nDie Produkt-Teams generieren Wert für den Kunden. Das Platform-Team generiert Wert für die Teams. Platform Engineering enabled DevOps in den Produkt-Teams.\nDie Zühlke Platform Plane # Gartner, BCG und McKinsey sagen klar: Platform Engineering ist absolut essenziell für die Zukunft. Bis 2027 werden 75% der Organisationen eine solche Plattform gebaut haben.\nBei Zühlke haben wir zusammen mit LGT, einer Privatbank aus Liechtenstein, die Platform Plane gebaut. Sie umfasst:\nApplication Runtime: Kubernetes as a Service mit grossartiger Developer Experience über ein Portal und Application Tunnels DevSecOps: Automatisches License Scanning, Secret Detection und SAST Zugriffsmanagement: Morgens onboarden, abends offboarden, alle Rechte auf Repositories und Tools werden sofort entzogen Security: Policy Enforcement und Netzwerkzonen Observability: FinOps und der OpenTelemetry Stack GitOps: Für kontinuierliche Wertlieferung Die Architektur folgt einem klaren Prinzip: Oben arbeiten die Menschen mit den Tools (wir abstrahieren keine Tools weg). Daneben gibt es die Plattform als Self-Service-Portal und CLI. Unten integrieren wir die verschiedenen Tools über Adaptoren, nicht direkt miteinander, sodass kein \u0026ldquo;Big Ball of Mud\u0026rdquo; entsteht. Tools können einfach ersetzt oder neue integriert werden.\nWas die Platform Plane bietet # Das Self-Service-Portal ermöglicht es, Partner zu onboarden, Spaces (Projekte/Produkte) zu erstellen und Rechte zu vergeben. Man hat den gesamten Cluster aufgelistet, kann sich per CLI direkt verbinden und im Cluster arbeiten. Es gibt einen standardisierten Katalog von Softwarekomponenten, die mit automatischem Namensschema, verwalteten Passwörtern und automatischer Integration ins Monitoring-System erstellt werden.\nBuild-in Security ist direkt eingebaut: Repositories, Container und Images werden vollautomatisch gescannt. Die Integration in die CI/CD-Landschaft ist tief, mit automatischen Pipelines. Der OpenTelemetry Stack mit Logs, Metriken und Dashboards ist direkt implementiert. Jede hinzugefügte Applikation bekommt automatisch Dashboards und wird automatisch integriert.\nDie Platform Plane steht in der Open Platform Plane Association jedem zur Verfügung, der Mitglied dieser Association wird.\nKernaussagen # Platform Engineering bildet das Fundament der digitalen Fabrik. Es enabled die Teams, DevOps zu leben und kontinuierlich Wert zu liefern. Der Cognitive Load muss reduziert werden. Produkt-Teams sollten sich auf die Wertschöpfung konzentrieren können, nicht auf die Wartung von Infrastruktur und Tools. Self-Service ist entscheidend. Die Plattform muss als Produkt mit Self-Service-Portal und CLI bereitgestellt werden, nicht als Ticket-basierter Service. Tools nicht abstrahieren, sondern integrieren. Die Entwickler arbeiten weiterhin mit den Tools, aber die Plattform stellt sie standardisiert und integriert bereit. Produkt-Teams generieren Wert für Kunden, Platform-Teams generieren Wert für die Teams. Diese klare Aufgabenteilung ist der Schlüssel zur Skalierung. Wir befinden uns im Zeitalter der Industrialisierung der Softwareentwicklung. Platform Engineering ist der Schlüssel dazu. ","date":"24. February 2024","externalUrl":null,"permalink":"/de/blogs/platform-plane-hochwertige-software-in-kurzer-zeit/","section":"Blogs","summary":"Dieser Vortrag ist eine Aufzeichnung meines Vortrags vom FI-Forum in Frankfurt am Main im November 2023. Das Thema: die Platform Plane und wie man hochwertige Software innerhalb kürzester Zeit entwickeln kann. Platform Engineering ist das Fundament der digitalen Fabrik und befähigt Teams, DevOps wirklich zu leben.\n","title":"Platform Plane: Hochwertige Software in kürzester Zeit","type":"blogs"},{"content":"","date":"17 February 2024","externalUrl":null,"permalink":"/en/tags/agile-testing/","section":"Tags","summary":"","title":"Agile Testing","type":"tags"},{"content":"","date":"17. February 2024","externalUrl":null,"permalink":"/de/tags/agiles-testen/","section":"Tags","summary":"","title":"Agiles Testen","type":"tags"},{"content":"Many people still think DevOps is only for web applications and cloud services. But the reality is clear: companies that apply DevOps principles to embedded systems are outpacing their competition. In this talk, which I gave at a DevOps Meetup in Munich, I explore why embedded teams need DevOps and how to build a Digital Factory that enables continuous value delivery, even for hardware products.\nThe Broken Value Stream # In most organizations I consult, the picture looks the same. Business creates plans, writes Jira tickets, and throws them over the \u0026ldquo;wall of confusion\u0026rdquo; to Development. Development implements something and throws it to Testing. Testing finds mismatches but signs off anyway. Operations receives the result and says \u0026ldquo;this will never work in production.\u0026rdquo; And when the customer finally sees it, they say: \u0026ldquo;This is not what we wanted.\u0026rdquo;\nThe root cause is the silo organization. Business, Development, Testing, and Operations work on different goals. They are not aligned, and the value stream is completely broken by these walls of confusion. The result: inflexible processes, slow delivery, and frustrated teams.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices which allows us to organize across the value stream and bring all the people together to work on a product.\u0026rdquo;\nFrom Projects to Products # Understanding the difference between project thinking and product thinking is fundamental to DevOps. A project has a start point, an end point, and a fixed set of deliverables. It is about maximizing the number of features delivered. Many companies claim they are agile, but they are still working in this project mode.\nProduct thinking is fundamentally different. In product mode, the customer is at the center. You work on that one feature that solves the customer\u0026rsquo;s problem, not on ten features because someone wrote them into a project plan. DevOps enables this shift because it brings all the people, processes, and technology together to continuously deliver value along a unified value stream.\nTesla: DevOps in the Real World # If you think DevOps does not apply to hardware, consider Tesla. In October 2021, Elon Musk tweeted about rolling out version 10.2 of the Full Self-Driving Beta to 1,000 owners with a perfect safety score of 100/100. What does this tell us?\nTesla\u0026rsquo;s software is modularized. They can update individual modules over the air. They do canary releases, targeting specific user groups. They calculate safety scores through observability. Eight days later, version 10.3 rolled out to a wider group. When a problem appeared, Tesla did a rollback and communicated that this was expected. Less than 24 hours later, they deployed 10.3.1 as a fix-forward.\nThis is canary releasing, rollbacks, fix-forward, and observability, all in a regulated environment with cars driving on public roads. The companies adopting Lean, Agile, and DevOps in hardware will soon dominate the market, just like Netflix, Google, and Facebook did in software twenty years ago.\nThe 24 Key Capabilities from Accelerate # The book \u0026ldquo;Accelerate: The Science Behind DevOps\u0026rdquo; identified 24 key capabilities that distinguish high-performing organizations. These are grouped into five areas:\nContinuous Delivery: Version control for everything (not just source code), automated deployments, continuous integration, trunk-based development, test automation, test data management, shift-left on security, and continuous delivery to staging.\nArchitecture: Loosely coupled architectures and empowered teams that can make their own decisions.\nProduct and Process: Customer feedback loops, value stream organization, small batches, and room for experimentation.\nLean Management: Eliminating harmful change approval boards, monitoring, proactive notifications, WIP limits, and visualizing work.\nCulture: Generative organizational culture where finding bugs is celebrated as learning, support for continuous learning, cross-team collaboration, job satisfaction, and transformational leadership.\nThe research shows that high performers achieve 973 times more deployments to production compared to low performers. Companies doing DevOps have faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees.\nContinuous Testing and Quality # Joe Justice, an Agile coach and former Tesla employee, stated that 50% of the money a Musk company invests into a new product goes into automated testing. In most companies I see, only a fraction goes into testing. This accelerates development at first, but eventually progress stalls because quality degrades.\nThe shift from the traditional V-model to modern testing is dramatic. In the old world, months could pass between writing a feature and testing it. With Behavior Driven Development (BDD), we define acceptance criteria in \u0026ldquo;given, when, then\u0026rdquo; form and bake quality in from the start. With Test-Driven Development (TDD), we write tests before code. The traditional test pyramid gets flipped: many unit tests (fast and cheap), some integration tests, and only a few end-to-end tests. The focus shifts from \u0026ldquo;find every bug\u0026rdquo; to \u0026ldquo;prevent bugs\u0026rdquo; through a risk-based approach.\n\u0026ldquo;In the traditional model, the focus is on finding every bug, which makes it very slow. In the Agile test pyramid, we want to prevent bugs. It is a risk-based approach.\u0026rdquo;\nPlatform Engineering: Scaling DevOps # When teams practice DevOps, each one needs infrastructure, CI/CD pipelines, monitoring, security tools, and access management. At scale, this creates massive redundancy, inconsistency, and cognitive overload. Each team reinvents the wheel.\nPlatform Engineering solves this. A dedicated platform team builds and maintains a standardized platform containing all the tools teams need: application runtime, developer experience, automated DevSecOps pipelines, access and identity management, and observability. Product teams still own and operate their products, following the \u0026ldquo;you build it, you run it\u0026rdquo; principle. The platform team simply provides the foundation.\nThe important distinction: customers do not pay for your platform. They pay for your products. But the platform generates value for your teams, enabling them to build better products faster.\nBuilding a Digital Factory # The Digital Factory is the holistic framework that ties everything together. At the portfolio level, the board of directors aligns big ideas with the company vision. At the product level, product management breaks down epics into features. At the team level, empowered teams work in an agile way on their modules, supported by a standardized platform.\nThis creates a continuous loop: fast delivery of features to the customer, fast feedback from the customer, and continuous learning. Platform Engineering builds the foundation. DevOps teams practice on top of it. And the Digital Factory orchestrates the whole system.\n\u0026ldquo;Platform Engineering builds your platform, which is the foundation of your Digital Factory, and enables your teams to do DevOps.\u0026rdquo;\nKey Takeaways # Products over projects. Stop maximizing features and start solving customer problems. DevOps enables the shift from project thinking to product thinking.\nQuality is not optional. Invest in automated testing from the start. Use BDD, TDD, and a risk-based test strategy. The cost of skipping tests always catches up with you.\nPlatform Engineering enables DevOps at scale. A standardized platform eliminates redundancy, reduces cognitive load, and lets product teams focus on delivering value.\nBuild a Digital Factory. Connect strategy with execution through Lean Portfolio Management, Platform Engineering, and empowered DevOps teams. This is how you industrialize embedded software development.\nLearn from Tesla. Even in regulated, hardware-heavy environments, DevOps practices like canary releases, rollbacks, and observability are not just possible, they are a competitive advantage.\n","date":"17 February 2024","externalUrl":null,"permalink":"/en/blogs/devops-in-an-embedded-world/","section":"Blogs","summary":"Many people still think DevOps is only for web applications and cloud services. But the reality is clear: companies that apply DevOps principles to embedded systems are outpacing their competition. In this talk, which I gave at a DevOps Meetup in Munich, I explore why embedded teams need DevOps and how to build a Digital Factory that enables continuous value delivery, even for hardware products.\n","title":"DevOps in an Embedded World: From Silos to Digital Factories","type":"blogs"},{"content":"Viele Menschen denken immer noch, DevOps sei nur für Webanwendungen und Cloud-Services relevant. Die Realität zeigt jedoch klar: Unternehmen, die DevOps-Prinzipien auf Embedded-Systeme anwenden, überholen ihre Konkurrenz. In diesem Vortrag, den ich bei einem DevOps-Meetup in München gehalten habe, zeige ich, warum Embedded-Teams DevOps brauchen und wie man eine Digitale Fabrik aufbaut, die kontinuierliche Wertlieferung ermöglicht, auch für Hardware-Produkte.\nDer unterbrochene Wertstrom # In den meisten Organisationen, die ich berate, sieht das Bild gleich aus. Das Business erstellt Pläne, schreibt Jira-Tickets und wirft sie über die \u0026ldquo;Wall of Confusion\u0026rdquo; zur Entwicklung. Die Entwicklung implementiert etwas und wirft es ans Testing. Das Testing findet Abweichungen, gibt aber trotzdem grünes Licht. Der Betrieb erhält das Ergebnis und sagt: \u0026ldquo;Das wird nie in Produktion funktionieren.\u0026rdquo; Und wenn der Kunde es schliesslich sieht, sagt er: \u0026ldquo;Das ist nicht, was wir wollten.\u0026rdquo;\nDie Ursache liegt in der Siloorganisation. Business, Entwicklung, Testing und Betrieb arbeiten auf unterschiedliche Ziele hin. Sie sind nicht aufeinander abgestimmt, und der Wertstrom ist durch diese Walls of Confusion komplett unterbrochen. Das Resultat: unflexible Prozesse, langsame Lieferung und frustrierte Teams.\n\u0026ldquo;DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, die es uns ermöglichen, uns entlang des Wertstroms zu organisieren und alle Menschen zusammenzubringen, um an einem Produkt zu arbeiten.\u0026rdquo;\nVon Projekten zu Produkten # Der Unterschied zwischen Projektdenken und Produktdenken ist fundamental für DevOps. Ein Projekt hat einen Start, ein Ende und ein fixes Set von Liefergegenständen. Es geht darum, die Anzahl der gelieferten Features zu maximieren. Viele Unternehmen behaupten, sie seien agil, arbeiten aber immer noch in diesem Projektmodus.\nProduktdenken ist fundamental anders. Im Produktmodus steht der Kunde im Zentrum. Man arbeitet an dem einen Feature, das das Problem des Kunden löst, nicht an zehn Features, weil jemand sie in einen Projektplan geschrieben hat. DevOps ermöglicht diesen Wandel, weil es alle Menschen, Prozesse und Technologien zusammenbringt, um kontinuierlich Wert entlang eines einheitlichen Wertstroms zu liefern.\nTesla: DevOps in der realen Welt # Wer denkt, DevOps sei nicht auf Hardware anwendbar, sollte sich Tesla ansehen. Im Oktober 2021 tweetete Elon Musk über das Rollout von Version 10.2 der Full Self-Driving Beta an 1'000 Besitzer mit einem perfekten Safety Score von 100/100. Was sagt uns das?\nTeslas Software ist modularisiert. Sie können einzelne Module über die Luft aktualisieren. Sie machen Canary Releases an bestimmte Nutzergruppen. Sie berechnen Safety Scores durch Observability. Acht Tage später wurde Version 10.3 an eine grössere Gruppe ausgerollt. Als ein Problem auftrat, machte Tesla einen Rollback und kommunizierte, dass dies erwartet war. Weniger als 24 Stunden später deployten sie 10.3.1 als Fix-Forward.\nDas sind Canary Releasing, Rollbacks, Fix-Forward und Observability, alles in einer regulierten Umgebung mit Autos auf öffentlichen Strassen. Die Unternehmen, die Lean, Agile und DevOps in Hardware übernehmen, werden bald den Markt dominieren, genau wie Netflix, Google und Facebook es vor zwanzig Jahren in der Software getan haben.\nDie 24 Schlüssel-Capabilities aus Accelerate # Das Buch \u0026ldquo;Accelerate: The Science Behind DevOps\u0026rdquo; identifizierte 24 Schlüssel-Capabilities, die leistungsstarke Organisationen auszeichnen. Diese sind in fünf Bereiche gruppiert:\nContinuous Delivery: Versionskontrolle für alles (nicht nur Quellcode), automatisierte Deployments, Continuous Integration, Trunk-Based Development, Testautomatisierung, Testdatenmanagement, Shift-Left bei Security und Continuous Delivery auf Staging.\nArchitektur: Lose gekoppelte Architekturen und befähigte Teams, die eigene Entscheidungen treffen können.\nProdukt und Prozess: Kundenfeedback-Schleifen, Wertstromorganisation, kleine Batches und Raum für Experimente.\nLean Management: Eliminierung schädlicher Change Approval Boards, Monitoring, proaktive Benachrichtigungen, WIP-Limits und Visualisierung der Arbeit.\nKultur: Generative Organisationskultur, in der das Finden von Bugs als Lernen gefeiert wird, Unterstützung für kontinuierliches Lernen, teamübergreifende Zusammenarbeit, Arbeitszufriedenheit und transformationale Führung.\nDie Forschung zeigt, dass High Performer 973-mal mehr Deployments in Produktion erreichen als Low Performer. Unternehmen, die DevOps praktizieren, haben eine schnellere Time-to-Market, mehr Wert fürs Geld, höhere Qualität, höhere Kundenzufriedenheit und top-qualifizierte Mitarbeitende.\nKontinuierliches Testen und Qualität # Joe Justice, Agile Coach und ehemaliger Tesla-Mitarbeiter, sagte, dass 50% des Geldes, das ein Musk-Unternehmen in ein neues Produkt investiert, in automatisiertes Testen fliesst. In den meisten Unternehmen, die ich sehe, geht nur ein Bruchteil ins Testen. Das beschleunigt die Entwicklung anfangs, aber irgendwann stagniert der Fortschritt, weil die Qualität abnimmt.\nDer Wandel vom traditionellen V-Modell zum modernen Testen ist dramatisch. In der alten Welt konnten Monate zwischen dem Schreiben eines Features und dem Testen vergehen. Mit Behavior Driven Development (BDD) definieren wir Akzeptanzkriterien im \u0026ldquo;given, when, then\u0026rdquo;-Format und bauen Qualität von Anfang an ein. Mit Test-Driven Development (TDD) schreiben wir Tests vor dem Code. Die traditionelle Testpyramide wird umgedreht: viele Unit-Tests (schnell und günstig), einige Integrationstests und nur wenige End-to-End-Tests. Der Fokus verschiebt sich von \u0026ldquo;jeden Bug finden\u0026rdquo; zu \u0026ldquo;Bugs verhindern\u0026rdquo; durch einen risikobasierten Ansatz.\n\u0026ldquo;Im traditionellen Modell liegt der Fokus darauf, jeden Bug zu finden, was es sehr langsam macht. In der agilen Testpyramide wollen wir Bugs verhindern. Es ist ein risikobasierter Ansatz.\u0026rdquo;\nPlatform Engineering: DevOps skalieren # Wenn Teams DevOps praktizieren, braucht jedes einzelne Infrastruktur, CI/CD-Pipelines, Monitoring, Security-Tools und Zugangsmanagement. Bei Skalierung entstehen massive Redundanz, Inkonsistenz und kognitive Überlastung. Jedes Team erfindet das Rad neu.\nPlatform Engineering löst dieses Problem. Ein dediziertes Platform-Team baut und pflegt eine standardisierte Plattform mit allen Tools, die Teams brauchen: Application Runtime, Developer Experience, automatisierte DevSecOps-Pipelines, Access und Identity Management sowie Observability. Die Produktteams besitzen und betreiben weiterhin ihre Produkte nach dem Prinzip \u0026ldquo;you build it, you run it.\u0026rdquo; Das Platform-Team stellt lediglich das Fundament bereit.\nDie wichtige Unterscheidung: Kunden zahlen nicht für Ihre Plattform. Sie zahlen für Ihre Produkte. Aber die Plattform generiert Wert für Ihre Teams und ermöglicht es ihnen, bessere Produkte schneller zu bauen.\nDie Digitale Fabrik aufbauen # Die Digitale Fabrik ist das ganzheitliche Framework, das alles zusammenbringt. Auf der Portfolio-Ebene richtet der Verwaltungsrat grosse Ideen an der Unternehmensvision aus. Auf der Produkt-Ebene bricht das Produktmanagement Epics in Features herunter. Auf der Team-Ebene arbeiten befähigte Teams agil an ihren Modulen, unterstützt durch eine standardisierte Plattform.\nDies erzeugt einen kontinuierlichen Kreislauf: schnelle Lieferung von Features an den Kunden, schnelles Feedback vom Kunden und kontinuierliches Lernen. Platform Engineering baut das Fundament. DevOps-Teams praktizieren darauf. Und die Digitale Fabrik orchestriert das gesamte System.\n\u0026ldquo;Platform Engineering baut Ihre Plattform, die das Fundament Ihrer Digitalen Fabrik ist, und ermöglicht es Ihren Teams, DevOps zu praktizieren.\u0026rdquo;\nKernaussagen # Produkte statt Projekte. Hören Sie auf, Features zu maximieren, und fangen Sie an, Kundenprobleme zu lösen. DevOps ermöglicht den Wandel vom Projektdenken zum Produktdenken.\nQualität ist nicht optional. Investieren Sie von Anfang an in automatisiertes Testen. Nutzen Sie BDD, TDD und eine risikobasierte Teststrategie. Die Kosten für ausgelassene Tests holen Sie immer ein.\nPlatform Engineering ermöglicht DevOps im grossen Massstab. Eine standardisierte Plattform eliminiert Redundanz, reduziert die kognitive Last und lässt Produktteams sich auf die Wertlieferung konzentrieren.\nBauen Sie eine Digitale Fabrik. Verbinden Sie Strategie mit Ausführung durch Lean Portfolio Management, Platform Engineering und befähigte DevOps-Teams. So industrialisieren Sie die Embedded-Softwareentwicklung.\nLernen Sie von Tesla. Selbst in regulierten, hardware-lastigen Umgebungen sind DevOps-Praktiken wie Canary Releases, Rollbacks und Observability nicht nur möglich, sie sind ein Wettbewerbsvorteil.\n","date":"17. February 2024","externalUrl":null,"permalink":"/de/blogs/devops-in-der-embedded-welt/","section":"Blogs","summary":"Viele Menschen denken immer noch, DevOps sei nur für Webanwendungen und Cloud-Services relevant. Die Realität zeigt jedoch klar: Unternehmen, die DevOps-Prinzipien auf Embedded-Systeme anwenden, überholen ihre Konkurrenz. In diesem Vortrag, den ich bei einem DevOps-Meetup in München gehalten habe, zeige ich, warum Embedded-Teams DevOps brauchen und wie man eine Digitale Fabrik aufbaut, die kontinuierliche Wertlieferung ermöglicht, auch für Hardware-Produkte.\n","title":"DevOps in der Embedded-Welt: Von Silos zur Digitalen Fabrik","type":"blogs"},{"content":"","date":"17 February 2024","externalUrl":null,"permalink":"/en/tags/embedded-systems/","section":"Tags","summary":"","title":"Embedded Systems","type":"tags"},{"content":"","date":"17. February 2024","externalUrl":null,"permalink":"/de/tags/embedded-systeme/","section":"Tags","summary":"","title":"Embedded-Systeme","type":"tags"},{"content":"","date":"17 February 2024","externalUrl":null,"permalink":"/en/tags/tesla/","section":"Tags","summary":"","title":"Tesla","type":"tags"},{"content":"This is a recording of my presentation at the DevOps Meetup Zurich from January 2024. The talk covers Developer Experience and Platform Engineering, including why Platform Engineering has emerged, how it fits into the Digital Factory concept, and a live demo of the Platform Plane, the internal developer platform we built together with LGT.\nThe Problem: Walls of Confusion # In many companies, the picture looks like this: business creates requirements in Word documents and Jira tickets, then throws them over a wall of confusion to development. Development implements something and throws it over another wall to testing. Testing checks it, and it goes over yet another wall to operations. Operations struggles to get it running, and the end result reaches the customer or business, who says: \u0026ldquo;What is this? This is not what we wanted.\u0026rdquo;\nThe root cause is the silo organization. Business, development, testing, and operations all work in separate silos with different goals. There is no alignment. The value stream is broken by these walls of confusion. And working in such an environment is not fun, so the developer experience is quite low.\nDevOps is a mindset, a culture, and a set of technical practices which allows us to organize ourselves across the value stream so that all people work together on a product, not on a project.\nIs DevOps Dead? The Cognitive Load Problem # Science has looked at DevOps extensively. The book \u0026ldquo;Accelerate\u0026rdquo; and the State of DevOps reports show impressive numbers: high performers achieve 973 times more deployments to production than low performers. DevOps delivers faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees.\nSo why the articles claiming \u0026ldquo;DevOps is dead\u0026rdquo; and \u0026ldquo;Platform Engineering is the new trend\u0026rdquo;? The answer lies in cognitive load. When teams embrace \u0026ldquo;you build it, you run it,\u0026rdquo; they need infrastructure, container runtimes, CI/CD pipelines, monitoring, security tooling, cost management, access and identity, and they still need to implement features. When you multiply this across multiple product teams, the inconsistencies, redundancies, and complexity become overwhelming.\nThe Digital Factory: Scaling DevOps # The solution is not going back to silo IT. The solution is the Digital Factory model. At the top level, a board of directors has a vision and a portfolio of ideas. The product management level breaks big ideas into features. Product teams work in an agile way, breaking features into user stories.\nWhen a new team needs to start, the Platform Engineering team provides them with a standardized CI/CD pipeline so they can begin delivering value immediately. The whole system works in the three ways of DevOps: continuously delivering fast value, getting feedback back, and continuously learning.\nThe Digital Factory has four layers:\nLean Portfolio Management connecting strategy with execution Product Management organizing multiple teams working on products Product Teams doing DevOps and owning their products Platform Team creating the foundation that enables teams to do DevOps Platform Engineering in Detail # The most important thing about Platform Engineering: the Platform Team creates an internal product that contains all the tools needed to deliver the company\u0026rsquo;s products. This includes application runtime, developer experience tooling, access and identity, observability and monitoring, and the CI/CD pipeline.\nA critical distinction: the Platform Team does not operate the products. It enables the teams to operate their own products. The product teams create their own CI/CD pipelines and dashboards based on the platform. The Platform Team generates value for the teams, and the product teams generate value for the customer.\nGartner predicts that Platform Engineering is one of the strategic technology trends of 2024. By roughly 2027, they predict that 75% of organizations will have adopted or created their own DevOps platform.\nThe Platform Plane: A Live Demo # Last year, LGT, a private bank in Liechtenstein, came to Zühlke wanting to create such a platform. They wanted a co-investment to build a platform and put it into an association so others could use it too. Together we built the Platform Plane and established the Open Platform Plane Association.\nThe platform includes:\nApplication Runtime with Kubernetes as a service, API Gateway, and Service Mesh Developer Experience with a portal, CLI, and tunneling into clusters Automated DevSecOps with secret detection, license scanning, and static application security testing Access and Identity allowing morning onboarding and afternoon offboarding with immediate effect on all tools Centralized Security with network separation and policy enforcement Observability with automatically created dashboards and FinOps tracking GitOps with CI/CD pipelines, repositories, and secret management In the demo, I showed how the portal integrates tools like GitLab, Kubernetes, Grafana, Argo CD, and HashiCorp Vault through adapters. This adapter pattern is key: it allows any tool to be replaced when needed, as long as it has an API.\nThe platform automatically scans repositories for security issues, rotates secrets when found in source code, creates documentation, and provides container image vulnerability analysis. When adding a new application like Microsoft SQL Server, everything is set up in a fully standardized way, including naming, passwords, sizing, dashboards, and observability integration.\nWe are entering the Age of Industrialization of Software Development. Platform Engineering builds the foundation of your Digital Factory and enables your teams to do DevOps.\nKey Takeaways # Walls of confusion from silo organizations break the value stream and kill developer experience DevOps is not dead. Platform Engineering enables teams to do DevOps by reducing cognitive load The Digital Factory model connects strategy with execution through Lean Portfolio Management, Product Management, Product Teams, and a Platform Team The Platform Team creates an internal product for other teams. It does not operate the products. The Platform Plane demonstrates what an enterprise developer platform looks like in practice, with integrated DevSecOps, observability, and self-service capabilities By 2027, Gartner predicts 75% of organizations will have their own DevOps platform ","date":"11 February 2024","externalUrl":null,"permalink":"/en/blogs/devops-meetup-zurich-2024-platform-engineering/","section":"Blogs","summary":"This is a recording of my presentation at the DevOps Meetup Zurich from January 2024. The talk covers Developer Experience and Platform Engineering, including why Platform Engineering has emerged, how it fits into the Digital Factory concept, and a live demo of the Platform Plane, the internal developer platform we built together with LGT.\n","title":"DevOps Meetup Zurich 2024: Developer Experience and Platform Engineering","type":"blogs"},{"content":"Dies ist eine Aufzeichnung meines Vortrags am DevOps Meetup Zürich vom Januar 2024. Der Vortrag behandelt Developer Experience und Platform Engineering: Warum Platform Engineering entstanden ist, wie es in das Digital-Factory-Konzept passt, und eine Live-Demo der Platform Plane, der internen Entwicklerplattform, die wir zusammen mit der LGT entwickelt haben.\nDas Problem: Walls of Confusion # In vielen Unternehmen sieht das Bild so aus: Das Business erstellt Anforderungen in Word-Dokumenten und Jira-Tickets und wirft sie über eine Wall of Confusion zur Entwicklung. Die Entwicklung implementiert etwas und wirft es über eine weitere Mauer zum Testing. Das Testing prüft es, und es geht über noch eine Mauer zum Betrieb. Der Betrieb kämpft damit, alles zum Laufen zu bringen, und das Endergebnis erreicht den Kunden oder das Business, die sagen: \u0026ldquo;Was ist das? Das wollten wir nicht.\u0026rdquo;\nDie Ursache ist die Siloorganisation. Business, Entwicklung, Testing und Betrieb arbeiten alle in separaten Silos mit unterschiedlichen Zielen. Es gibt keine Abstimmung. Der Value Stream ist durch diese Walls of Confusion gebrochen. Und in einer solchen Umgebung zu arbeiten macht keinen Spass, die Developer Experience ist entsprechend niedrig.\nDevOps ist ein Mindset, eine Kultur und ein Satz von technischen Praktiken, die uns erlauben, uns über den gesamten Value Stream hinweg zu organisieren, sodass alle Menschen gemeinsam an einem Produkt arbeiten, nicht an einem Projekt.\nIst DevOps tot? Das Problem der kognitiven Last # Die Wissenschaft hat DevOps eingehend untersucht. Das Buch \u0026ldquo;Accelerate\u0026rdquo; und die State of DevOps Reports zeigen beeindruckende Zahlen: High Performer erreichen 973-mal mehr Deployments in Produktion als Low Performer. DevOps liefert schnellere Time to Market, mehr Wert für das Geld, höhere Qualität, höhere Kundenzufriedenheit und top qualifizierte Mitarbeitende.\nWarum also die Artikel, die behaupten \u0026ldquo;DevOps ist tot\u0026rdquo; und \u0026ldquo;Platform Engineering ist der neue Trend\u0026rdquo;? Die Antwort liegt in der kognitiven Last. Wenn Teams \u0026ldquo;You build it, you run it\u0026rdquo; leben, brauchen sie Infrastruktur, Container-Runtimes, CI/CD-Pipelines, Monitoring, Security-Tooling, Kostenmanagement, Access und Identity, und sie müssen trotzdem noch Features implementieren. Multipliziert man das über mehrere Produkt-Teams, werden die Inkonsistenzen, Redundanzen und die Komplexität überwältigend.\nDie Digital Factory: DevOps skalieren # Die Lösung ist nicht, zur Silo-IT zurückzukehren. Die Lösung ist das Digital-Factory-Modell. Auf der obersten Ebene hat ein Verwaltungsrat eine Vision und ein Portfolio von Ideen. Das Produktmanagement bricht grosse Ideen in Features herunter. Produkt-Teams arbeiten agil und zerlegen Features in User Stories.\nWenn ein neues Team starten muss, stellt das Platform-Engineering-Team eine standardisierte CI/CD-Pipeline bereit, sodass das Team sofort mit der Wertschöpfung beginnen kann. Das gesamte System funktioniert nach den drei Wegen von DevOps: kontinuierlich schnell Wert liefern, Feedback zurückbekommen und kontinuierlich lernen.\nDie Digital Factory hat vier Ebenen:\nLean Portfolio Management verbindet Strategie mit Umsetzung Produktmanagement organisiert mehrere Teams, die an Produkten arbeiten Produkt-Teams praktizieren DevOps und verantworten ihre Produkte Platform-Team schafft die Grundlage, die den Teams DevOps ermöglicht Platform Engineering im Detail # Das Wichtigste am Platform Engineering: Das Platform-Team erstellt ein internes Produkt, das alle Tools enthält, die für die Produktentwicklung des Unternehmens benötigt werden. Dazu gehören Application Runtime, Developer-Experience-Tooling, Access und Identity, Observability und Monitoring sowie die CI/CD-Pipeline.\nEine entscheidende Unterscheidung: Das Platform-Team betreibt nicht die Produkte. Es befähigt die Teams, ihre eigenen Produkte zu betreiben. Die Produkt-Teams erstellen ihre eigenen CI/CD-Pipelines und Dashboards basierend auf der Plattform. Das Platform-Team generiert Wert für die Teams, und die Produkt-Teams generieren Wert für den Kunden.\nGartner sagt voraus, dass Platform Engineering einer der strategischen Technologietrends 2024 ist. Bis etwa 2027 prognostizieren sie, dass 75% der Organisationen ihre eigene DevOps-Plattform übernommen oder erstellt haben werden.\nDie Platform Plane: Eine Live-Demo # Letztes Jahr kam die LGT, eine Privatbank in Liechtenstein, zu Zühlke mit dem Wunsch, eine solche Plattform zu bauen. Sie wollten ein Co-Investment, um eine Plattform zu entwickeln und sie in einen Verein zu überführen, damit auch andere sie nutzen können. Zusammen bauten wir die Platform Plane und gründeten die Open Platform Plane Association.\nDie Plattform umfasst:\nApplication Runtime mit Kubernetes as a Service, API Gateway und Service Mesh Developer Experience mit einem Portal, CLI und Tunneling in Cluster Automatisiertes DevSecOps mit Secret Detection, License Scanning und statischer Sicherheitsanalyse Access und Identity mit Onboarding am Morgen und Offboarding am Abend, mit sofortiger Wirkung auf alle Tools Zentralisierte Sicherheit mit Netzwerktrennung und Policy-Durchsetzung Observability mit automatisch erstellten Dashboards und FinOps-Tracking GitOps mit CI/CD-Pipelines, Repositories und Secret Management In der Demo habe ich gezeigt, wie das Portal Tools wie GitLab, Kubernetes, Grafana, Argo CD und HashiCorp Vault über Adapter integriert. Dieses Adapter-Muster ist der Schlüssel: Es ermöglicht den Austausch jedes Tools bei Bedarf, solange es eine API hat.\nDie Plattform scannt Repositories automatisch auf Sicherheitsprobleme, rotiert gefundene Secrets im Quellcode, erstellt Dokumentation und bietet Schwachstellenanalyse für Container-Images. Beim Hinzufügen einer neuen Anwendung wie Microsoft SQL Server wird alles vollständig standardisiert eingerichtet, inklusive Namensgebung, Passwörter, Dimensionierung, Dashboards und Observability-Integration.\nWir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein. Platform Engineering bildet die Grundlage eurer Digital Factory und ermöglicht euren Teams, DevOps zu machen.\nKernaussagen # Walls of Confusion aus Siloorganisationen unterbrechen den Value Stream und zerstören die Developer Experience DevOps ist nicht tot. Platform Engineering ermöglicht es Teams, DevOps zu machen, indem es die kognitive Last reduziert Das Digital-Factory-Modell verbindet Strategie mit Umsetzung über Lean Portfolio Management, Produktmanagement, Produkt-Teams und ein Platform-Team Das Platform-Team erstellt ein internes Produkt für andere Teams. Es betreibt nicht die Produkte. Die Platform Plane zeigt, wie eine Enterprise-Entwicklerplattform in der Praxis aussieht, mit integriertem DevSecOps, Observability und Self-Service-Fähigkeiten Bis 2027 prognostiziert Gartner, dass 75% der Organisationen ihre eigene DevOps-Plattform haben werden ","date":"11. February 2024","externalUrl":null,"permalink":"/de/blogs/devops-meetup-zuerich-2024-platform-engineering/","section":"Blogs","summary":"Dies ist eine Aufzeichnung meines Vortrags am DevOps Meetup Zürich vom Januar 2024. Der Vortrag behandelt Developer Experience und Platform Engineering: Warum Platform Engineering entstanden ist, wie es in das Digital-Factory-Konzept passt, und eine Live-Demo der Platform Plane, der internen Entwicklerplattform, die wir zusammen mit der LGT entwickelt haben.\n","title":"DevOps Meetup Zürich 2024: Developer Experience und Platform Engineering","type":"blogs"},{"content":"In dieser Episode von Tech Chat mit Navika Chadha, Cloud Engineer und Microsoft MVP, hatten wir ein ausführliches Gespräch über Platform Engineering: Was es ist, wie es sich von DevOps unterscheidet, warum Unternehmen es einführen sollten und welche Fähigkeiten benötigt werden. Die Diskussion schneidet durch den Buzz und die Click-Bait-Überschriften, um zu erklären, warum DevOps sehr lebendig ist und wie Platform Engineering es ergänzt.\nWas ist Platform Engineering? # Platform Engineering dreht sich um Befähigung. Ein Platform-Engineering-Team stellt eine Plattform als internes Produkt für die anderen Teams bereit, die Produkte entwickeln. Diese Plattform sollte alles enthalten, was die Produkt-Teams brauchen, um ihre Produkte schneller und effizienter zu entwickeln.\nDas Platform-Team generiert Wert für die Produkt-Teams, und die Produkt-Teams generieren Wert für den Kunden. Der Grund, warum viele Unternehmen in diese Richtung gehen, ist einfach: Die kognitive Last auf den Produkt-Teams stieg. Sie mussten zu viele Tools, zu viel Technologie, zu viel Komplexität bewältigen. Es gab Redundanzen über Teams hinweg. Platform Engineering reduziert diese kognitive Last durch Standardisierung.\nPlatform Engineering ermöglicht es anderen Teams, DevOps zu machen. Es ist ein Enabler, kein Ersatz.\nWarum sollten Unternehmen Platform Engineering einführen? # Die Vorteile fliessen in zwei Richtungen. Für interne Teams (Softwareentwickler) steigert die Plattform die Effizienz durch Automatisierung und standardisiertes Tooling. Für Kunden und Nutzer resultiert es in konsistenterem, qualitativ hochwertigerem Output. Es ist eine Win-win-Situation.\nPlatform Engineering ist im Wesentlichen Standardisierung. Man gibt Teams einen \u0026ldquo;Golden Path,\u0026rdquo; einen empfohlenen Weg, Software zu bauen und bereitzustellen. Für etwa 80% der Anwendungsfälle sollte die Plattform die richtige Lösung sein. Aber man muss Teams immer die Freiheit lassen, auszubrechen und eigene Wege zu gehen, wenn es nötig ist.\nWelche Fähigkeiten sollte eine Plattform haben? # Jede Plattform sieht je nach Unternehmensbedürfnissen anders aus. Aber generisch erscheinen einige Fähigkeiten konsistent:\nApplication Runtime: Wo Anwendungen laufen. Das kann On-Premise sein, Cloud, Docker, virtuelle Maschinen oder ein Kubernetes-Cluster. Automatisierung: Automatisierung wiederkehrender Aufgaben wie Zertifikatsrotation, Passwortwechsel und Schwachstellenmanagement (Container-Scanning, SCA, SBOM). Observability: Standard-Dashboards, Tracing und Monitoring, die bereits vorhanden sind, damit Teams das nicht jedes Mal von Grund auf aufbauen müssen. CI/CD-Pipelines: Vorgefertigte Pipelines mit sinnvollen Standardwerten, die Teams sofort für den Bau ihrer Produkte nutzen können. Die Kernerkenntnis: Plattformen drehen sich hauptsächlich um wiederverwendbare, wiederholbare Aufgaben. Anstatt jedes Mal manuell von vorne anzufangen, standardisiert man, damit sich Teams auf das Wesentliche konzentrieren können: Features liefern.\nDevOps vs. Platform Engineering: Ergänzung, kein Wettbewerb # Es gibt viel Buzz, der behauptet, Platform Engineering werde DevOps ersetzen. Aber vieles davon ist Click-Bait. Hier ist die Realität:\nDie DevOps-Bewegung begann damit, Entwicklung und Betrieb zusammenzubringen, und entwickelte sich dann in Richtung kontinuierlicher Wertlieferung, indem alle Menschen über den Value Stream hinweg einbezogen wurden. Das führte uns von Projekten zu Produkten. Aber das hat seinen Preis: Man muss Silos abbauen, was bedeutet, dass die kognitive Last auf den Teams steigt, weil sie alles selbst handhaben müssen.\nPlatform Engineering entstand als Antwort auf diese kognitive Last. Ein Platform-Engineering-Team nutzt DevOps-Praktiken, um die Plattform zu bauen. Produkt-Teams nutzen DevOps-Praktiken auf dieser Plattform, um ihre Produkte zu bauen. DevOps ist nicht tot. Es ist nach wie vor die Grundlage.\nPlatform Engineering und DevOps ergänzen sich. Platform Engineering ist das starke Fundament, das DevOps effizienter macht. Aber wenn man ein Startup mit einem Team ist, braucht man kein Platform Engineering. Man macht einfach DevOps. Der Platform-Engineering-Fall kommt ins Spiel, wenn man mehrere Teams mit Redundanzen hat und schneller werden will, während man die Kosten senkt.\nPlatform Engineering Tools # Die Tool-Landschaft wächst rasant. Microsoft hat Tools in diesem Bereich veröffentlicht. OpenShift kann als Platform-Engineering-Tool betrachtet werden. Backstage ist ein sehr gutes Beispiel für ein Developer-Portal. Viele weitere Tools entstehen, und ich erwarte bald einen Gartner-Quadranten für Platform-Engineering-Tools.\nWichtig zu erkennen: Als Unternehmen oder Platform-Engineering-Team muss man schauen, was die Produkt-Teams wirklich brauchen. Ist es eine Standardplattform von der Stange oder eine massgeschneiderte Plattform, die auf anderen Plattformen aufbaut? Normalerweise bauen Unternehmen Plattformen auf Plattformen, indem sie Fähigkeiten stapeln. Der Schlüssel ist zu identifizieren, welche Fähigkeiten man braucht, welche man von bestehenden Plattformen übernehmen kann und welche man selbst bauen muss.\nSicherheit und Kostenüberlegungen # Beim Bau einer eigenen Plattform gelten alle Sicherheitsmassnahmen. Es ist ein internes Produkt, also braucht man Penetrationstests, Sicherheitstests, License Scanning, SBOM-Analyse, alles. Eine gut gebaute eigene Plattform kann absolut sicher sein.\nDie grössere Frage sind die Kosten. Der Bau einer Plattform erfordert mindestens ein Team von fünf bis sieben hochqualifizierten Personen mit 10+ Jahren Erfahrung in der Softwareentwicklung. Sie brauchen tiefes Wissen in Kubernetes, Pipelines, Sicherheit, Netzwerken, Backups und IT-Betrieb. Diese Investition ist erheblich. Aber für ein Unternehmen mit rund 1.000 Entwicklern und spezialisierten Entwicklungsbedürfnissen macht der Bau einer eigenen Plattform absolut wirtschaftlich Sinn. Für kleinere Organisationen kann eine Standardplattform kosteneffektiver sein.\nFähigkeiten für Platform Engineers # Platform Engineering ist eine junge Disziplin, aber die Anforderungen an die Fähigkeiten werden klarer. Ein typisches Platform-Team braucht vielfältige Expertise:\nFrontend/UX: Portal-Interfaces bauen, oft auf Basis von Tools wie Backstage Kubernetes: Tiefes Wissen in Container-Orchestrierung ist essentiell Sicherheit: Verständnis von Schwachstellenmanagement, Netzwerkrichtlinien und Compliance Pipelines: Expertise in CI/CD-Automatisierung und Integration Netzwerke: Wissen über Service Meshes, Ingress und Netzwerktopologie Das Standardprofil eines Platform Engineers ist jemand mit breitem Kubernetes-Wissen, Verständnis von Softwareentwicklungspraktiken, Kenntnis des Kunden (Software-Engineering-Teams) und Fähigkeiten in Pipeline-Automatisierung. Normalerweise deckt ein diverses Team verschiedene Spezialisierungen ab, anstatt dass eine Person alles abdeckt.\nKernaussagen # Platform Engineering befähigt Produkt-Teams, DevOps effizienter zu machen, indem es die kognitive Last reduziert DevOps ist nicht tot. Platform Engineering und DevOps ergänzen sich. Platform Engineering bietet die Grundlage, DevOps ist die Praxis. Plattformen sollten einen Golden Path für etwa 80% der Anwendungsfälle bieten und Teams Freiheit für die restlichen 20% lassen Die Build-vs.-Buy-Entscheidung hängt von Teamgrösse, Spezialisierungsbedarf und Kosten ab. Unternehmen mit 1.000+ Entwicklern können eigene Plattformen rechtfertigen. Platform Engineers brauchen ein vielfältiges Fähigkeitsprofil über Kubernetes, Sicherheit, Pipelines und Developer Experience Jede Plattform sollte die kognitive Last reduzieren und die Time to Productivity für neue Teammitglieder beschleunigen ","date":"11. February 2024","externalUrl":null,"permalink":"/de/blogs/platform-engineering-vs-devops-effizienz-erschliessen/","section":"Blogs","summary":"In dieser Episode von Tech Chat mit Navika Chadha, Cloud Engineer und Microsoft MVP, hatten wir ein ausführliches Gespräch über Platform Engineering: Was es ist, wie es sich von DevOps unterscheidet, warum Unternehmen es einführen sollten und welche Fähigkeiten benötigt werden. Die Diskussion schneidet durch den Buzz und die Click-Bait-Überschriften, um zu erklären, warum DevOps sehr lebendig ist und wie Platform Engineering es ergänzt.\n","title":"Effizienz erschliessen: Platform Engineering vs. DevOps","type":"blogs"},{"content":"In this episode of Tech Chat with Navika Chadha, a Cloud Engineer and Microsoft MVP, we had a deep conversation about Platform Engineering: what it is, how it differs from DevOps, why companies should adopt it, and what skills are needed. The discussion cuts through the buzz and click-bait headlines to explain why DevOps is very much alive and how Platform Engineering complements it.\nWhat Is Platform Engineering? # Platform Engineering is about enablement. A Platform Engineering team provides a platform as an internal product to the other teams that create products. This platform should contain everything the product teams need to develop their products faster and more efficiently.\nThe platform team generates value for the product teams, and the product teams generate value for the client. The reason many companies are moving in this direction is simple: the cognitive load on product teams was rising. They needed to handle too many tools, too much technology, too much complexity. There were redundancies across teams. Platform Engineering reduces that cognitive load through standardization.\nPlatform Engineering enables other teams to do DevOps. It is an enabler, not a replacement.\nWhy Should Companies Adopt Platform Engineering? # The benefits flow in two directions. For internal teams (software developers), the platform increases efficiency through automation and standardized tooling. For clients and users, it results in more consistent, higher quality output. It is a win-win situation.\nPlatform Engineering is essentially about standardization. You give teams a \u0026ldquo;golden path,\u0026rdquo; a recommended way of building and deploying software. For about 80% of use cases, the platform should be the right solution. But you always need to allow teams the freedom to break out and do their own thing when necessary.\nWhat Capabilities Should a Platform Have? # Every platform will look different depending on the company\u0026rsquo;s needs. But generically, several capabilities appear consistently:\nApplication Runtime: Where applications run. This could be on-premise, cloud, Docker, virtual machines, or a Kubernetes cluster. Automation: Automating repetitive tasks like certificate rotation, password changes, and vulnerability management (container scanning, SCA, SBOM). Observability: Default dashboards, tracing, and monitoring already in place so teams do not need to build that from scratch every time. CI/CD Pipelines: Pre-built pipelines with sensible defaults that teams can use immediately for building their products. The key insight: platforms are mostly about reusable, repeatable tasks. Instead of starting from scratch manually every time, you standardize so teams can focus on what matters most, delivering features.\nDevOps vs. Platform Engineering: Complement, Not Compete # There is a lot of buzz claiming Platform Engineering will replace DevOps. But much of that is click-bait. Here is the reality:\nThe DevOps movement started by combining development and operations, then evolved toward continuously delivering value by incorporating all people working across the value stream. This moved us from projects to products. But this comes with a price: you need to remove silos, which means the cognitive load on teams rises because they need to handle everything.\nPlatform Engineering was born as a response to that cognitive load. A platform engineering team uses DevOps practices to build the platform. Product teams use DevOps practices on top of that platform to build their products. DevOps is not dead. It is still the foundation.\nPlatform Engineering and DevOps complement each other. Platform Engineering is the strong foundation that makes DevOps more efficient. But if you are a startup with one team, you do not need Platform Engineering. You just do DevOps. The Platform Engineering case comes into play when you have multiple teams with redundancies and you want to get faster while bringing down costs.\nPlatform Engineering Tools # The tooling landscape is growing rapidly. Microsoft has released tools in this space. OpenShift can be looked at as a platform engineering tool. Backstage is a very good example of a developer portal. Many more tools are emerging, and I expect a Gartner quadrant for platform engineering tools soon.\nWhat is important to recognize: as a company or platform engineering team, you need to look at what your product teams actually need. Is it a standard platform off the shelf, or a custom-built platform assembled on top of other platforms? Usually, companies end up building platforms on top of platforms, stacking capabilities. The key is to identify which capabilities you need, which you can borrow from existing platforms, and which you need to build yourself.\nSecurity and Cost Considerations # When building a custom platform, all security measures apply. It is an internal product, so you need penetration testing, security testing, license scanning, SBOM analysis, everything. A well-built custom platform can be absolutely secure.\nThe bigger question is cost. Building a platform requires at least a team of five to seven highly skilled people with 10+ years of experience in software development. They need deep knowledge in Kubernetes, pipelines, security, networking, backups, and IT operations. That investment is significant. But for a company with around 1,000 developers and specialized development needs, building a custom platform absolutely makes business sense. For smaller organizations, using an off-the-shelf platform may be more cost-effective.\nSkills for Platform Engineers # Platform Engineering is a young discipline, but the skill requirements are becoming clear. A typical platform team needs diverse expertise:\nFrontend/UX: Building portal interfaces, often on top of tools like Backstage Kubernetes: Deep knowledge of container orchestration is essential Security: Understanding vulnerability management, network policies, and compliance Pipelines: Expertise in CI/CD automation and integration Networking: Knowledge of service meshes, ingress, and network topology The default profile of a platform engineer is someone with broad Kubernetes knowledge, understanding of software development practices, knowledge of the customer (software engineering teams), and skills in pipeline automation. Usually, a diverse team covers different specializations rather than one person covering everything.\nKey Takeaways # Platform Engineering is about enabling product teams to do DevOps more efficiently by reducing cognitive load DevOps is not dead. Platform Engineering and DevOps complement each other. Platform Engineering provides the foundation, DevOps is the practice. Platforms should provide a golden path for about 80% of use cases while allowing teams freedom for the remaining 20% The build vs. buy decision depends on team size, specialization needs, and cost. Companies with 1,000+ developers can justify custom platforms. Platform engineers need a diverse skill set spanning Kubernetes, security, pipelines, and developer experience Every platform should reduce cognitive load and accelerate the time to productivity for new team members ","date":"11 February 2024","externalUrl":null,"permalink":"/en/blogs/platform-engineering-vs-devops-unlocking-efficiency/","section":"Blogs","summary":"In this episode of Tech Chat with Navika Chadha, a Cloud Engineer and Microsoft MVP, we had a deep conversation about Platform Engineering: what it is, how it differs from DevOps, why companies should adopt it, and what skills are needed. The discussion cuts through the buzz and click-bait headlines to explain why DevOps is very much alive and how Platform Engineering complements it.\n","title":"Unlocking Efficiency: Platform Engineering vs. DevOps","type":"blogs"},{"content":"Für die 90 Days of DevOps Community habe ich das Konzept der digitalen Fabrik vorgestellt. Nach Jahren von DevOps-Transformationen in verschiedenen Branchen bei Zühlke habe ich einen ganzheitlichen Ansatz zur Skalierung von DevOps entwickelt, der über Tools und Pipelines hinausgeht. In diesem Vortrag erkläre ich, warum wir immer noch mit Mauern der Verwirrung kämpfen, wie Platform Engineering Teams befähigt, DevOps im grossen Massstab zu betreiben, und wie digitale Fabriken alles zusammenbringen.\nDer gebrochene Wertstrom # Das Muster, das ich in Unternehmen für Unternehmen sehe, ist immer dasselbe. Das Business hat grossartige Ideen. Sie packen sie in Word-Dokumente und Jira-Tickets und werfen sie über die Mauer der Verwirrung zur Entwicklung. Die Entwicklung baut etwas und wirft es zum Testing. Das Testing prüft etwas (das selten mit der ursprünglichen Spezifikation übereinstimmt) und wirft es zum Betrieb. Der Betrieb sagt: \u0026ldquo;Das wird in der Produktion nie funktionieren.\u0026rdquo; Aber irgendwie schaffen sie es. Der Kunde bekommt das Ergebnis und sagt: \u0026ldquo;Das ist nicht das, was wir wollten.\u0026rdquo;\nDer Wertstrom wird durch diese Mauern der Verwirrung gebrochen. Sie entstehen aus Silo-Organisationen mit unterschiedlichen Zielen, fehlender Abstimmung, langsamen und ineffektiven Prozessen und kulturellem Widerstand. Sicherheit und Qualität werden zum Nachgedanken statt eingebauter Praxis.\nVon Projekten zu Produkten # Diese Probleme haben ihren Ursprung in der Art, wie wir Arbeit organisieren. Früher machten wir Wasserfall-Projekte mit fixem Scope, Budget und Zeit. Dann brachte Agile kleinere Inkremente, aber wir machen immer noch Projekte. Unsere Kunden wollen Produkte.\nEin Projekt fokussiert auf Output: Features, User Stories, Tasks und Code maximieren. Ein Produkt fokussiert auf Outcome: das Bedürfnis des Kunden verstehen, sein Problem lösen, sein Verhalten verändern. DevOps unterstützt diesen Wandel, denn es ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das Menschen über den Wertstrom organisiert, um kontinuierlich Wert zu liefern.\n«DevOps bedeutet, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.»\nDie 24 Schlüsselfähigkeiten aus Accelerate # Das Buch Accelerate hat wissenschaftlich 24 Schlüsselfähigkeiten identifiziert, die die Software-Delivery-Performance treiben. Sie fallen in fünf Kategorien:\nContinuous Delivery: Versionskontrolle, Deployment-Automatisierung, Continuous Integration, Trunk-Based Development, Testautomatisierung, Testdatenmanagement, Shift-Left Security Architektur: Lose gekoppelte Architektur und befähigte Teams (Teams mit maximal fünf Personen mit klaren Inputs und Outputs) Produkt und Prozess: Kundenfeedback, Value Stream Mapping, Arbeiten in kleinen Batches, Team-Experimentierung Lean Management und Monitoring: Change-Approval-Prozesse (die laut Wissenschaft keinen Nutzen bringen und oft verlangsamen), Monitoring, WIP-Limits, Visualisierung der Arbeit Kultur: Westrum-Organisationskultur (pathologisch, bürokratisch oder generativ), unterstützendes Lernen, Arbeitszufriedenheit, transformationale Führung Die Forschung bildet auch die Beziehungen zwischen diesen Fähigkeiten ab. Wenn man die Ergebnisse auf der rechten Seite erreichen will, investiert man in die Fähigkeiten auf der linken Seite.\nDas Tesla-Beispiel # Um zu veranschaulichen, wie moderne Continuous Delivery aussieht, betrachten wir Tesla. Am 7. Oktober 2021 twitterte Elon Musk, dass das Selbstfahr-Modul FSD 10.2 an 1'000 Besitzer mit perfektem Safety Score ausgerollt wird. Das sagt uns: Die Software ist modularisiert, Over-the-Air-Updates funktionieren, das Fahrverhalten wird kontinuierlich überwacht, und bestimmte Benutzergruppen können gezielt angesprochen werden. Das ist ein Canary Release.\nAm 15. Oktober wurde Version 10.3 an eine grössere Gruppe ausgerollt. Am 24. Oktober wurde auf 10.2 zurückgerollt wegen eines Problems. In einer regulierten Branche, mit Autos auf der Strasse, führten sie einen Rollback durch. Nicht einmal 24 Stunden später deployten sie 10.3.1 als Fix Forward. Viele Unternehmen schaffen keine Rollbacks mit ihrer Software. Tesla macht es mit Hardware auf der Strasse.\nDas Problem der kognitiven Belastung # Moderne Softwareentwicklung erfordert ein enormes Set an technischen Praktiken: Infrastruktur, Laufzeitumgebung, CI/CD, Monitoring, Security, Tooling, Kostenmanagement, Wartung und Zugriffsmanagement. Und irgendwo dazwischen will man auch noch eine Applikation bauen.\nWenn man das über mehrere Teams skaliert, baut jedes Team seinen eigenen Stack. Das führt zu Inkonsistenzen, Redundanzen, fehlendem Betriebswissen, keinen Synergien und Schwierigkeiten, Mitarbeitende zwischen Teams zu verschieben. Die kognitive Belastung wird erdrückend.\nPlatform Engineering: Das Fundament # Platform Engineering löst dieses Problem. Ein Plattform-Team baut ein Produkt, die Plattform, das standardisierte Fähigkeiten für Produkt-Teams bereitstellt:\nApplikations-Laufzeitumgebung (Environments, Kubernetes-Cluster) DevSecOps (Vulnerability Scans, Lizenz-Scanning, Container Scanning) Zugang und Identität (zentralisierte Authentifizierung über alle Tools) Monitoring und Observability (vorkonfigurierte Dashboards und Alerting) CI/CD-Pipelines (standardisiert, sofort einsatzbereit) Die Produkt-Teams bauen, betreiben und warten ihre Produkte auf dieser Plattform. Sie besitzen weiterhin ihre CI/CD-Pipelines, überwachen ihre Applikationen und reagieren auf Incidents. Das Plattform-Team befähigt sie nur, DevOps zu machen, ohne das Rad neu zu erfinden.\nDas ist kein neues Silo. Die Plattform ist ein Produkt, das Teams nutzen wollen. Das Plattform-Team schafft Wert für die Teams. Die Produkt-Teams schaffen Wert für die Kunden.\nDie digitale Fabrik: Ein ganzheitlicher Ansatz # Eine digitale Fabrik bringt alles zusammen. Stellt euch ein Unternehmen vor, das Drohnen baut (oder ersetzt \u0026ldquo;Drohne\u0026rdquo; durch euer Softwareprodukt):\nVorstandsebene: Das Management hat eine Vision (Marktanteil erhöhen) und ein Portfolio von Initiativen. Sie priorisieren: eine Drohne bauen, die schwere Lasten tragen kann.\nProduktebene: Produktmanager nehmen dieses Epic und entwerfen Features: grösserer Akku, aktualisierte Software, neuer Motor.\nTeamebene: Bestehende Teams arbeiten an Software- und Akku-Änderungen. Für den neuen Motor braucht es ein neues Team. Das Plattform-Team stellt eine standardisierte CI/CD-Pipeline bereit, damit das neue Team ohne Verzögerung starten kann.\nLieferung: Alle Teile werden zusammengebaut und an den Kunden geliefert. Der Kunde ist zufrieden.\nFeedback-Schleife: Telemetriedaten von den Drohnen fliessen zurück an die Teams zur kontinuierlichen Verbesserung und an den Vorstand für strategische Entscheidungen.\nDas ist eine digitale Fabrik. Lean Portfolio Management an der Spitze verbindet Strategie mit Ausführung. Das Plattform-Team am Fundament ermöglicht DevOps. Produkt-Teams in der Mitte liefern Wert.\nGrossartige Produkte erfordern eine ganzheitliche Sicht # Eine digitale Fabrik zu bauen, dreht sich nicht nur um DevOps und Platform Engineering. Man braucht auch:\nSkalierbare Architektur mit einem modularen, API-getriebenen Ansatz Datenmanagement um aus Telemetrie- und Geschäftsdaten Sinn zu machen Kundenerlebnis mit einem End-to-End-Fokus auf die Customer Journey Agile Programmlieferung zur Verwaltung von Backlogs, Abhängigkeiten und Team-Abstimmung Produktmanagement um Strategie mit Ausführung zu verbinden Kernaussagen # Von Projekten zu Produkten wechseln. Auf Outcomes statt Outputs fokussieren. Den Kunden ins Zentrum stellen. DevOps ist ein ganzheitlicher Ansatz, der Menschen, Prozesse und Technologie über den Wertstrom zusammenbringt. Platform Engineering reduziert die kognitive Belastung und ermöglicht Produkt-Teams, DevOps im grossen Massstab durch Standardisierung und Self-Service zu betreiben. Digitale Fabriken sind das ganzheitliche Modell für industrialisierte Softwareentwicklung: Lean Portfolio Management an der Spitze, eine Plattform als Fundament und befähigte Produkt-Teams in der Mitte. Die Feedback-Schleife hört nie auf. Von Telemetrie zurück zu den Teams, von Geschäftsmetriken zurück zum Vorstand: datengetriebene Entscheidungsfindung hält die Fabrik am Laufen. Wir treten in das Zeitalter der industrialisierten Softwareentwicklung ein. Platform Engineering ist das Fundament der digitalen Fabrik, und die digitale Fabrik ist der Weg, wie wir kontinuierlich Wert liefern. ","date":"4. February 2024","externalUrl":null,"permalink":"/de/blogs/die-digitale-fabrik-90-days-of-devops/","section":"Blogs","summary":"Für die 90 Days of DevOps Community habe ich das Konzept der digitalen Fabrik vorgestellt. Nach Jahren von DevOps-Transformationen in verschiedenen Branchen bei Zühlke habe ich einen ganzheitlichen Ansatz zur Skalierung von DevOps entwickelt, der über Tools und Pipelines hinausgeht. In diesem Vortrag erkläre ich, warum wir immer noch mit Mauern der Verwirrung kämpfen, wie Platform Engineering Teams befähigt, DevOps im grossen Massstab zu betreiben, und wie digitale Fabriken alles zusammenbringen.\n","title":"Die digitale Fabrik: 90 Days of DevOps","type":"blogs"},{"content":"For the 90 Days of DevOps community, I presented the concept of the digital factory. After years of doing DevOps transformations across industries at Zühlke, I have developed a holistic approach to scaling DevOps that goes beyond just tools and pipelines. In this talk, I explain why we still struggle with walls of confusion, how platform engineering enables teams to do DevOps at scale, and how digital factories bring everything together.\nThe Broken Value Stream # The pattern I see in company after company is the same. The business has great ideas. They put them into Word documents and Jira tickets and throw them over the wall of confusion to development. Development builds something and throws it to testing. Testing verifies something (that rarely matches the original specification), and throws it to operations. Operations says \u0026ldquo;this will never work in production\u0026rdquo; but somehow manages. The customer gets the result and says: \u0026ldquo;That is not what we wanted.\u0026rdquo;\nThe value stream is broken by these walls of confusion. They come from silo organizations with different goals, missing alignment, slow and ineffective processes, and cultural resistance. Security and quality become afterthoughts instead of built-in practices.\nFrom Projects to Products # These problems originate from how we organize work. In the past, we did waterfall projects with fixed scope, budget, and time. Then agile brought smaller increments, but we are still doing projects. Our clients want products.\nA project focuses on output: maximize features, user stories, tasks, and code. A product focuses on outcome: understand the customer\u0026rsquo;s need, solve their problem, change their behavior. DevOps supports this shift because it is a mindset, a culture, and a set of technical practices that organizes people across the value stream to continuously deliver value.\n\u0026ldquo;DevOps is about bringing all the people, process, and technology together to continuously deliver value.\u0026rdquo;\nThe 24 Key Capabilities from Accelerate # The book Accelerate scientifically identified 24 key capabilities that drive software delivery performance. They fall into five categories:\nContinuous Delivery: Version control, deployment automation, continuous integration, trunk-based development, test automation, test data management, shift-left security Architecture: Loosely coupled architecture and empowered teams (teams of maximum five people with clear inputs and outputs) Product and Process: Customer feedback, value stream mapping, working in small batches, team experimentation Lean Management and Monitoring: Change approval processes (which science shows add no value and often slow things down), monitoring, WIP limits, visualizing work Culture: Westrum organizational culture (pathological, bureaucratic, or generative), supportive learning, job satisfaction, transformational leadership The research also maps the relationships between these capabilities. When you want to achieve the outcomes on the right side, you invest in the capabilities on the left side. This is one of the most important pictures in DevOps.\nThe Tesla Example # To illustrate what modern continuous delivery looks like, consider Tesla. On October 7, 2021, Elon Musk tweeted that the self-driving module FSD 10.2 would roll out to 1,000 owners with a perfect safety score. This tells us several things: the software is modularized, over-the-air updates work, they monitor driving behavior continuously, and they can target specific user groups. That is a canary release.\nOn October 15, version 10.3 rolled out to a larger group. On October 24, they rolled back to 10.2 because of a problem. In a regulated industry, with cars on the road, they performed a rollback. Not even 24 hours later, they deployed 10.3.1 as a fix forward. Many companies cannot do rollbacks with their software. Tesla does it with hardware on the road.\nThe Cognitive Load Problem # Modern software development requires an enormous set of technical practices: infrastructure, runtime, CI/CD, monitoring, security, tooling, cost management, maintenance, and access management. And somewhere in there, you also want to build an application.\nWhen you scale this across multiple teams, each team builds its own stack. This leads to inconsistencies, redundancies, lack of operational experience, no synergies, and difficulty moving people between teams. The cognitive load becomes crushing.\nPlatform Engineering: The Foundation # Platform engineering solves this. A platform team builds a product, the platform, that provides standardized capabilities to product teams:\nApplication runtime (environments, Kubernetes clusters) DevSecOps (vulnerability scans, license scanning, container scanning) Access and identity (centralized authentication across all tools) Monitoring and observability (pre-configured dashboards and alerting) CI/CD pipelines (standardized, ready to use) The product teams build, run, and maintain their products on top of this platform. They still own their CI/CD pipelines, still monitor their applications, still respond to incidents. The platform team just enables them to do DevOps without reinventing the wheel.\nThis is not a new silo. The platform is a product that teams want to use. The platform team generates value for the teams. The product teams generate value for the customers.\nThe Digital Factory: A Holistic Approach # A digital factory brings everything together. Picture a company that builds drones (or replace \u0026ldquo;drone\u0026rdquo; with your software product):\nBoard level: The management has a vision (increase market share) and a portfolio of initiatives. They prioritize: build a drone that can carry heavy weights.\nProduct level: Product managers take this epic and design features: bigger battery, updated software, new engine.\nTeam level: Existing teams work on software and battery changes. For the new engine, a new team needs to start. The platform team provides a standardized CI/CD pipeline so the new team can begin with zero delay.\nDelivery: All parts are assembled and delivered. The customer is happy.\nFeedback loop: Telemetry data from the drones flows back to the teams for continuous improvement, and also back to the board for strategic decisions.\nThis is what I call a digital factory. Lean portfolio management at the top connects strategy with execution. The platform team at the foundation enables DevOps. Product teams in the middle deliver value.\nCreating Great Products Requires a Holistic View # Building a digital factory is not just about DevOps and platform engineering. You also need:\nScalable architecture with a modular, API-driven approach Data management to make sense of telemetry and business data Customer experience with an end-to-end focus on the customer journey Agile program delivery to manage backlogs, dependencies, and team alignment Product management to connect strategy with execution Key Takeaways # Move from projects to products. Focus on outcomes, not outputs. Put the customer at the center. DevOps is a holistic approach that brings people, process, and technology together across the value stream. Platform engineering reduces cognitive load and enables product teams to do DevOps at scale through standardization and self-service. Digital factories are the holistic model for industrialized software development: lean portfolio management at the top, a platform at the foundation, and empowered product teams in the middle. The feedback loop never stops. From telemetry back to teams, and from business metrics back to the board, data-driven decision making keeps the factory running. We are entering the age of industrialized software development. Platform engineering is the foundation of the digital factory, and the digital factory is how we continuously deliver value. ","date":"4 February 2024","externalUrl":null,"permalink":"/en/blogs/the-digital-factory-90-days-of-devops/","section":"Blogs","summary":"For the 90 Days of DevOps community, I presented the concept of the digital factory. After years of doing DevOps transformations across industries at Zühlke, I have developed a holistic approach to scaling DevOps that goes beyond just tools and pipelines. In this talk, I explain why we still struggle with walls of confusion, how platform engineering enables teams to do DevOps at scale, and how digital factories bring everything together.\n","title":"The Digital Factory: 90 Days of DevOps","type":"blogs"},{"content":"I joined Eveline Oehrlich, Chief Research Officer at the DevOps Institute, on the Humans of DevOps podcast for a conversation about whether DevOps is dead. Spoiler: it is not. But the reality in most companies is that we have not progressed as far as many people think. In this episode, we talk about what a Chief of DevOps actually does, why companies still struggle with walls of confusion, how platform engineering enables scaling, and my prediction about digital factories.\nWhat Does a Chief of DevOps Do? # As Chief of DevOps at Zühlke, I work as a thought leader. That means speaking at conferences, creating videos, writing blog posts, defining the DevOps strategy and offerings for the company, building education programs, and training people. But the most important part of the role is working in real projects. Only by making your hands dirty in actual client engagements can you truly lead thought in this space.\nThe Walls of Confusion Are Still There # When I go into companies today, I still see the same picture I saw years ago. The business has bright ideas, writes them into Word documents and Jira tickets, and throws them over the wall of confusion to the development team. The developers build something and throw it to QA. QA tests something and throws it to operations. Operations struggles to keep it running. The customer gets the result and says: \u0026ldquo;This is not what we wanted.\u0026rdquo;\nThese walls of confusion persist because most companies have not organized themselves across the value stream. They still have silo organizations. They still work in projects with start dates, end dates, and yearly budget goals. Many companies say they are doing DevOps because they introduced a \u0026ldquo;DevOps team\u0026rdquo; or hired a \u0026ldquo;DevOps engineer,\u0026rdquo; but that is not really doing DevOps.\n\u0026ldquo;We have not yet progressed really into the direction of DevOps. What many companies are doing is they say we have that DevOps silo introduced or we have the DevOps engineer. But that is not really doing DevOps.\u0026rdquo;\nCulture Change Must Come From the Top # DevOps has three dimensions: mindset, culture, and technical practices. On the technical side, most organizations are doing reasonably well. The real challenge is the cultural and mindset shift. That change can only come from top management. Without executive buy-in for a genuine cultural transformation, DevOps teams are fighting against windmills.\nThere is a hopeful side: the teams that are doing great DevOps work are producing visible outcomes and results. Over time, these results bubble up to executive leaders, who begin to see that DevOps is an overall culture change, not just a technology initiative.\nScaling DevOps with Platform Engineering # When you have a small company or a single product, doing DevOps is relatively straightforward. Scaling it is the hard part. When multiple product teams work independently, each team tends to reinvent the wheel. They build their own toolchains, manage their own infrastructure, and carry a massive cognitive load.\nThis is where platform engineering comes in. A platform team builds a platform, including APIs, self-service portals, and a marketplace, so that product teams can build, maintain, and operate their products efficiently. The platform team creates value for the teams while the product teams create value for the customers.\nWhat skills does a platform engineer need? You need to be a software engineer. A platform is a product that requires building user interfaces, APIs, databases, and integrations. On top of that, you need a strong DevOps mindset and deep knowledge of cloud-native technologies.\nThe DevOps Naming Debate # The term DevOps is not perfect. It implies just development and operations. People suggest DevSecOps, BizDevOps, DevXOps, and many other variations. I think this debate leads nowhere. DevOps is about bringing all people, all processes, and all technology together to continuously deliver value. The exact term matters less than having a shared understanding of what it means.\nOrganizing Across the Value Stream # Eveline asked me what I would recommend to a Chief of DevOps who wants to expand their DevOps journey from a people and culture perspective. My answer: organize across the value stream.\nIdentify the value streams in your company. Understand how you generate value, what steps are needed, and which people are involved. Then organize those people into value stream teams, sometimes also called product teams. Give these teams budget and the power to make decisions. Empower them to focus on their customers and build great products with built-in quality.\nThis shifts the focus away from projects (\u0026ldquo;we need these 10 features\u0026rdquo;) toward customer-centric product development with happy customers and happy employees.\nMy Prediction: Digital Factories # When Eveline asked me to pull out my crystal ball, I predicted digital factories. We can already see it happening with platform engineering. Companies are standardizing their software development and moving toward industrialization.\nIn a digital factory, teams are organized across the value stream, producing digital products or cyber-physical products. The platform engineering team provides the conveyor belt for these digital factories. Software development is no longer about every team reinventing everything. Instead, standardized components fit together because they follow common standards.\n\u0026ldquo;My prediction is we will see a lot of digital factories coming up.\u0026rdquo;\nKey Takeaways # DevOps is not dead, but most companies have not truly adopted it yet. Silo organizations, project thinking, and missing cultural change are still the norm. Culture change must come from the top. Without executive commitment, DevOps teams lack the mandate for real transformation. Platform engineering enables scaling. A platform team builds a product that reduces cognitive load and lets product teams focus on delivering value. Organize across the value stream. Move from silo-based project teams to empowered product teams aligned along value streams. The future is digital factories. Standardized platforms, organized teams, and industrialized software development will define the next era. ","date":"27 January 2024","externalUrl":null,"permalink":"/en/blogs/devops-institute-podcast-devops-is-not-dead/","section":"Blogs","summary":"I joined Eveline Oehrlich, Chief Research Officer at the DevOps Institute, on the Humans of DevOps podcast for a conversation about whether DevOps is dead. Spoiler: it is not. But the reality in most companies is that we have not progressed as far as many people think. In this episode, we talk about what a Chief of DevOps actually does, why companies still struggle with walls of confusion, how platform engineering enables scaling, and my prediction about digital factories.\n","title":"DevOps Institute Podcast: DevOps Is NOT Dead","type":"blogs"},{"content":"Ich war zu Gast bei Eveline Oehrlich, Chief Research Officer beim DevOps Institute, im Humans of DevOps Podcast. Die Frage: Ist DevOps tot? Spoiler: Nein, ist es nicht. Aber die Realität in den meisten Unternehmen zeigt, dass wir nicht so weit gekommen sind, wie viele denken. In dieser Episode sprechen wir darüber, was ein Chief of DevOps eigentlich macht, warum Unternehmen immer noch mit Mauern der Verwirrung kämpfen, wie Platform Engineering die Skalierung ermöglicht und meine Prognose über digitale Fabriken.\nWas macht ein Chief of DevOps? # Als Chief of DevOps bei Zühlke arbeite ich als Thought Leader. Das bedeutet: Vorträge auf Konferenzen, Videos produzieren, Blogposts schreiben, die DevOps-Strategie und das Angebot des Unternehmens definieren, Ausbildungsprogramme aufbauen und Menschen ausbilden. Aber der wichtigste Teil der Rolle ist die Arbeit in echten Projekten. Nur wenn man sich in tatsächlichen Kundenprojekten die Hände schmutzig macht, kann man wirklich ein Thought Leader in diesem Bereich sein.\nDie Mauern der Verwirrung bestehen weiterhin # Wenn ich heute in Unternehmen gehe, sehe ich immer noch dasselbe Bild wie vor Jahren. Das Business hat grossartige Ideen, schreibt sie in Word-Dokumente und Jira-Tickets und wirft sie über die Mauer der Verwirrung zum Entwicklungsteam. Die Entwickler bauen etwas und werfen es zur QA. Die QA testet etwas und wirft es zum Betrieb. Der Betrieb kämpft damit, es am Laufen zu halten. Der Kunde bekommt das Ergebnis und sagt: \u0026ldquo;Das ist nicht das, was wir wollten.\u0026rdquo;\nDiese Mauern der Verwirrung bestehen weiterhin, weil die meisten Unternehmen sich nicht über den Wertstrom organisiert haben. Sie haben immer noch Silo-Organisationen. Sie arbeiten immer noch in Projekten mit Startdatum, Enddatum und jährlichen Budgetzielen. Viele Unternehmen sagen, sie machen DevOps, weil sie ein \u0026ldquo;DevOps-Team\u0026rdquo; eingeführt oder einen \u0026ldquo;DevOps Engineer\u0026rdquo; eingestellt haben. Aber das ist nicht wirklich DevOps.\n«Wir sind noch nicht wirklich in Richtung DevOps vorangeschritten. Was viele Unternehmen machen, ist: Sie sagen, wir haben dieses DevOps-Silo eingeführt oder wir haben den DevOps Engineer. Aber das ist nicht wirklich DevOps.»\nKulturwandel muss von oben kommen # DevOps hat drei Dimensionen: Mindset, Kultur und technische Praktiken. Auf der technischen Seite sind die meisten Organisationen recht gut aufgestellt. Die eigentliche Herausforderung ist der kulturelle Wandel und der Wandel im Denken. Dieser Wandel kann nur vom Top-Management kommen. Ohne den Rückhalt der Geschäftsleitung für eine echte kulturelle Transformation kämpfen DevOps-Teams gegen Windmühlen.\nEs gibt eine hoffnungsvolle Seite: Die Teams, die grossartige DevOps-Arbeit leisten, produzieren sichtbare Ergebnisse. Mit der Zeit dringen diese Ergebnisse bis zur Geschäftsleitung vor, die beginnt zu erkennen, dass DevOps ein umfassender Kulturwandel ist, nicht nur eine Technologie-Initiative.\nDevOps skalieren mit Platform Engineering # Wenn man ein kleines Unternehmen hat oder nur ein Produkt entwickelt, ist DevOps relativ einfach umzusetzen. Die Skalierung ist die Herausforderung. Wenn mehrere Produkt-Teams unabhängig arbeiten, neigt jedes Team dazu, das Rad neu zu erfinden. Sie bauen ihre eigenen Toolchains, verwalten ihre eigene Infrastruktur und tragen eine massive kognitive Belastung.\nHier kommt Platform Engineering ins Spiel. Ein Plattform-Team baut eine Plattform mit APIs, Self-Service-Portalen und einem Marketplace, damit Produkt-Teams ihre Produkte effizient bauen, warten und betreiben können. Das Plattform-Team schafft Wert für die Teams, während die Produkt-Teams Wert für die Kunden schaffen.\nWelche Fähigkeiten braucht ein Platform Engineer? Man muss Software Engineer sein. Eine Plattform ist ein Produkt, das Benutzeroberflächen, APIs, Datenbanken und Integrationen erfordert. Dazu braucht man ein starkes DevOps-Mindset und tiefes Wissen über Cloud-Native-Technologien.\nDie DevOps-Namensdebatte # Der Begriff DevOps ist nicht perfekt. Er impliziert nur Entwicklung und Betrieb. Leute schlagen DevSecOps, BizDevOps, DevXOps und viele andere Varianten vor. Ich denke, diese Debatte führt nirgendwohin. DevOps bedeutet, alle Menschen, alle Prozesse und alle Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. Der genaue Begriff ist weniger wichtig als ein gemeinsames Verständnis dessen, was er bedeutet.\nOrganisation über den Wertstrom # Eveline fragte mich, was ich einem Chief of DevOps empfehlen würde, der die DevOps-Reise aus der Perspektive von Menschen und Kultur erweitern möchte. Meine Antwort: Organisiert euch über den Wertstrom.\nIdentifiziert die Wertströme in eurem Unternehmen. Versteht, wie ihr Wert generiert, welche Schritte nötig sind und welche Menschen beteiligt sind. Dann organisiert diese Menschen in Wertstrom-Teams, manchmal auch Produkt-Teams genannt. Gebt diesen Teams Budget und die Macht, Entscheidungen zu treffen. Befähigt sie, sich auf ihre Kunden zu konzentrieren und grossartige Produkte mit eingebauter Qualität zu schaffen.\nDas verschiebt den Fokus weg von Projekten (\u0026ldquo;wir brauchen diese 10 Features\u0026rdquo;) hin zu kundenorientierter Produktentwicklung mit zufriedenen Kunden und zufriedenen Mitarbeitenden.\nMeine Prognose: Digitale Fabriken # Als Eveline mich bat, meine Kristallkugel hervorzuholen, prognostizierte ich digitale Fabriken. Wir können es bereits mit Platform Engineering beobachten. Unternehmen standardisieren ihre Softwareentwicklung und bewegen sich in Richtung Industrialisierung.\nIn einer digitalen Fabrik sind Teams über den Wertstrom organisiert und produzieren digitale Produkte oder cyber-physische Produkte. Das Platform-Engineering-Team stellt das Fliessband für diese digitalen Fabriken bereit. Softwareentwicklung bedeutet nicht mehr, dass jedes Team alles neu erfindet. Stattdessen passen standardisierte Komponenten zusammen, weil sie gemeinsamen Standards folgen.\n«Meine Prognose ist, dass wir viele digitale Fabriken entstehen sehen werden.»\nKernaussagen # DevOps ist nicht tot, aber die meisten Unternehmen haben es noch nicht wirklich übernommen. Silo-Organisationen, Projekt-Denken und fehlender Kulturwandel sind immer noch die Norm. Kulturwandel muss von oben kommen. Ohne Commitment der Geschäftsleitung fehlt DevOps-Teams das Mandat für eine echte Transformation. Platform Engineering ermöglicht die Skalierung. Ein Plattform-Team baut ein Produkt, das die kognitive Belastung reduziert und Produkt-Teams erlaubt, sich auf die Wertlieferung zu konzentrieren. Organisiert euch über den Wertstrom. Wechselt von silobasierten Projektteams zu befähigten Produkt-Teams entlang der Wertströme. Die Zukunft sind digitale Fabriken. Standardisierte Plattformen, organisierte Teams und industrialisierte Softwareentwicklung werden die nächste Ära definieren. ","date":"27. January 2024","externalUrl":null,"permalink":"/de/blogs/devops-institute-podcast-devops-ist-nicht-tot/","section":"Blogs","summary":"Ich war zu Gast bei Eveline Oehrlich, Chief Research Officer beim DevOps Institute, im Humans of DevOps Podcast. Die Frage: Ist DevOps tot? Spoiler: Nein, ist es nicht. Aber die Realität in den meisten Unternehmen zeigt, dass wir nicht so weit gekommen sind, wie viele denken. In dieser Episode sprechen wir darüber, was ein Chief of DevOps eigentlich macht, warum Unternehmen immer noch mit Mauern der Verwirrung kämpfen, wie Platform Engineering die Skalierung ermöglicht und meine Prognose über digitale Fabriken.\n","title":"DevOps Institute Podcast: DevOps ist NICHT tot","type":"blogs"},{"content":"Jedes Jahr durchforste ich die neuesten Berichte, Artikel und Branchendiskussionen, um einen umfassenden Überblick über die DevOps-Trends zusammenzustellen. Für 2024 habe ich jeden wichtigen Trend in den Technology Adoption Lifecycle eingeordnet, um ein klares Bild zu zeichnen, wo jede Technologie, Methodik oder Fähigkeit in Bezug auf die Verbreitung steht. Dieses Framework hilft zu verstehen, was nicht nur im Trend liegt, sondern wie ausgereift jeder Trend wirklich ist.\nDer Technology Adoption Lifecycle als Framework # Der Technology Adoption Lifecycle unterteilt Anwender in fünf Gruppen: Innovators (2,5%), Early Adopters (13,5%), Early Majority (34%), Late Majority (34%) und Laggards (16%). Jede Gruppe hat eine unterschiedliche Bereitschaft, neue Technologien zu übernehmen. Indem wir DevOps-Trends in diese Segmente einordnen, sehen wir auf einen Blick, welche Praktiken Mainstream sind und welche sich noch entwickeln.\nDas ist keine rein akademische Übung. Für Technologie-Entscheider zeigt diese Einordnung, wo die sicheren Wetten liegen und wo die Chancen für Wettbewerbsvorteile stecken.\nLate Majority: Die etablierten Praktiken # Das Late-Majority-Segment enthält Praktiken, die mittlerweile weit verbreitet sind, selbst bei konservativen Unternehmen:\nDevOps selbst, als Mindset, Kultur und technische Praktiken zur Organisation über den Value Stream hinweg Continuous Integration (CI), bei der Entwickler regelmässig Code in ein zentrales Repository zusammenführen, mit automatisierten Builds und Tests Container, die leichtgewichtigen, eigenständigen Laufzeitumgebungen, die zum Standard für Deployments geworden sind Monitoring, die kontinuierliche Erfassung und Analyse von Metriken und Logs zur Überwachung der Systemgesundheit Test-Automatisierung, der Einsatz von Software-Tools zur Ausführung von Tests und Sicherstellung der Qualität Deployment-Automatisierung, die Entfernung manueller Schritte aus dem Deployment-Prozess Das sind keine Differenzierungsmerkmale mehr. Das ist Grundvoraussetzung.\nEarly Majority: Die Wachstumszone # Das Early-Majority-Segment ist der Bereich, in dem 2024 die dynamischste Aktivität stattfindet:\nDORA Metrics (Deployment Frequency, Lead Time for Changes, Time to Restore, Change Failure Rate) zur Messung der DevOps-Effektivität. Ein Wort der Warnung: KPIs sind ein zweischneidiges Schwert. Achtet genau auf die Implementierung, sonst können sie eurer Organisation schaden. Internal Developer Portal (IDP), eine zentrale Plattform, die Entwicklern Zugang zu Tools, Ressourcen und Dokumentation bietet Platform Engineering, die Disziplin der Gestaltung standardisierter Toolsets für Entwicklerproduktivität. Das ist der grosse Trend für 2024, vollständig im Einklang mit Gartners Top Technology Trends. Test Data Management, der Umgang mit realistischen, konformen und sicheren Testdaten. Zur Erinnerung: Entwickler sollten niemals auf Produktionsdaten testen. Continuous Delivery (CD), die automatische Bereitstellung von Artefakten in Staging-Umgebungen nach CI Container Orchestration, mit Kubernetes als De-facto-Standard Infrastructure as Code (IaC), die Verwaltung von Infrastruktur durch Code statt manueller Prozesse Observability, die Nutzung von Logs, Metriken und Traces für Systemtransparenz DevSecOps, die Integration von Sicherheit als kontinuierlicher Teil des Entwicklungsprozesses Site Reliability Engineering (SRE), die Anwendung von Software Engineering auf Infrastruktur und Betrieb GitOps, die Verwendung von Git als Single Source of Truth für Infrastruktur- und Anwendungsmanagement FinOps, die Einführung finanzieller Verantwortlichkeit bei Cloud-Ausgaben. Kosten sind eine nichtfunktionale Anforderung und eine Einschränkung für jedes Backlog-Item. Platform Engineering ist der grösste DevOps-Trend für 2024. Das stimmt vollständig mit dem überein, was Gartner über die Top-Technologietrends sagt.\nEarly Adopters: Der Wettbewerbsvorteil # Im Early-Adopters-Segment investieren zukunftsorientierte Unternehmen für Wettbewerbsvorteile:\nKI-augmentierte Entwicklung, die Integration von KI in Coding und Testing (etwa GitHub Copilot). Compliance- und Sicherheitsfragen bremsen die breitere Adoption noch, aber ich erwarte, dass dies bis 2025 in die Early Majority rückt. Industry Cloud Platforms, spezialisierte Cloud-Dienste für bestimmte Branchen wie Gesundheitswesen und Finanzwirtschaft AIOps, der Einsatz von KI zur Verbesserung und Automatisierung des IT-Betriebs ChatOps, die Integration von Kommunikationstools mit operativen Aufgaben für Echtzeit-Automatisierung DataOps, ein agiler Ansatz zur Verwaltung verteilter Datenarchitekturen MLOps, die Optimierung des Machine-Learning-Modell-Lebenszyklus von Entwicklung bis Produktion DevEx (Developer Experience), der Fokus auf Tools, Praktiken und Kultur, die Entwicklung effizient und angenehm machen eBPF, die programmierbare Paketfilterung und Kernel-Level-Observability in Linux Policy as Code, die Definition und Durchsetzung von Richtlinien durch Code für automatisierte Compliance Service Mesh, eine dedizierte Infrastrukturschicht für die Microservice-Kommunikation Documentation as Code, die Versionierung und Automatisierung von Dokumentation im Entwicklungsprozess Continuous Testing, die Automatisierung von Tests über den gesamten Softwareentwicklungszyklus Cloud Development Environments, die Bereitstellung von Entwicklungsumgebungen in der Cloud Chaos Engineering, das gezielte Einfügen kontrollierter Fehler zur Aufdeckung von Schwachstellen Innovators: Die Grenze des Möglichen # Am äussersten Rand der Adoption finden sich Konzepte, die nur visionäre Teams erkunden:\nDesignOps, die Optimierung von Design-Team-Workflows und Zusammenarbeit Observability Driven Development (ODD), die Entwicklung von Anwendungen mit eingebauter Observability von Beginn an Data Mesh, ein dezentraler, domänenorientierter Ansatz für Datenmanagement im grossen Massstab NoOps, das Ziel, traditionellen IT-Betrieb durch extreme Automatisierung zu minimieren oder zu eliminieren Meine Prognosen für 2025 # Basierend auf der Landschaft von 2024 erwarte ich für 2025 Folgendes:\nDORA Metrics, Internal Developer Portals, Platform Engineering, Continuous Delivery und Container Orchestration werden beginnen, von der Early Majority in die Late Majority zu wechseln. Auf der Early-Adopters-Seite werden KI-augmentierte Entwicklung, AIOps, MLOps, Continuous Testing und Cloud Development Environments den Chasm erfolgreich in die Early Majority überqueren.\nDer Chasm zwischen Early Adopters und Early Majority ist die kritischste Lücke im Adoptionszyklus. Viele Technologien scheitern an diesem Punkt an der breiten Akzeptanz. Es wird faszinierend sein zu sehen, welche dieser Trends den Sprung schaffen.\nKernaussagen # Platform Engineering ist der Top-DevOps-Trend 2024, bestätigt durch Branchenanalysen und Gartner Der Technology Adoption Lifecycle bietet eine kraftvolle Perspektive zur Bewertung jedes Trends und zur Investitionsentscheidung KI dringt auf mehreren Ebenen in DevOps ein: Entwicklung, Betrieb und Machine-Learning-Lifecycle-Management Etablierte Praktiken wie CI, Container und Monitoring sind Grundvoraussetzungen, keine Differenzierungsmerkmale Finanzielle Verantwortlichkeit (FinOps) und Sicherheitsintegration (DevSecOps) werden zu Standardbestandteilen des DevOps-Werkzeugkastens Die grosse Frage für 2025: Welche Early-Adopter-Technologien werden den Chasm in die Mainstream-Adoption erfolgreich überqueren? ","date":"19. January 2024","externalUrl":null,"permalink":"/de/blogs/devops-trends-2024-die-zukunft-der-produktentwicklung/","section":"Blogs","summary":"Jedes Jahr durchforste ich die neuesten Berichte, Artikel und Branchendiskussionen, um einen umfassenden Überblick über die DevOps-Trends zusammenzustellen. Für 2024 habe ich jeden wichtigen Trend in den Technology Adoption Lifecycle eingeordnet, um ein klares Bild zu zeichnen, wo jede Technologie, Methodik oder Fähigkeit in Bezug auf die Verbreitung steht. Dieses Framework hilft zu verstehen, was nicht nur im Trend liegt, sondern wie ausgereift jeder Trend wirklich ist.\n","title":"DevOps Trends 2024: Die Zukunft der Produktentwicklung","type":"blogs"},{"content":"Every year, I go through the latest reports, articles, and industry discussions to compile a comprehensive view of the DevOps trends shaping our industry. For 2024, I mapped every major trend onto the technology adoption lifecycle to give you a clear picture of where each technology, methodology, or capability stands in terms of adoption. This framework helps you understand not just what is trending, but how mature each trend really is.\nThe Technology Adoption Lifecycle as a Framework # The technology adoption lifecycle divides adopters into five groups: Innovators (2.5%), Early Adopters (13.5%), Early Majority (34%), Late Majority (34%), and Laggards (16%). Each group has a different willingness to adopt new technologies. By placing DevOps trends into these segments, we can see at a glance which practices are mainstream and which are still emerging.\nThis is not just an academic exercise. If you are a technology leader, this mapping tells you where the safe bets are and where the opportunities for competitive advantage lie.\nLate Majority: The Established Practices # The Late Majority segment contains practices that are now widely adopted, even by conservative enterprises:\nDevOps itself, as a mindset, culture, and set of technical practices for organizing across the value stream Continuous Integration (CI), where developers frequently merge code into a central repository with automated builds and tests Containers, the lightweight, standalone executable environments that have become the norm for deploying applications Monitoring, the continuous collection and analysis of metrics and logs for tracking system health Test Automation, using software tools to execute tests and ensure quality standards Deployment Automation, removing manual steps from the deployment process to ensure consistency and reduce human error These are no longer differentiators. They are table stakes.\nEarly Majority: The Growth Zone # The Early Majority segment is where the most dynamic activity happens in 2024. These practices are being adopted by a growing number of organizations:\nDORA Metrics (Deployment Frequency, Lead Time for Changes, Time to Restore, Change Failure Rate) for measuring DevOps effectiveness. A word of caution: KPIs are a two-sided sword. Pay close attention when implementing them, or they can harm your organization. Internal Developer Portal (IDP), a centralized platform giving developers access to tools, resources, and documentation Platform Engineering, the discipline of designing standardized toolsets for developer productivity. This is the big trend for 2024, fully aligned with Gartner\u0026rsquo;s Top Technology Trends. Test Data Management, handling realistic, compliant, and secure test datasets. Remember: developers should never test on production data. Continuous Delivery (CD), automatically deploying artifacts to staging environments after CI Container Orchestration, with Kubernetes as the de facto standard Infrastructure as Code (IaC), managing infrastructure through code rather than manual processes Observability, using logs, metrics, and traces for system transparency DevSecOps, integrating security as a continuous part of the development process Site Reliability Engineering (SRE), applying software engineering to infrastructure and operations GitOps, using Git as the single source of truth for infrastructure and application management FinOps, bringing financial accountability to cloud spending. Cost is a nonfunctional requirement, and it is a constraint on every backlog item. Platform Engineering is the biggest DevOps trend for 2024. This is completely in line with what Gartner is telling us about the top technology trends.\nEarly Adopters: The Competitive Edge # The Early Adopters segment is where forward-thinking organizations invest to gain competitive advantage:\nAI-Augmented Development, integrating AI into coding and testing (think GitHub Copilot). Compliance and security issues are still slowing broader adoption, but I expect this to move into Early Majority by 2025. Industry Cloud Platforms, specialized cloud services tailored to specific industries like healthcare and finance AIOps, applying AI to enhance and automate IT operations, especially valuable in complex cloud environments ChatOps, integrating communication tools with operational tasks for real-time automation DataOps, an agile approach to distributed data architecture management MLOps, streamlining the machine learning model lifecycle from development to production DevEx (Developer Experience), focusing on tools, practices, and culture that make development efficient and enjoyable eBPF, enabling programmable packet filtering and kernel-level observability in Linux Policy as Code, defining and enforcing policies through code for automated compliance Service Mesh, a dedicated infrastructure layer for microservice communication Documentation as Code, versioning and automating documentation within the development process Continuous Testing, automating testing throughout the entire software development lifecycle Cloud Development Environments, hosting development environments in the cloud for flexibility and collaboration Chaos Engineering, deliberately injecting controlled failures to uncover vulnerabilities Innovators: The Frontier # At the very edge of adoption, the Innovators segment contains concepts that only visionary teams are exploring:\nDesignOps, optimizing design team workflows and collaboration Observability Driven Development (ODD), building applications with observability baked in from the start Data Mesh, a decentralized, domain-oriented approach to data management at scale NoOps, aiming to minimize or eliminate traditional IT operations through extreme automation My Predictions for 2025 # Based on the 2024 landscape, here is what I expect for 2025:\nDORA Metrics, Internal Developer Portals, Platform Engineering, Continuous Delivery, and Container Orchestration will start moving from Early Majority to Late Majority. On the Early Adopters side, AI-Augmented Development, AIOps, MLOps, Continuous Testing, and Cloud Development Environments will successfully cross the chasm into Early Majority.\nThe chasm between Early Adopters and Early Majority is the most critical gap in the adoption lifecycle. Many technologies fail to gain mainstream acceptance at this point. It will be fascinating to see which of these trends make the jump.\nKey Takeaways # Platform Engineering is the top DevOps trend for 2024, confirmed by both industry research and Gartner\u0026rsquo;s analysis The technology adoption lifecycle provides a powerful lens for evaluating where each trend stands and where to invest AI is entering DevOps at multiple levels: development, operations, and machine learning lifecycle management Established practices like CI, containers, and monitoring are now baseline expectations, not differentiators Financial accountability (FinOps) and security integration (DevSecOps) are becoming standard parts of the DevOps toolkit The biggest question for 2025: which Early Adopter technologies will successfully cross the chasm into mainstream adoption? ","date":"19 January 2024","externalUrl":null,"permalink":"/en/blogs/devops-trends-2024-unlocking-the-future-of-product-delivery/","section":"Blogs","summary":"Every year, I go through the latest reports, articles, and industry discussions to compile a comprehensive view of the DevOps trends shaping our industry. For 2024, I mapped every major trend onto the technology adoption lifecycle to give you a clear picture of where each technology, methodology, or capability stands in terms of adoption. This framework helps you understand not just what is trending, but how mature each trend really is.\n","title":"DevOps Trends 2024: Unlocking the Future of Product Delivery","type":"blogs"},{"content":"","date":"19 January 2024","externalUrl":null,"permalink":"/en/tags/trends/","section":"Tags","summary":"","title":"Trends","type":"tags"},{"content":"In dieser Episode des DevTalk-Podcasts unterhalte ich mich mit meinem Kollegen Kerry Lothrop über den Stand von DevOps. Wir kennen uns seit vielen Jahren bei Zühlke, und Kerry wollte erfahren, was DevOps heute wirklich bedeutet, wo Unternehmen Schwierigkeiten haben und wohin sich die Branche entwickelt.\nWas DevOps wirklich bedeutet # Eine der ersten Fragen von Kerry war, DevOps zu definieren. Für mich ist DevOps ein Mindset, eine Kultur und eine Reihe von technischen Praktiken, die es uns ermöglichen, kontinuierlich Wert zu liefern. Es bringt alle Menschen, alle Technologien und alle Methoden zusammen, damit wir unseren Kunden kontinuierlich Mehrwert bieten können.\nDer Mindset-Teil ist besonders wichtig. Wenn man ein DevOps-Mindset hat, denkt man in Produkten. Es geht um das Ergebnis, das man erreichen möchte, nicht um den Output. Statt die Anzahl der Features zu maximieren, konzentriert man sich darauf, das eine Feature umzusetzen, das für den Kunden gut ist. Man stellt den Nutzer in den Mittelpunkt und versucht, sein tatsächliches Problem zu lösen.\n„DevOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken, die es uns ermöglichen, kontinuierlich Wert zu liefern.\u0026quot;\nDie Ursprungsgeschichte: Wir hatten es schon einmal # Interessanterweise arbeiteten die Menschen Anfang der 2000er Jahre bereits in einem Modell, das ich als DevOps-Betriebsmodell bezeichnen würde. Es gab kleine Teams, die Projektmanagement, Requirements Engineering, Testing, Entwicklung und Betrieb übernahmen. Alles war in einem Team vereint, es gab keine Silos und keine Mauern der Verwirrung.\nDann wurde es komplizierter. Unternehmen entschieden sich, die Softwareentwicklung zu skalieren, indem sie spezialisierte Teams für jede Disziplin bildeten. So entstanden die Silos. Das Problem: Der Wertstrom fliesst nicht durch Silos. Stattdessen werden Dinge über Mauern der Verwirrung geworfen, und genau dort beginnen die Probleme.\nDevOps beginnt vor dem Code # Kerry war überrascht, als ich erklärte, dass DevOps viel früher beginnt, als die meisten denken. Es fängt an, wenn das Business eine Idee hat. Nicht alle Ideen sind es wert, in ein Projekt umgesetzt zu werden. In einer DevOps-Welt identifiziert man zuerst die Hypothese hinter der Idee und versteht, welches Problem man lösen möchte.\nDann definiert man Frühindikatoren zur Erfolgsmessung. Man geht zum Kunden mit UX-Methoden, um die Hypothese zu validieren. Man definiert die minimale Architektur, die nötig ist. Man zerlegt alles in Features und User Stories. Und man entwickelt mit kontinuierlicher Testbarkeit und Betreibbarkeit im Blick. Nach dem Aufbau der Continuous-Delivery-Pipeline misst man, ob die Hypothese zutrifft, und passt sich entsprechend an.\nDas ist der vollständige Zyklus des DevOps-Unendlichkeitssymbols.\nMessen, was zählt # Wenn es um die Messung der Software-Delivery-Performance geht, verweise ich immer auf das Buch Accelerate und die DORA-Metriken. Die vier wichtigsten Metriken sind:\nLead Time for Changes: Wie lange es vom Code-Commit bis zur Produktion dauert Deployment Frequency: Wie oft man in die Produktion deployt Change Failure Rate: Der Prozentsatz der Deployments, die Fehler verursachen Mean Time to Recovery: Wie schnell man den Service nach einem Vorfall wiederherstellt Es ist wichtig, den Unterschied zwischen Deployment und Release zu verstehen. Ein Deployment bringt neuen Code mit ausgeschaltetem Feature Toggle in die Produktion. Ein Release ist das Einschalten des Feature Toggles. Diese Unterscheidung ermöglicht eine hohe Deployment-Frequenz, ohne die Nutzer zu stören.\nNicht jedes Unternehmen muss alle 15 Minuten deployen. Es ist völlig in Ordnung, täglich oder in einem Zwei-Tage-Zyklus zu deployen. Entscheidend ist das Gespräch darüber, was im eigenen Kontext sinnvoll ist.\nDer Aufstieg digitaler Fabriken und Platform Engineering # Auf die Frage, wohin DevOps sich entwickelt, teilte ich meine Vision des Zeitalters der Industrialisierung der Softwareentwicklung. Wir bewegen uns hin zu digitalen Fabriken, in denen Teams auf Fliessbändern der Automatisierung arbeiten und kontinuierlich ihre Produkte liefern.\nDiese Fliessbänder sind Plattformen, die von Plattform-Teams gebaut werden, die Platform Engineering betreiben. Die Plattform-Teams ermöglichen es den Produkt-Teams, DevOps zu praktizieren. Das ist die Richtung, in die sich die Branche entwickelt: Plattformen, die die kognitive Last reduzieren und Teams ermöglichen, sich auf die Wertschöpfung zu konzentrieren.\n„Wir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein. Platform Engineering ermöglicht es Produkt-Teams, DevOps zu betreiben.\u0026quot;\nKI in DevOps: Bereits mit grosser Wirkung # Wir sprachen auch über KI. Zum Zeitpunkt des Podcasts war gerade ChatGPT 4 veröffentlicht worden. Ich berichtete, dass KI bereits im Operations-Bereich durch AIOps hilft. Bei einem meiner Kunden generieren wir täglich rund 16 Terabyte Telemetriedaten. Das ist ein Big-Data-Problem, und KI ist hervorragend in der Mustererkennung, um Problembereiche zu identifizieren und Ursachenanalysen durchzuführen.\nIch prognostizierte, dass sich KI über Planung und Entwicklung hinaus auf Releasing, Monitoring und Deployment ausweiten wird. Die Tools entwickeln sich rasant weiter, und KI wird uns weiterhin helfen, über den gesamten DevOps-Zyklus hinweg bessere Arbeit zu leisten.\nKernaussagen # DevOps ist zuerst ein Mindset. Die Kultur und das Produktdenken sind wichtiger als die Tools. Denke in Produkten, nicht in Projekten. Fokussiere dich auf das Ergebnis für den Kunden, nicht auf den Output für die Organisation. Beginne mit der Hypothese. Bevor du etwas baust, verstehe, welches Problem du löst und wie du den Erfolg misst. Nutze DORA-Metriken weise. Sie sind wissenschaftlich belegt, aber wende sie auf deinen Kontext an, statt blindlings Elite-Status anzustreben. Platform Engineering ist die Zukunft. Digitale Fabriken mit internen Entwicklerplattformen werden Teams ermöglichen, DevOps im grossen Massstab zu betreiben. KI wird den gesamten DevOps-Zyklus transformieren. Von der Planung bis zum Monitoring hat KI bereits eine Wirkung und wird weiter wachsen. ","date":"14. January 2024","externalUrl":null,"permalink":"/de/blogs/devtalk-podcast-der-stand-von-devops/","section":"Blogs","summary":"In dieser Episode des DevTalk-Podcasts unterhalte ich mich mit meinem Kollegen Kerry Lothrop über den Stand von DevOps. Wir kennen uns seit vielen Jahren bei Zühlke, und Kerry wollte erfahren, was DevOps heute wirklich bedeutet, wo Unternehmen Schwierigkeiten haben und wohin sich die Branche entwickelt.\n","title":"DevTalk Podcast: Der Stand von DevOps","type":"blogs"},{"content":"In this episode of the DevTalk podcast, my colleague Kerry Lothrop and I have a conversation about the state of DevOps. We have known each other for many years at Zühlke, and Kerry wanted to pick my brain on what DevOps really means today, where companies struggle, and where the industry is heading.\nWhat DevOps Really Means # One of the first things Kerry asked me was to define DevOps. For me, DevOps is a mindset, a culture, and a set of technical practices that allows us to continuously deliver value. It brings all the people, all the technology, and all the methodology together so that we can continuously deliver value to our clients.\nThe mindset part is especially important. When you have a DevOps mindset, you think in products. It is about the outcome you want to achieve, not the output. Instead of maximizing the number of features, you focus on implementing that one feature that is good for the customer. You bring the user into the center and aim to solve their actual problem.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices which allows us to continuously deliver value.\u0026rdquo;\nThe Origin Story: We Had It Before # Interestingly, when I look back to the early 2000s, people were already working in what I would call a DevOps operating model. You had small teams that did project management, requirements engineering, testing, development, and operations. Everything was in one team, and there were no silos and no walls of confusion.\nThen things got more complicated. Companies decided to scale up software development by creating specialized teams for each discipline. That is when the silos were introduced. The problem is that value does not flow through silos. Instead, things get thrown over walls of confusion, and that is where the problems begin.\nDevOps Starts Before Code # Kerry was surprised when I explained that DevOps starts much earlier than most people think. It begins when the business has a bright idea. Not all ideas are worth turning into a project, so in a DevOps world, you first identify the hypothesis behind the idea and understand what problem you are trying to solve.\nThen you define leading indicators to measure success. You go to the customer with UX methods to validate the hypothesis. You define the minimal amount of architecture needed. You break things down into features and user stories. And you develop with continuous testability and operability in mind. After building the continuous delivery pipeline, you measure whether the hypothesis is true and adapt accordingly.\nThis is the full cycle of the DevOps infinity symbol.\nMeasuring What Matters # When it comes to measuring software delivery performance, I always point to the book Accelerate and the DORA metrics. The four key metrics are:\nLead Time for Changes: How long from code commit until production Deployment Frequency: How often you deploy to production Change Failure Rate: The percentage of deployments causing failures Mean Time to Recovery: How quickly you restore service after an incident It is important to understand the difference between deployment and release. A deployment brings new code into production with the feature toggle off. A release is switching on the feature toggle. This distinction enables high deployment frequency without disrupting users.\nNot every company needs to deploy every 15 minutes. It is perfectly fine to deploy daily or in a two-day cycle. The key is to have a conversation about what makes sense for your context.\nThe Rise of Digital Factories and Platform Engineering # When Kerry asked where DevOps is heading, I shared my vision of the age of industrialization of software development. We are moving toward digital factories where teams work on conveyor belts of automation, continuously delivering their products.\nThese conveyor belts are platforms, built by platform teams doing platform engineering. The platform teams enable the product teams to do DevOps. This is the direction the industry is heading: platforms that reduce cognitive load and let teams focus on delivering value.\n\u0026ldquo;We are entering the age of industrialization of software development. Platform engineering enables product teams to do DevOps.\u0026rdquo;\nAI in DevOps: Already Making an Impact # We also talked about AI. At the time of the podcast, ChatGPT 4 had just been released. I shared that AI is already helping in the operations space through AIOps. At one of my clients, we generate roughly 16 terabytes of telemetry data every day. That is a big data problem, and AI is excellent at pattern matching to identify problem areas and do root cause analysis.\nI predicted that AI will expand beyond planning and building into releasing, monitoring, and deploying. The tools are rapidly evolving, and AI will continue to help us do a better job across the entire DevOps cycle.\nKey Takeaways # DevOps is a mindset first. The culture and product thinking matter more than the tools. Think in products, not projects. Focus on outcome for the customer, not output for the organization. Start with the hypothesis. Before building anything, understand what problem you are solving and how you will measure success. Use DORA metrics wisely. They are scientifically proven, but apply them to your context rather than chasing elite status. Platform engineering is the future. Digital factories with internal developer platforms will enable teams to do DevOps at scale. AI will transform the full DevOps cycle. From planning through monitoring, AI is already making an impact and will continue to grow. ","date":"14 January 2024","externalUrl":null,"permalink":"/en/blogs/devtalk-podcast-the-state-of-devops/","section":"Blogs","summary":"In this episode of the DevTalk podcast, my colleague Kerry Lothrop and I have a conversation about the state of DevOps. We have known each other for many years at Zühlke, and Kerry wanted to pick my brain on what DevOps really means today, where companies struggle, and where the industry is heading.\n","title":"DevTalk Podcast: The State of DevOps","type":"blogs"},{"content":"At the Conf42 DevSecOps 2024 conference, I presented my approach to architecting for continuous delivery. After more than 21 years at Zühlke, working across industries on DevOps transformations, I keep seeing the same fundamental problem: value streams broken by walls of confusion. In this talk, I walk through how organizations can move from project thinking to product thinking, build in quality and security from the start, architect for operability, and use platform engineering to scale it all.\nThe Broken Value Stream # When I visit companies as a consultant, I almost always see the same pattern. The business has bright ideas, writes them into Word documents and Jira tickets, and throws them over the wall of confusion to the development team. The developers implement something and throw it over to testing. The testers look at the requirements (which never quite match what was built), test something, and throw it over to operations. Operations says \u0026ldquo;this will never work in production,\u0026rdquo; but somehow they manage. Finally, the customer sees the result and says: \u0026ldquo;What is that? This does not solve our problem.\u0026rdquo;\nThe blue line running through this picture is the value stream, and it is broken by these walls of confusion. The root cause is silo organizations with different goals, no alignment, legacy systems, inflexible processes, and cultural resistance.\nThese challenges originate from how we have historically done software development. In the past, we delivered in large waterfall batches with fixed scope, budget, and time. Then around 2000, we moved to agile with smaller increments. But we are still doing projects when our clients actually want products.\nFrom Projects to Products # A project focuses on output: deliver these 10 features in six months for 200,000 euros. A product focuses on outcome: solve the customer\u0026rsquo;s problem and change their behavior. DevOps supports this shift because it is a mindset, a culture, and a set of technical practices that allows teams to organize across the value stream and continuously deliver value.\nThe term \u0026ldquo;DevOps\u0026rdquo; itself is not perfect. It implies just development and operations. Some people suggest DevSecOps, BizDevOps, or other variations. I always say we would need something like \u0026ldquo;DevSecBizArcCompQAOps\u0026rdquo; and I am sure I would still forget someone. The point is: DevOps means bringing all people, processes, and technology together to continuously deliver value.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices that brings all people, process, and technology together to continuously deliver value.\u0026rdquo;\nWhy DevOps Matters: The Science # The book Accelerate (The Science of DevOps) identifies 24 key capabilities that drive improvements in software delivery performance. These capabilities span five categories: continuous delivery, architecture, product and process, lean management and monitoring, and culture.\nThe research also maps the relationships between these capabilities. I consider this one of the most important pictures for anyone doing a DevOps transformation: it shows what you need to invest in (left side) to achieve the outcomes you want (right side).\nThe State of DevOps reports compare low performers with high performers. The numbers are massive in deployment frequency, lead time, time to recovery, and change failure rate. The benefits translate to what every CIO wants: faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees.\nBuilding in Quality: Shift Left Testing # Quality is essential for continuous delivery. When you look at companies like SpaceX and Tesla, Elon Musk invests roughly 50% of new product budgets into automated testing. That is how they can deliver fast innovation to the market. Most companies invest far less.\nTraditional testing follows a V-model with delayed feedback. A requirements engineer writes a feature, another writes a story, a developer writes code, and if we are lucky, some tests. Then months later, a tester tests the story and another tester tests the feature. The feedback loop can be three months, six months, or even a year.\nThe alternative is to shift left with Behavior Driven Development (BDD) and Test Driven Development (TDD). Define acceptance criteria in Given/When/Then format upfront, write the test first, then implement the code. This inverts the traditional test pyramid: instead of many slow, expensive end-to-end tests, you get a massive amount of fast, cheap unit tests. The focus shifts from finding bugs to preventing them.\nBuilding in Security: DevSecOps # A continuous delivery pipeline is more than CI/CD. It starts with continuous exploration (ideation, backlog management, requirements engineering) and ends with release on demand (feature toggles). Within this pipeline, security must be built in at every stage:\nPlanning: Threat modeling to analyze attack vectors and mitigate risks Coding: Merge requests and pull requests with peer review Building: Static application security testing, software composition analysis, license compliance, container scanning, secret detection Testing: Dynamic application security testing Production: Penetration testing and continuous security monitoring Architecting for Operability # When we practice \u0026ldquo;you build it, you run it,\u0026rdquo; operability becomes a first-class concern. Proactive detection means our monitoring systems alert us based on tolerance thresholds before customers notice problems. Disaster recovery procedures need to be in place and rehearsed regularly.\nMonitoring has evolved significantly. Two-tier systems needed basic metrics and logs. Three-tier applications required application monitoring with traces. Today\u0026rsquo;s distributed service-oriented architectures demand full observability, often enhanced with AIOps to make sense of the massive amounts of data.\n\u0026ldquo;When architecting a system, a subsystem, or a microservice, you always need to think: how is this going to be operated in production?\u0026rdquo;\nPlatform Engineering: The Key to Scaling # Modern software development requires teams to handle infrastructure, runtimes, CI/CD pipelines, monitoring, security tools, supporting tools, cost management, maintenance, and access management. Oh, and they also want to build an application. When you scale this across multiple teams, you get inconsistencies, redundancies, reinvented wheels, and crushing cognitive load.\nPlatform engineering solves this. A platform team builds a product (the platform) that provides standardized application runtimes, DevSecOps capabilities, access and identity management, monitoring and observability, and CI/CD pipelines. The product teams build, run, and maintain their products on top of this platform.\nThis is not another silo. The platform team creates a product that other teams want to use. The teams still own their products, still operate them, still monitor them. The platform just enables them to do DevOps without reinventing the wheel.\nGartner, BCG, and McKinsey all agree: platform engineering will be critical in the next five years.\nKey Takeaways # Move from projects to products. Put the customer in the center and solve their problems instead of delivering feature lists. Build in quality from the start. Use BDD and TDD to shift testing left. Write tests before code to prevent bugs instead of finding them. Build in security from the start. Apply DevSecOps across the entire delivery pipeline, from threat modeling in planning to continuous monitoring in production. Architect for operability. Think about how every component will be operated in production, and invest in full-stack observability. Use platform engineering to scale. Build a standardized platform so product teams can focus on delivering value instead of managing tools. We are entering the age of industrialized software development. Platform engineering is the foundation that enables teams to practice DevSecOps and continuously deliver value. ","date":"9 January 2024","externalUrl":null,"permalink":"/en/blogs/architecting-continuous-delivery-conf42/","section":"Blogs","summary":"At the Conf42 DevSecOps 2024 conference, I presented my approach to architecting for continuous delivery. After more than 21 years at Zühlke, working across industries on DevOps transformations, I keep seeing the same fundamental problem: value streams broken by walls of confusion. In this talk, I walk through how organizations can move from project thinking to product thinking, build in quality and security from the start, architect for operability, and use platform engineering to scale it all.\n","title":"Architecting for Continuous Delivery at Conf42 DevSecOps 2024","type":"blogs"},{"content":"An der Conf42 DevSecOps 2024 Konferenz habe ich meinen Ansatz zur Architektur für Continuous Delivery vorgestellt. Nach über 21 Jahren bei Zühlke, in denen ich branchenübergreifend an DevOps-Transformationen gearbeitet habe, sehe ich immer wieder dasselbe fundamentale Problem: Wertströme, die durch Mauern der Verwirrung gebrochen werden. In diesem Vortrag zeige ich, wie Organisationen den Weg von Projekt-Denken zu Produkt-Denken schaffen, Qualität und Sicherheit von Anfang an einbauen, für Betreibbarkeit architekturieren und Platform Engineering zur Skalierung nutzen können.\nDer gebrochene Wertstrom # Wenn ich als Berater Unternehmen besuche, sehe ich fast immer dasselbe Bild. Das Business hat grossartige Ideen, schreibt sie in Word-Dokumente und Jira-Tickets und wirft sie über die Mauer der Verwirrung zum Entwicklungsteam. Die Entwickler implementieren etwas und werfen es zum Testing weiter. Die Tester schauen auf die Anforderungen (die nie ganz mit dem Gebauten übereinstimmen), testen etwas und werfen es zum Betrieb weiter. Der Betrieb sagt: \u0026ldquo;Das wird in der Produktion nie funktionieren.\u0026rdquo; Irgendwie schaffen sie es trotzdem. Schliesslich sieht der Kunde das Ergebnis und sagt: \u0026ldquo;Was ist das? Das löst unser Problem nicht.\u0026rdquo;\nDie blaue Linie in diesem Bild ist der Wertstrom, und er wird durch diese Mauern der Verwirrung gebrochen. Die Ursache sind Silo-Organisationen mit unterschiedlichen Zielen, fehlender Abstimmung, Legacy-Systemen, unflexiblen Prozessen und kulturellem Widerstand.\nDiese Herausforderungen stammen aus der Art, wie wir historisch Software entwickelt haben. Früher lieferten wir in grossen Wasserfall-Batches mit fixem Scope, Budget und Zeit. Um 2000 wechselten wir zu Agile mit kleineren Inkrementen. Aber wir machen immer noch Projekte, obwohl unsere Kunden eigentlich Produkte wollen.\nVon Projekten zu Produkten # Ein Projekt fokussiert auf Output: liefere diese 10 Features in sechs Monaten für 200'000 Euro. Ein Produkt fokussiert auf Outcome: löse das Problem des Kunden und verändere sein Verhalten. DevOps unterstützt diesen Wandel, denn es ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das es Teams ermöglicht, sich über den Wertstrom zu organisieren und kontinuierlich Wert zu liefern.\nDer Begriff \u0026ldquo;DevOps\u0026rdquo; selbst ist nicht perfekt. Er impliziert nur Entwicklung und Betrieb. Manche schlagen DevSecOps, BizDevOps oder andere Varianten vor. Ich sage immer, wir bräuchten etwas wie \u0026ldquo;DevSecBizArcCompQAOps\u0026rdquo;, und ich bin sicher, ich würde trotzdem jemanden vergessen. Der Punkt ist: DevOps bedeutet, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.\n«DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das alle Menschen, Prozesse und Technologien zusammenbringt, um kontinuierlich Wert zu liefern.»\nWarum DevOps wichtig ist: Die Wissenschaft # Das Buch Accelerate (The Science of DevOps) identifiziert 24 Schlüsselfähigkeiten, die Verbesserungen in der Software-Delivery-Performance treiben. Diese Fähigkeiten erstrecken sich über fünf Kategorien: Continuous Delivery, Architektur, Produkt und Prozess, Lean Management und Monitoring sowie Kultur.\nDie Forschung bildet auch die Beziehungen zwischen diesen Fähigkeiten ab. Ich betrachte dies als eines der wichtigsten Bilder für jeden, der eine DevOps-Transformation durchführt: Es zeigt, was man investieren muss (linke Seite), um die gewünschten Ergebnisse (rechte Seite) zu erreichen.\nDie State-of-DevOps-Berichte vergleichen Low Performer mit High Performern. Die Zahlen sind massiv bei Deployment-Frequenz, Lead Time, Time to Recovery und Change Failure Rate. Die Vorteile übersetzen sich in das, was jeder CIO möchte: schnellere Time-to-Market, mehr Wert fürs Geld, höhere Qualität, höhere Kundenzufriedenheit und top qualifizierte Mitarbeitende.\nQualität einbauen: Shift Left Testing # Qualität ist essenziell für Continuous Delivery. Wenn man sich Unternehmen wie SpaceX und Tesla anschaut, investiert Elon Musk etwa 50% des Budgets für neue Produkte in automatisiertes Testing. So können sie schnelle Innovation auf den Markt bringen. Die meisten Unternehmen investieren deutlich weniger.\nTraditionelles Testing folgt einem V-Modell mit verzögertem Feedback. Ein Requirements Engineer schreibt ein Feature, ein anderer eine Story, ein Entwickler schreibt Code, und wenn wir Glück haben, auch Tests. Dann, Monate später, testet ein Tester die Story und ein anderer das Feature. Die Feedback-Schleife kann drei Monate, sechs Monate oder sogar ein Jahr dauern.\nDie Alternative ist der Shift Left mit Behavior Driven Development (BDD) und Test Driven Development (TDD). Abnahmekriterien im Given/When/Then-Format vorab definieren, zuerst den Test schreiben, dann den Code implementieren. Das kehrt die traditionelle Testpyramide um: Statt vieler langsamer, teurer End-to-End-Tests erhält man eine massive Menge schneller, günstiger Unit-Tests. Der Fokus verschiebt sich vom Finden von Fehlern zum Verhindern von Fehlern.\nSicherheit einbauen: DevSecOps # Eine Continuous-Delivery-Pipeline ist mehr als CI/CD. Sie beginnt mit Continuous Exploration (Ideenfindung, Backlog Management, Requirements Engineering) und endet mit Release on Demand (Feature Toggles). Innerhalb dieser Pipeline muss Sicherheit in jeder Phase eingebaut sein:\nPlanung: Threat Modeling zur Analyse von Angriffsvektoren und zur Risikominderung Coding: Merge Requests und Pull Requests mit Peer Review Build: Statische Sicherheitsanalyse, Software Composition Analysis, Lizenz-Compliance, Container Scanning, Secret Detection Testing: Dynamische Sicherheitsanalyse Produktion: Penetrationstests und kontinuierliches Sicherheits-Monitoring Architektur für Betreibbarkeit # Wenn wir \u0026ldquo;you build it, you run it\u0026rdquo; praktizieren, wird Betreibbarkeit zu einer erstklassigen Anforderung. Proaktive Erkennung bedeutet, dass unsere Monitoring-Systeme uns basierend auf Toleranzschwellen alarmieren, bevor Kunden Probleme bemerken. Disaster-Recovery-Verfahren müssen vorhanden und regelmässig geübt werden.\nMonitoring hat sich erheblich weiterentwickelt. Zwei-Tier-Systeme brauchten grundlegende Metriken und Logs. Drei-Tier-Anwendungen erforderten Application Monitoring mit Traces. Heutige verteilte, serviceorientierte Architekturen verlangen volle Observability, oft ergänzt durch AIOps, um aus den riesigen Datenmengen Sinn zu machen.\n«Wenn man ein System, ein Subsystem oder einen Microservice architekturiert, muss man immer denken: Wie wird das in der Produktion betrieben?»\nPlatform Engineering: Der Schlüssel zur Skalierung # Moderne Softwareentwicklung erfordert von Teams, dass sie sich um Infrastruktur, Laufzeitumgebungen, CI/CD-Pipelines, Monitoring, Sicherheits-Tools, Support-Tools, Kostenmanagement, Wartung und Zugriffsmanagement kümmern. Ach ja, und sie wollen auch noch eine Anwendung bauen. Wenn man das über mehrere Teams skaliert, entstehen Inkonsistenzen, Redundanzen, neu erfundene Räder und eine erdrückende kognitive Belastung.\nPlatform Engineering löst dieses Problem. Ein Plattform-Team baut ein Produkt (die Plattform), das standardisierte Laufzeitumgebungen, DevSecOps-Fähigkeiten, Zugangs- und Identitätsmanagement, Monitoring und Observability sowie CI/CD-Pipelines bereitstellt. Die Produkt-Teams bauen, betreiben und warten ihre Produkte auf dieser Plattform.\nDas ist kein neues Silo. Das Plattform-Team erstellt ein Produkt, das andere Teams nutzen wollen. Die Teams besitzen weiterhin ihre Produkte, betreiben sie und überwachen sie. Die Plattform ermöglicht es ihnen nur, DevOps zu machen, ohne das Rad neu zu erfinden.\nGartner, BCG und McKinsey sind sich einig: Platform Engineering wird in den nächsten fünf Jahren entscheidend sein.\nKernaussagen # Von Projekten zu Produkten wechseln. Den Kunden ins Zentrum stellen und seine Probleme lösen, statt Feature-Listen abzuarbeiten. Qualität von Anfang an einbauen. BDD und TDD nutzen, um das Testing nach links zu verschieben. Tests vor dem Code schreiben, um Fehler zu verhindern statt zu finden. Sicherheit von Anfang an einbauen. DevSecOps über die gesamte Delivery-Pipeline anwenden, von Threat Modeling in der Planung bis zu kontinuierlichem Monitoring in der Produktion. Für Betreibbarkeit architekturieren. Bei jeder Komponente darüber nachdenken, wie sie in der Produktion betrieben wird, und in Full-Stack Observability investieren. Platform Engineering zur Skalierung nutzen. Eine standardisierte Plattform bauen, damit Produkt-Teams sich auf die Wertlieferung konzentrieren können statt auf Tool-Management. Wir treten in das Zeitalter der industrialisierten Softwareentwicklung ein. Platform Engineering ist das Fundament, das Teams befähigt, DevSecOps zu praktizieren und kontinuierlich Wert zu liefern. ","date":"9. January 2024","externalUrl":null,"permalink":"/de/blogs/architektur-fuer-continuous-delivery-conf42/","section":"Blogs","summary":"An der Conf42 DevSecOps 2024 Konferenz habe ich meinen Ansatz zur Architektur für Continuous Delivery vorgestellt. Nach über 21 Jahren bei Zühlke, in denen ich branchenübergreifend an DevOps-Transformationen gearbeitet habe, sehe ich immer wieder dasselbe fundamentale Problem: Wertströme, die durch Mauern der Verwirrung gebrochen werden. In diesem Vortrag zeige ich, wie Organisationen den Weg von Projekt-Denken zu Produkt-Denken schaffen, Qualität und Sicherheit von Anfang an einbauen, für Betreibbarkeit architekturieren und Platform Engineering zur Skalierung nutzen können.\n","title":"Architektur für Continuous Delivery an der Conf42 DevSecOps 2024","type":"blogs"},{"content":"","date":"9 January 2024","externalUrl":null,"permalink":"/en/tags/testing/","section":"Tags","summary":"","title":"Testing","type":"tags"},{"content":"","date":"3 December 2023","externalUrl":null,"permalink":"/en/tags/accelerate/","section":"Tags","summary":"","title":"Accelerate","type":"tags"},{"content":"","date":"3 December 2023","externalUrl":null,"permalink":"/en/tags/anti-patterns/","section":"Tags","summary":"","title":"Anti-Patterns","type":"tags"},{"content":"Als Chief of DevOps und Partner bei Zühlke helfe ich seit über zwei Jahrzehnten Unternehmen, kontinuierlich Wert zu liefern. In diesem Video gehe ich das komplette DevOps-Angebot von Zühlke durch: von unserem Verständnis von DevOps und den Herausforderungen der Skalierung bis hin zu unseren konkreten Dienstleistungen, einschliesslich der Digital Factory und der Platform Plane.\nDas Problem: Gebrochene Value Streams # Wenn ich Unternehmen besuche, begegne ich häufig dem gleichen Bild. Das Business erstellt grossartige Pläne in Jira-Tickets und Word-Dokumenten und wirft sie über eine Wall of Confusion zur Entwicklung. Die Entwicklung implementiert etwas und wirft es über eine weitere Mauer zum Testing. Das Testing prüft es und wirft es zum Betrieb. Der Betrieb kämpft damit, es zum Laufen zu bringen, und der Kunde sagt: \u0026ldquo;Das ist nicht das, was wir wollten.\u0026rdquo;\nDie Grundursache ist die Siloorganisation. Business, Entwicklung, Testing und Betrieb arbeiten alle in separaten Silos mit unterschiedlichen Zielen und ohne echte Abstimmung. Der Value Stream, dargestellt als blaues Unendlichkeitssymbol, wird durch Walls of Confusion unterbrochen. Es fehlt auch an Software Engineering Excellence über den gesamten Value Stream hinweg.\nDevOps ist die Lösung. Es ist ein Mindset, eine Kultur und ein Satz technischer Praktiken, die uns erlauben, uns über den Value Stream hinweg zu organisieren, sodass alle Menschen zusammenarbeiten, um kontinuierlich Wert für den Kunden zu liefern.\nDevOps dreht sich darum, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. Das ist DevOps.\nDie Herausforderung der DevOps-Skalierung # Die Zahlen sprechen für sich. Die State of DevOps Reports zeigen, dass High Performer 973-mal mehr Deployments erreichen als Low Performer. DevOps liefert schnellere Time to Market, mehr Wert für das Geld, höhere Qualität, höhere Kundenzufriedenheit und top qualifizierte Mitarbeitende. Jeder CIO will genau das.\nAber DevOps in einem Team zu machen ist bereits eine Herausforderung. DevOps im grossen Massstab zu skalieren ist noch schwieriger. Manche Unternehmen versuchen es mit einem \u0026ldquo;DevOps-Team\u0026rdquo; zwischen Entwicklung und Betrieb, was nur ein weiteres Silo einführt. Die echte Lösung sind Produkt-Teams mit allen Menschen zusammen. Aber das bringt Inkonsistenzen, Redundanzen und eine massive kognitive Last.\nAllein das Tooling ist überwältigend. Die Continuous-Delivery-Pipeline beginnt und endet nicht mit CI/CD. Sie umfasst Continuous Exploration (Requirements Engineering, Backlog Management), Continuous Integration, Continuous Deployment und Release on Demand mit Feature Toggles. Jeder dieser Bereiche erfordert spezialisierte Tools, die gewartet und integriert werden müssen. Dazu kommt, dass Teams alle technischen Praktiken moderner Softwareentwicklung beherrschen, das Onboarding neuer Leute bewältigen (was Tage oder Wochen für die Zugangsberechtigung dauern kann) und sowohl Qualität als auch Sicherheit sicherstellen müssen.\nDie Digital Factory: Das Zielbild # Was jedes Unternehmen braucht, ist eine Digital Factory. Auf der obersten Ebene hat ein Verwaltungsrat eine Vision und Strategie. Ein Portfolio-Kanban enthält alle grossen Ideen als Epics. Der Verwaltungsrat priorisiert und wählt die vielversprechendsten Epics aus. Das Produktmanagement bricht Epics in Features herunter. Produkt-Teams arbeiten agil und zerlegen Features in User Stories, die durch die Continuous-Delivery-Pipeline fliessen.\nDas Platform-Engineering-Team stellt standardisierte Pipelines für neue Teams bereit, damit diese sofort produktiv sind. Das gesamte System liefert Wert an den Kunden, bekommt Feedback zurück und lernt kontinuierlich. Das sind die drei Wege von DevOps.\nDie Digital Factory hat vier Ebenen:\nLean Portfolio Management verbindet Strategie mit Umsetzung Produktmanagement organisiert Teams, die an Produkten arbeiten Produkt-Teams praktizieren DevOps, bauen, betreiben und verantworten ihre Produkte Platform-Team entwickelt, baut und wartet die Plattform Das Platform-Team stellt standardisierte Tools bereit, damit Produkt-Teams effizient arbeiten können. Die Plattform umfasst Application Runtime und Compute, DevSecOps (automatisierte Sicherheit nach links verschieben), Access und Identity (Onboarding am Morgen, Offboarding am Abend), zentralisierte Sicherheit, Observability und Monitoring, und alles was Teams brauchen, um sich auf Feature-Entwicklung statt Infrastruktur zu konzentrieren.\nDas Zühlke DevOps Angebot # Zühlke ist ein globaler Dienstleister mit über 2.000 Mitarbeitenden in 17 Büros in zehn Ländern. 1968 gegründet, ist es nach wie vor in Partnerhand. Die Fähigkeiten umfassen Digital Consulting, KI und Data, Cloud, Cybersecurity, Digital Experience, Software Excellence, Hardware- und Elektronikentwicklung und DevOps.\nUnser DevOps-Angebot hat sechs Säulen:\n1. DevOps Engineering und Consulting: Alles von Value Stream Engineering bis Continuous Delivery und Release-Orchestrierung. Wir helfen beim Übergang von Projekten zu Produkten mit modernster Produktlieferung.\n2. Qualität und Continuous Testing: Man kann nicht skalieren, wenn die Qualität schlecht ist. Shift Left, Qualität von Anfang an einbauen, in Testautomatisierung und Continuous Testing investieren.\n3. Digital Factory: Ein Lean-Transformationsansatz für mehrere Teams, ganze Organisationen oder das gesamte Unternehmen. Er transformiert die Organisation in eine Digital Factory, die kontinuierlich Wert liefert, Durchlaufzeiten reduziert, Qualität verbessert und Kundenzufriedenheit sowie Mitarbeiterzufriedenheit steigert. Komplett massgeschneidert, basierend auf Blueprints und Bausteinen.\n4. Platform Engineering: Implementierung einer internen Entwicklerplattform mit Observability, Metriken und Kubernetes as a Service. Das ist die Grundlage der Digital Factory.\n5. Application Modernization: Für Unternehmen mit Legacy-Anwendungen und Landschaften. Wir machen Software-Evaluation, Enterprise Architecture und Transformation einzelner Anwendungen oder kompletter Landschaften.\n6. Turnaround: Wenn ein Projekt oder Produkt in Schwierigkeiten ist, helfen wir, es wieder auf Kurs zu bringen, es zuverlässiger und resilienter zu machen und die Release-Fähigkeit zu steigern.\nDie Platform Plane # Die Platform Plane ist ein Accelerator-Asset von Zühlke. Sie verbindet Best-of-Breed-Tools zu einer herausragenden Benutzererfahrung. Sie ist viel mehr als nur ein Entwicklerportal.\nDie Platform Plane umfasst:\nApplication Runtime und Compute: Kubernetes as a Service, API Gateway, Service Catalog und Managed Ingress Developer Experience: Portal, CLI, Application Templates, Networking und Tunneling DevSecOps: Automatisierte Software Composition Analysis, Secret Detection, SAST und License Scanning Access und Identity: Self-Onboarding für Teams mit sofortigem Zugang zu allen verbundenen Tools Zentralisierte Sicherheit: Firewall-Support, WAF-Support und Netzwerktopologien out of the box Observability: Open-Telemetry-Stack, Managed Dashboards und FinOps-KPIs GitOps: CI/CD-Pipelines, Secret Management und fertige Pipeline-Templates Die Architektur integriert Tools über Adapter. Tools werden nicht zu einem grossen Klumpen zusammengeschweisst. Jedes Tool wird über einen Adapter und einen einheitlichen Integrationsblock integriert, dann durch eine Automatisierungs- und Provisioning-Schicht verbunden. Das ermöglicht es, neue Tools einfach hinzuzufügen und bestehende Tools bei Bedarf auszutauschen.\nWir treten in das Zeitalter der Industrialisierung der Softwareentwicklung ein. Platform Engineering baut die Plattform, die Grundlage eurer Digital Factory, und ermöglicht euren Teams, DevOps zu machen.\nWas eine ganzheitliche Digital Factory erfordert # Der Aufbau einer Digital Factory erfordert einen ganzheitlichen Ansatz:\nSkalierbare Architektur mit guten APIs für die Produktentwicklung DevOps und Software Engineering Praktiken über den gesamten Value Stream Eine Plattform als Fundament für die Produktentwicklung Daten und Analytics, damit Management und Teams die richtigen Entscheidungen treffen können Kundenzentrierung mit einer grossartigen End-to-End Customer Experience Agile Product Delivery mit Backlog Management, Dependency Management und Team Management Produktmanagement mit Lean Portfolio Management, das Strategie mit Umsetzung verbindet Kernaussagen # Gebrochene Value Streams aus Siloorganisationen sind die Grundursache für langsame, qualitativ schlechte Softwarelieferung DevOps im grossen Massstab erfordert einen Digital-Factory-Ansatz mit Lean Portfolio Management, Produktmanagement, Produkt-Teams und einem Platform-Team Das Platform-Team stellt eine standardisierte Plattform bereit, damit Produkt-Teams sich auf Feature-Lieferung konzentrieren können Zühlke bietet sechs DevOps-Services: Engineering und Consulting, Qualität, Digital Factory, Platform Engineering, Application Modernization und Turnaround Die Platform Plane integriert Best-of-Breed-Tools über Adapter, sodass Tools ausgetauscht werden können, ohne die Plattform zu stören Die Digital Factory ist ein ganzheitlicher Lean-Transformationsansatz, der Architektur, DevOps, Plattform, Daten, Customer Experience und agile Delivery abdeckt ","date":"3. December 2023","externalUrl":null,"permalink":"/de/blogs/das-zuehlke-devops-angebot/","section":"Blogs","summary":"Als Chief of DevOps und Partner bei Zühlke helfe ich seit über zwei Jahrzehnten Unternehmen, kontinuierlich Wert zu liefern. In diesem Video gehe ich das komplette DevOps-Angebot von Zühlke durch: von unserem Verständnis von DevOps und den Herausforderungen der Skalierung bis hin zu unseren konkreten Dienstleistungen, einschliesslich der Digital Factory und der Platform Plane.\n","title":"Das Zühlke DevOps Angebot: Von DevOps Engineering bis zur Digital Factory","type":"blogs"},{"content":"DevOps transformations look simple on paper. Take an existing environment, add the Spotify model, throw in SAFe, sprinkle some Team Topologies, add DevOps and platform engineering, stir well, add as many tools as possible, and stir again. What happens? It crashes. And people say \u0026ldquo;DevOps is bullshit.\u0026rdquo;\nThe problem is not DevOps. The problem is how organizations approach the transformation. In this video, I share the anti-patterns and lessons learned from my years of doing DevOps transformations across industries at Zühlke.\nWhat Companies Want to Achieve # Before diving into the anti-patterns, let me clarify what companies actually want from a DevOps transformation. The top five goals I encounter are:\nMore value for the money (increased efficiency) Faster time to market Higher quality Higher customer satisfaction Top qualified employees (winning the war for talent) And the challenges they face? Legacy systems and processes, budget constraints, talent management, culture and change management, and the alignment between IT and business.\nAnti-Pattern 1: Missing Sense of Urgency # The first lesson learned is about the sense of urgency at the C-level. When top management lacks urgency, the transformation becomes a series of meetings with many PowerPoints but no decisions. Topics get discussed endlessly without progress.\nThe sense of urgency can come from two sources: a burning platform (the company must change now) or a visible future threat (a challenger is coming). When management wants to do a DevOps transformation, I always ask \u0026ldquo;Why?\u0026rdquo; at least five times to get to the root cause.\nI use Dr. John P. Kotter\u0026rsquo;s Eight Steps of Leading Change, where the first step is creating that sense of urgency. If you cannot establish urgency at the C-level, you can stop right there. You will only achieve a small transformation because you lack the mandate for big changes.\n\u0026ldquo;If you don\u0026rsquo;t have a sense of urgency at the C-level, the only thing you will do is a small DevOps transformation.\u0026rdquo;\nAnti-Pattern 2: Missing Leadership Commitment # Even when the C-level has the sense of urgency, middle management can block progress. They like the status quo. They fear losing control and influence. They focus on short-term wins and may completely lack understanding of what a DevOps transformation aims to achieve.\nThe solutions:\nPeer learning: Connect your managers with peers from companies that have already done the transformation. This is one of the best recommendations I can give. Education and training: Middle managers need to understand DevOps to lead the change. Clear expectations: The C-level must set explicit goals, KPIs, and measurements for the transformation. Business alignment: Extend the transformation beyond IT to include the business, or face massive resistance. External experts: Engage people who have been through it before. Anti-Pattern 3: One-Size-Fits-All # \u0026ldquo;We implemented the Spotify model.\u0026rdquo; \u0026ldquo;At Google, they do it this way.\u0026rdquo; This is a dangerous path. Your context is different. When you implement a framework by the book without thinking, you get confusion, resistance, and relabeling. Your three-month release cycle becomes a \u0026ldquo;PI\u0026rdquo; (Program Increment). Your project manager gets the new title \u0026ldquo;RTE\u0026rdquo; or \u0026ldquo;Scrum Master.\u0026rdquo; Nothing actually changes.\nThe solution: define your own values, not the values of a framework. Define your principles that guide decisions. Define outcomes, not outputs. Establish a clear purpose that answers your employees\u0026rsquo; question: \u0026ldquo;What is in it for me?\u0026rdquo; And always inspect and adapt.\n\u0026ldquo;Use frameworks as a toolbox. Take out what fits your need and solves your problem. Do not apply them by the book.\u0026rdquo;\nAnti-Pattern 4: Forming a DevOps Team # This happens on the lower management level: \u0026ldquo;We want to do a little bit of DevOps, so let us create a DevOps team.\u0026rdquo; That DevOps team becomes just another silo between development and operations, adding more walls of confusion to the value stream.\nThe root cause is resistance to change. The solution is to have a clear goal, adopt a product mindset, organize across the value stream, and apply budgeting according to value streams instead of departments.\nAnti-Pattern 5: Busyness # Everyone is busy. Calendars are completely full. Everything is done to only 60%. There is no excellence. And burnout rates are high.\nThe root cause is multi-loading: people assigned to multiple roles, multiple products, and multiple projects simultaneously. I regularly encounter people assigned to 10% across ten different projects. They can attend meetings and align, but they cannot create real value.\nMy rule: people contributing to a product or project must work at least 60% on that single product or project. If they cannot, they are not part of the team (they might be subject matter experts, but they are not contributors). If you cannot find enough people at 60% or more, you do not start the project, or you stop another one first. This is nothing else than limiting work in process by limiting capacity.\nAnti-Pattern 6: Going Full DevOps Without a Platform # \u0026ldquo;All product teams will now do you-build-it-you-run-it and handle everything themselves.\u0026rdquo; The result: inconsistency, redundancy, bad time-to-productivity, and burnout. The cognitive load is simply too high when every team must manage infrastructure, CI/CD, monitoring, security, tooling, and cost management on their own.\nThe solution is platform engineering. A platform team builds a centralized platform with standardized tooling, secured environments, and self-service capabilities. Product teams build on top of this platform. They still own their products, but the platform reduces their cognitive load so they can focus on creating value.\nThis is not a new silo. The platform team creates a product that other teams want to use.\nThe Digital Factory: Putting It All Together # When you apply all these lessons, you arrive at the digital factory model:\nBoard level: Lean portfolio management with a clear vision and prioritized initiatives based on monitoring data Product level: Product management that connects strategy with execution Team level: Empowered product teams that build, run, and maintain their products Platform level: A platform team that provides the foundation with standardized DevSecOps, runtime, security, monitoring, and CI/CD The platform team generates value for the teams. The product teams generate value for the customers. Data flows from monitoring back to teams for improvement, and back to the board for strategic decisions.\nSuccess Criteria for DevOps Transformations # Know what you want to achieve. Get C-level backup, define clear goals and outcomes (not outputs), and take a holistic view. Your context is different. Use frameworks as a toolbox, not a prescription. Use your brain. Leadership, leadership, leadership. Leaders must lead by example with an agile mindset. If leadership does not go first, it will not work. Build the right thing. Use lean portfolio management to prioritize initiatives and focus on outcomes. Build the thing right. Invest in platform engineering, standards, and quality. Hire software engineers, not programmers. You need engineering discipline, not just coding skill. You are never done. A DevOps transformation is not a project. It requires continuous improvement forever. Key Takeaways # Sense of urgency is non-negotiable. Without it at the C-level, you will only achieve marginal improvements. Leadership commitment at every level is essential. Use peer learning to bring resistant managers along. Never apply frameworks blindly. Define your own values, principles, and outcomes. Inspect and adapt continuously. Avoid creating DevOps silos. Organize across the value stream with empowered product teams. Fight busyness with focus. Enforce a 60% minimum allocation per person per product. Limit work in process. Platform engineering prevents cognitive overload. A standardized platform enables product teams to do DevOps at scale. We are entering the age of industrialized software development. Digital factories, built on platform engineering, are how organizations will continuously deliver value. ","date":"3 December 2023","externalUrl":null,"permalink":"/en/blogs/devops-transformation-lessons-learned/","section":"Blogs","summary":"DevOps transformations look simple on paper. Take an existing environment, add the Spotify model, throw in SAFe, sprinkle some Team Topologies, add DevOps and platform engineering, stir well, add as many tools as possible, and stir again. What happens? It crashes. And people say “DevOps is bullshit.”\n","title":"DevOps Transformations: My Lessons Learned","type":"blogs"},{"content":"DevOps-Transformationen sehen auf dem Papier einfach aus. Man nehme eine bestehende Umgebung, füge das Spotify-Modell hinzu, werfe SAFe dazu, streue etwas Team Topologies ein, packe DevOps und Platform Engineering obendrauf, rühre gut um, füge so viele Tools wie möglich hinzu und rühre nochmal. Was passiert? Es kracht. Und die Leute sagen: \u0026ldquo;DevOps ist Quatsch.\u0026rdquo;\nDas Problem ist nicht DevOps. Das Problem ist, wie Organisationen die Transformation angehen. In diesem Video teile ich die Anti-Patterns und Erfahrungen aus meinen Jahren von DevOps-Transformationen in verschiedenen Branchen bei Zühlke.\nWas Unternehmen erreichen wollen # Bevor wir in die Anti-Patterns eintauchen, lassen Sie mich klären, was Unternehmen tatsächlich von einer DevOps-Transformation erwarten. Die fünf häufigsten Ziele, die mir begegnen:\nMehr Wert fürs Geld (gesteigerte Effizienz) Schnellere Time-to-Market Höhere Qualität Höhere Kundenzufriedenheit Top qualifizierte Mitarbeitende (den Kampf um Talente gewinnen) Und die Herausforderungen? Legacy-Systeme und -Prozesse, Budgetbeschränkungen, Talentmanagement, Kultur und Change Management sowie die Abstimmung zwischen IT und Business.\nAnti-Pattern 1: Fehlendes Dringlichkeitsgefühl # Die erste Erfahrung betrifft das Dringlichkeitsgefühl auf C-Level. Wenn dem Top-Management die Dringlichkeit fehlt, wird die Transformation zu einer Serie von Meetings mit vielen PowerPoints, aber ohne Entscheidungen. Themen werden endlos diskutiert ohne Fortschritt.\nDas Dringlichkeitsgefühl kann aus zwei Quellen stammen: eine brennende Plattform (das Unternehmen muss sich jetzt ändern) oder eine sichtbare zukünftige Bedrohung (ein Herausforderer kommt). Wenn das Management eine DevOps-Transformation will, frage ich immer mindestens fünfmal \u0026ldquo;Warum?\u0026rdquo;, um zur Wurzel zu gelangen.\nIch verwende Dr. John P. Kotters Acht Schritte des Change Managements, wobei der erste Schritt das Schaffen eines Dringlichkeitsgefühls ist. Wenn man keine Dringlichkeit auf C-Level etablieren kann, kann man gleich aufhören. Man wird nur eine kleine Transformation erreichen, weil das Mandat für grosse Veränderungen fehlt.\n«Wenn man kein Dringlichkeitsgefühl auf C-Level hat, wird man nur eine kleine DevOps-Transformation erreichen.»\nAnti-Pattern 2: Fehlendes Führungscommitment # Selbst wenn das C-Level das Dringlichkeitsgefühl hat, kann das mittlere Management den Fortschritt blockieren. Sie mögen den Status quo. Sie fürchten den Verlust von Kontrolle und Einfluss. Sie fokussieren auf kurzfristige Erfolge und haben möglicherweise gar kein Verständnis dafür, was eine DevOps-Transformation erreichen soll.\nDie Lösungen:\nPeer Learning: Die eigenen Manager mit Gleichgesinnten aus Unternehmen verbinden, die die Transformation bereits durchgeführt haben. Das ist eine meiner besten Empfehlungen. Ausbildung und Training: Das mittlere Management muss DevOps verstehen, um den Wandel zu führen. Klare Erwartungen: Das C-Level muss explizite Ziele, KPIs und Messgrössen für die Transformation setzen. Business-Alignment: Die Transformation über die IT hinaus auf das Business ausweiten, sonst droht massiver Widerstand. Externe Experten: Menschen einbeziehen, die das schon durchgemacht haben. Anti-Pattern 3: Einheitslösung für alle # \u0026ldquo;Wir haben das Spotify-Modell implementiert.\u0026rdquo; \u0026ldquo;Bei Google machen sie es so.\u0026rdquo; Das ist ein gefährlicher Weg. Euer Kontext ist anders. Wenn man ein Framework unreflektiert nach Lehrbuch implementiert, bekommt man Verwirrung, Widerstand und Umetikettierung. Der Drei-Monats-Releasezyklus wird zum \u0026ldquo;PI\u0026rdquo; (Program Increment). Der Projektmanager bekommt den neuen Titel \u0026ldquo;RTE\u0026rdquo; oder \u0026ldquo;Scrum Master.\u0026rdquo; Tatsächlich ändert sich nichts.\nDie Lösung: Eigene Werte definieren, nicht die Werte eines Frameworks. Eigene Prinzipien definieren, die Entscheidungen leiten. Outcomes definieren, nicht Outputs. Einen klaren Zweck etablieren, der die Frage der Mitarbeitenden beantwortet: \u0026ldquo;Was habe ich davon?\u0026rdquo; Und immer Inspect und Adapt betreiben.\n«Nutzt Frameworks als Werkzeugkasten. Nehmt heraus, was zu eurem Bedarf passt und euer Problem löst. Wendet sie nicht nach Lehrbuch an.»\nAnti-Pattern 4: Ein DevOps-Team bilden # Das passiert auf der unteren Managementebene: \u0026ldquo;Wir wollen ein bisschen DevOps machen, also erstellen wir ein DevOps-Team.\u0026rdquo; Dieses DevOps-Team wird nur ein weiteres Silo zwischen Entwicklung und Betrieb und fügt dem Wertstrom weitere Mauern der Verwirrung hinzu.\nDie Ursache ist Widerstand gegen Veränderung. Die Lösung: ein klares Ziel haben, ein Produkt-Mindset übernehmen, sich über den Wertstrom organisieren und die Budgetierung nach Wertströmen statt nach Abteilungen ausrichten.\nAnti-Pattern 5: Geschäftigkeit # Alle sind beschäftigt. Kalender sind komplett voll. Alles wird nur zu 60% erledigt. Es gibt keine Exzellenz. Und die Burnout-Raten sind hoch.\nDie Ursache ist Multi-Loading: Menschen, die gleichzeitig mehreren Rollen, mehreren Produkten und mehreren Projekten zugewiesen sind. Ich begegne regelmässig Menschen, die zu 10% auf zehn verschiedenen Projekten eingeteilt sind. Sie können an Meetings teilnehmen und abstimmen, aber keinen echten Wert schaffen.\nMeine Regel: Menschen, die zu einem Produkt oder Projekt beitragen, müssen mindestens 60% ihrer Zeit auf dieses eine Produkt oder Projekt verwenden. Wenn das nicht möglich ist, sind sie nicht Teil des Teams (sie können Fachexperten sein, aber sie sind keine Wertschöpfer). Wenn man nicht genügend Leute mit 60% oder mehr findet, startet man das Projekt nicht, oder man stoppt zuerst ein anderes. Das ist nichts anderes als Work in Process begrenzen durch Kapazitätslimitierung.\nAnti-Pattern 6: Volles DevOps ohne Plattform # \u0026ldquo;Alle Produkt-Teams machen jetzt You-Build-It-You-Run-It und kümmern sich um alles selbst.\u0026rdquo; Das Ergebnis: Inkonsistenz, Redundanz, schlechte Time-to-Productivity und Burnout. Die kognitive Belastung ist schlicht zu hoch, wenn jedes Team Infrastruktur, CI/CD, Monitoring, Security, Tooling und Kostenmanagement selbst managen muss.\nDie Lösung ist Platform Engineering. Ein Plattform-Team baut eine zentralisierte Plattform mit standardisiertem Tooling, gesicherten Umgebungen und Self-Service-Fähigkeiten. Produkt-Teams bauen auf dieser Plattform auf. Sie besitzen weiterhin ihre Produkte, aber die Plattform reduziert ihre kognitive Belastung, damit sie sich auf die Wertschöpfung konzentrieren können.\nDas ist kein neues Silo. Das Plattform-Team erstellt ein Produkt, das andere Teams nutzen wollen.\nDie digitale Fabrik: Alles zusammenfügen # Wenn man all diese Erfahrungen anwendet, gelangt man zum Modell der digitalen Fabrik:\nVorstandsebene: Lean Portfolio Management mit einer klaren Vision und priorisierten Initiativen basierend auf Monitoring-Daten Produktebene: Produktmanagement, das Strategie mit Ausführung verbindet Teamebene: Befähigte Produkt-Teams, die ihre Produkte bauen, betreiben und warten Plattformebene: Ein Plattform-Team, das das Fundament mit standardisiertem DevSecOps, Laufzeitumgebung, Security, Monitoring und CI/CD bereitstellt Das Plattform-Team schafft Wert für die Teams. Die Produkt-Teams schaffen Wert für die Kunden. Daten fliessen vom Monitoring zurück an die Teams zur Verbesserung und zurück an den Vorstand für strategische Entscheidungen.\nErfolgskriterien für DevOps-Transformationen # Wissen, was man erreichen will. Rückendeckung vom C-Level holen, klare Ziele und Outcomes (nicht Outputs) definieren und eine ganzheitliche Sicht einnehmen. Euer Kontext ist anders. Frameworks als Werkzeugkasten nutzen, nicht als Rezept. Den eigenen Kopf einsetzen. Führung, Führung, Führung. Führungskräfte müssen mit gutem Beispiel vorangehen und ein agiles Mindset haben. Wenn die Führung nicht vorangeht, funktioniert es nicht. Das Richtige bauen. Lean Portfolio Management nutzen, um Initiativen zu priorisieren und auf Outcomes zu fokussieren. Die Sache richtig bauen. In Platform Engineering, Standards und Qualität investieren. Software Engineers einstellen, keine Programmierer. Man braucht Engineering-Disziplin, nicht nur Coding-Fähigkeiten. Man ist nie fertig. Eine DevOps-Transformation ist kein Projekt. Sie erfordert kontinuierliche Verbesserung auf Dauer. Kernaussagen # Dringlichkeitsgefühl ist nicht verhandelbar. Ohne Dringlichkeit auf C-Level erreicht man nur marginale Verbesserungen. Führungscommitment auf jeder Ebene ist essenziell. Peer Learning nutzen, um zögerliche Manager mitzunehmen. Nie Frameworks blind anwenden. Eigene Werte, Prinzipien und Outcomes definieren. Kontinuierlich Inspect und Adapt betreiben. DevOps-Silos vermeiden. Sich über den Wertstrom mit befähigten Produkt-Teams organisieren. Geschäftigkeit mit Fokus bekämpfen. Mindestens 60% Zuordnung pro Person pro Produkt durchsetzen. Work in Process begrenzen. Platform Engineering verhindert kognitive Überlastung. Eine standardisierte Plattform ermöglicht Produkt-Teams, DevOps im grossen Massstab zu betreiben. Wir treten in das Zeitalter der industrialisierten Softwareentwicklung ein. Digitale Fabriken, aufgebaut auf Platform Engineering, sind der Weg, wie Organisationen kontinuierlich Wert liefern. ","date":"3. December 2023","externalUrl":null,"permalink":"/de/blogs/devops-transformation-erfahrungen-und-anti-patterns/","section":"Blogs","summary":"DevOps-Transformationen sehen auf dem Papier einfach aus. Man nehme eine bestehende Umgebung, füge das Spotify-Modell hinzu, werfe SAFe dazu, streue etwas Team Topologies ein, packe DevOps und Platform Engineering obendrauf, rühre gut um, füge so viele Tools wie möglich hinzu und rühre nochmal. Was passiert? Es kracht. Und die Leute sagen: “DevOps ist Quatsch.”\n","title":"DevOps-Transformationen: Meine Erfahrungen und Anti-Patterns","type":"blogs"},{"content":"In diesem Video tauche ich tief in die Wissenschaft hinter DevOps ein. Insbesondere schaue ich mir die DORA-Metriken an, woher sie kommen und welches Buch die wissenschaftliche Grundlage für alles liefert, was wir über leistungsstarke Software-Delivery-Organisationen wissen: Accelerate.\nDas Buch Accelerate # Das Buch Accelerate: The Science of Lean Software and DevOps wurde 2018 veröffentlicht und hat 288 Seiten. Ich empfehle es jedem, der an DevOps oder an einer DevOps-Transformation arbeitet. Es ist das Buch, das man gelesen haben muss.\nDas Buch wurde von drei bemerkenswerten Autoren geschrieben. Dr. Nicole Forsgren hat die Forschung durchgeführt und das Startup DORA (DevOps Research and Assessment) gegründet. Jez Humble ist bekannt für seine Bücher Continuous Delivery und The DevOps Handbook. Gene Kim ist bekannt für The Phoenix Project, The Unicorn Project und ist Co-Autor des DevOps Handbook. Er hat auch den DevOps Enterprise Summit ins Leben gerufen. Diese drei Bücher, Accelerate, The DevOps Handbook und The Phoenix Project, bilden die essenzielle Leseliste für jeden im DevOps-Bereich.\nDas Buch besteht aus drei Teilen. Teil eins beschreibt die Ergebnisse: die 24 Schlüsselfähigkeiten, die durch die Forschung entdeckt wurden. Teil zwei behandelt die Wissenschaft, einschliesslich aller statistischen Analysetechniken. Teil drei ist eine Fallstudie von ING über ihre DevOps-Transformation und dient als Blaupause. Wenn du wenig Zeit hast, lies zumindest Teil eins.\nDie 24 Schlüsselfähigkeiten # Das Beeindruckendste an Accelerate ist, dass die Autoren Unternehmen wissenschaftlich analysiert haben, die DevOps betreiben, und 24 Schlüsselfähigkeiten gefunden haben, die Verbesserungen in der Software-Delivery-Performance treiben. Diese sind in fünf Kategorien organisiert:\nContinuous-Delivery-Fähigkeiten: Versionskontrolle, Deployment-Automatisierung, Continuous Integration, Trunk-basierte Entwicklung, Testautomatisierung, Testdatenmanagement, Shift-Left-Security und Continuous Delivery.\nArchitektur-Fähigkeiten: Lose gekoppelte Architektur und die Befähigung der Teams, eigene Entscheidungen zu treffen.\nProdukt- und Prozessfähigkeiten: Kundenfeedback, Organisation entlang des Wertstroms, Arbeit in kleinen Batches und die Möglichkeit für Teams, zu experimentieren.\nLean-Management- und Monitoring-Fähigkeiten: Change Advisory Boards sind wirkungslos (die Wissenschaft hat das bestätigt). Man sollte Monitoring-Systeme haben, proaktive Benachrichtigungen einsetzen, Work in Process begrenzen und die Arbeit über den Wertstrom hinweg visualisieren.\nKulturelle Fähigkeiten: Westrum-Organisationskultur (generativ statt bürokratisch oder pathologisch), unterstütztes Lernen, Zusammenarbeit über Teams hinweg, Arbeitszufriedenheit und transformationale Führung.\n„Die Wissenschaft hat herausgefunden, dass Change Advisory Boards wirkungslos sind. Viele Prozesse sind überflüssig, weil man sie bereits mit der Pipeline automatisiert hat.\u0026quot;\nWas diese Forschung aussergewöhnlich macht, sind nicht nur die Fähigkeiten selbst, sondern die Beziehungen zwischen ihnen. Das Buch liefert ein Bild, das zeigt, wie diese Fähigkeiten sich gegenseitig beeinflussen. Auf der rechten Seite steht, was man erreichen möchte. Auf der linken Seite steht, was man tun muss, um das zu erreichen. Für mich ist das das Referenzbild für jede DevOps-Transformation.\nDie DORA-Metriken # Wie misst man die Software-Delivery-Performance? Es ist nicht die Team-Velocity. Es sind nicht die Codezeilen. Es ist nicht die Anzahl der Commits oder die Testabdeckung. Die wissenschaftlich bewiesenen Metriken sind die DORA-Metriken:\nLead Time for Changes: Wie lange es vom Code-Commit bis zur Produktion dauert. Die Zeit vor dem Code-Commit (Ideation, Requirements, Implementierung) ist nicht enthalten, weil sie statistisch nicht signifikant ist. Elite-Performer schaffen das in weniger als einer Stunde. High liegt bei einem Tag bis einer Woche. Medium bei einem Monat bis sechs Monaten. Low bei mehr als sechs Monaten.\nDeployment Frequency: Wie oft man in die Produktion deployt. Zur Erinnerung: Ein Deployment bringt Code in die Produktion mit ausgeschaltetem Feature Toggle. Ein Release ist das Einschalten des Toggles. Elite-Organisationen deployen auf Abruf, mehrmals täglich. High bedeutet einmal täglich bis einmal wöchentlich.\nTime to Restore Service: Wie lange man braucht, um sich von einem Vorfall zu erholen. Elite-Teams stellen den Service innerhalb einer Stunde wieder her. Diese Metrik ist eng mit Lead Time und Deployment Frequency verknüpft.\nChange Failure Rate: Der Prozentsatz der Deployments, die einen Fehler verursachen. Elite liegt bei 0 bis 15 %. High und Medium bei 16 bis 30 %. Low bei 31 bis 45 %.\nWichtig: Betrachte immer mindestens zwei Metriken, eine aus dem Bereich Geschwindigkeit (Lead Time, Deployment Frequency) und eine aus dem Bereich Stabilität (Time to Restore, Change Failure Rate). Nur auf Geschwindigkeit oder nur auf Stabilität zu optimieren, ergibt ein verzerrtes Bild.\nDie Zahlen sprechen für sich # Die State-of-DevOps-Berichte vergleichen Elite-Performer mit Low-Performern. Der Bericht von 2019 zeigt, dass Elite-Unternehmen folgende Vorteile haben:\n208x häufigere Deployments 106x schnellere Lead Time 2604x schnellere Wiederherstellung des Service 7x niedrigere Change Failure Rate Bis 2021 waren diese Zahlen noch grösser geworden. Der Markt beschleunigt sich. Elite-Organisationen werden schneller, und die Kluft zwischen Elite- und Low-Performern wächst weiter.\nDie Vorteile sind klar: schnellere Time to Market, mehr Wert für das Geld, höhere Qualität, höhere Kundenzufriedenheit und top-qualifizierte Mitarbeitende. Genau das wollen CIOs.\nDie Entwicklung über die Zeit # Betrachtet man die State-of-DevOps-Daten über die Zeit, gab es 2018 nur wenige Elite-Unternehmen, viele High-Performer, einige im Medium-Bereich und einen grossen Anteil Low-Performer. Im Laufe der Jahre sind mehr Unternehmen auf Elite- und High-Level aufgestiegen. Die Low-Performer haben sich entweder verbessert oder sind vom Markt verschwunden.\nKernaussagen # Lies Accelerate. Es ist das essenzielle Buch für jeden, der im DevOps-Bereich arbeitet. Lies mindestens Teil eins. Fokussiere dich auf die 24 Schlüsselfähigkeiten. Sie sind wissenschaftlich bewiesen und treiben die Software-Delivery-Performance. Nutze die DORA-Metriken. Lead Time for Changes, Deployment Frequency, Time to Restore Service und Change Failure Rate sind die einzigen wissenschaftlich validen KPIs. Unterscheide Deployment von Release. Deployment bringt Code mit ausgeschaltetem Feature Toggle in die Produktion. Release schaltet ihn ein. Balance zwischen Geschwindigkeit und Stabilität. Messe immer beide Dimensionen für ein genaues Bild. Die Beweislage ist überwältigend. Elite-DevOps-Organisationen übertreffen Low-Performer um Grössenordnungen bei allen Metriken. ","date":"3. December 2023","externalUrl":null,"permalink":"/de/blogs/die-wissenschaft-hinter-devops/","section":"Blogs","summary":"In diesem Video tauche ich tief in die Wissenschaft hinter DevOps ein. Insbesondere schaue ich mir die DORA-Metriken an, woher sie kommen und welches Buch die wissenschaftliche Grundlage für alles liefert, was wir über leistungsstarke Software-Delivery-Organisationen wissen: Accelerate.\n","title":"Die Wissenschaft hinter DevOps","type":"blogs"},{"content":"","date":"3 December 2023","externalUrl":null,"permalink":"/en/tags/dora-metrics/","section":"Tags","summary":"","title":"DORA Metrics","type":"tags"},{"content":"","date":"3. December 2023","externalUrl":null,"permalink":"/de/tags/dora-metriken/","section":"Tags","summary":"","title":"DORA-Metriken","type":"tags"},{"content":"In this video, I take a deep dive into the science behind DevOps. Specifically, I look at the DORA metrics, where they come from, and the book Accelerate that provides the scientific foundation for everything we know about high-performing software delivery organizations.\nThe Book Accelerate # The book Accelerate: The Science of Lean Software and DevOps was published in 2018 and has 288 pages. I highly recommend it to everyone working on DevOps or on a DevOps transformation. It is the essential book to read.\nThe book was written by three remarkable authors. Dr. Nicole Forsgren did the research and created the startup DORA (DevOps Research and Assessment). Jez Humble is well known for his books Continuous Delivery and The DevOps Handbook. Gene Kim is known for The Phoenix Project, The Unicorn Project, and is co-author of The DevOps Handbook. He also created the DevOps Enterprise Summit. These three books, Accelerate, The DevOps Handbook, and The Phoenix Project, are the essential reading list for anyone in the DevOps space.\nThe book has three parts. Part one describes the findings: the 24 key capabilities they discovered through their research. Part two covers the science, including all the statistical analysis techniques they used. Part three is a case study from ING about their DevOps transformation, serving as a blueprint. If you have limited time, at least read part one.\nThe 24 Key Capabilities # The most amazing thing about Accelerate is that they scientifically analyzed companies doing DevOps and found 24 key capabilities that drive improvements in software delivery performance. These are organized into five categories:\nContinuous Delivery Capabilities: Version control, deployment automation, continuous integration, trunk-based development, test automation, test data management, shift-left security, and continuous delivery.\nArchitecture Capabilities: Loosely coupled architecture and empowering teams to make their own decisions.\nProduct and Process Capabilities: Customer feedback, organizing across the value stream, working in small batches, and allowing teams to experiment.\nLean Management and Monitoring Capabilities: Change approval boards are ineffective (science has confirmed this). You should have monitoring systems, proactive notifications, limit work in process, and visualize work across the value stream.\nCultural Capabilities: Westrum organizational culture (generative over bureaucratic or pathological), supported learning, collaboration across teams, job satisfaction, and transformational leadership.\n\u0026ldquo;Science has found out that change approval boards are for nothing. Many of the processes are redundant because you have already automated them with your pipeline.\u0026rdquo;\nWhat makes this research extraordinary is not just the capabilities themselves, but the relationships between them. The book provides a picture showing how these capabilities influence each other. On the right side is what you want to achieve. On the left side is what you need to do to achieve that. For me, this is the reference picture for any DevOps transformation.\nThe DORA Metrics # How do you measure software delivery performance? It is not team velocity. It is not lines of code. It is not the number of commits or test coverage. The scientifically proven metrics are the DORA metrics:\nLead Time for Changes: How long from code commit until production. Note that the time before code commit (ideation, requirements, implementation) is not included because it is statistically not significant. Elite performers do this in less than an hour. High is one day to one week. Medium is one month to six months. Low is more than six months.\nDeployment Frequency: How often you deploy to production. Remember: deployment is bringing code into production with the feature toggle off. Release is switching the toggle on. Elite organizations deploy on demand, multiple times per day. High is once per day to once per week.\nTime to Restore Service: How long to recover from an incident. Elite teams restore within an hour. This metric is closely related to lead time and deployment frequency.\nChange Failure Rate: The percentage of deployments causing a failure. Elite is 0 to 15%. High and medium are 16 to 30%. Low is 31 to 45%.\nImportant: always consider at least two metrics, one from speed (lead time, deployment frequency) and one from stability (time to restore, change failure rate). Optimizing only for speed or only for stability gives a distorted picture.\nThe Numbers Speak for Themselves # The State of DevOps reports compare elite performers with low performers. The 2019 report shows that elite companies have:\n208x more frequent deployments 106x faster lead time 2604x faster time to restore service 7x lower change failure rate By 2021, these numbers had grown even larger. The market is accelerating. Elite organizations are getting faster, and the gap between elite and low performers continues to widen.\nThe benefits are clear: faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees. This is exactly what CIOs want.\nThe Shift Over Time # Looking at the state of DevOps data over time, in 2018 there were only a few elite companies, many high performers, some medium, and a large portion of low performers. Over the years, more companies moved to elite and high levels. The low performers either improved or went out of business.\nKey Takeaways # Read Accelerate. It is the essential book for anyone working in DevOps. At minimum, read part one. Focus on the 24 key capabilities. They are scientifically proven to drive software delivery performance. Use the DORA metrics. Lead time for changes, deployment frequency, time to restore service, and change failure rate are the only scientifically valid KPIs. Distinguish deployment from release. Deployment brings code to production with the feature toggle off. Release switches it on. Balance speed and stability. Always measure both dimensions to get an accurate picture. The evidence is overwhelming. Elite DevOps organizations outperform low performers by orders of magnitude across all metrics. ","date":"3 December 2023","externalUrl":null,"permalink":"/en/blogs/the-science-of-devops/","section":"Blogs","summary":"In this video, I take a deep dive into the science behind DevOps. Specifically, I look at the DORA metrics, where they come from, and the book Accelerate that provides the scientific foundation for everything we know about high-performing software delivery organizations.\n","title":"The Science of DevOps","type":"blogs"},{"content":"As Chief of DevOps and Partner at Zühlke, I have spent over two decades helping companies continuously deliver value. In this video, I walk through the complete Zühlke DevOps offering, from our understanding of DevOps and the challenges of scaling it, to our concrete service offerings including the Digital Factory and the Platform Plane.\nThe Problem: Broken Value Streams # When I visit companies, I frequently encounter the same picture. Business creates great plans in Jira tickets and Word documents, then throws them over a wall of confusion to development. Development implements something and throws it over another wall to testing. Testing checks it and throws it to operations. Operations struggles to get it running, and the customer says: \u0026ldquo;This is not what we wanted.\u0026rdquo;\nThe root cause is the silo organization. Business, development, testing, and operations all work in separate silos with different goals and no real alignment. The value stream, visualized as that blue infinity symbol, is interrupted by walls of confusion. There is also a lack of software engineering excellence across this value stream.\nDevOps is the solution. It is a mindset, a culture, and a set of technical practices that allows us to organize across the value stream so that all people work together to continuously deliver value to the customer.\nDevOps is all about bringing all the people, process, and technology together to continuously deliver value. This is what DevOps is.\nThe Challenge of Scaling DevOps # The numbers speak for themselves. The State of DevOps reports show that high performers achieve 973 times more deployments than low performers. DevOps delivers faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees. Every CIO wants exactly that.\nBut doing DevOps in one team is already challenging. Doing DevOps at scale is even harder. Some companies try to solve it by creating a \u0026ldquo;DevOps team\u0026rdquo; between development and operations, which just introduces another silo. The real solution is product teams with all people together. But that introduces inconsistencies, redundancies, and a massive cognitive load.\nThe tooling alone is overwhelming. The Continuous Delivery Pipeline does not start and end with CI/CD. It includes continuous exploration (requirements engineering, backlog management), continuous integration, continuous deployment, and release on demand with feature toggles. Each of these areas requires specialized tools that need to be maintained and integrated. On top of that, teams must master all the technical practices of modern software development, handle onboarding of new people (which can take days or weeks for access provisioning), and ensure both quality and security.\nThe Digital Factory: The Target Picture # What every company needs is a Digital Factory. At the top level, a board of directors has a vision and strategy. A Portfolio Kanban holds all the big ideas as Epics. The board prioritizes and selects the most promising Epics. Product management breaks Epics into features. Product teams work in an agile way, breaking features into user stories that flow through the Continuous Delivery Pipeline.\nThe Platform Engineering team provides standardized pipelines for new teams so they can be productive immediately. The whole system delivers value to the customer, gets feedback back, and continuously learns. These are the three ways of DevOps.\nThe Digital Factory has four layers:\nLean Portfolio Management connecting strategy with execution Product Management organizing teams working on products Product Teams doing DevOps, building, running, and owning their products Platform Team developing, building, and maintaining the platform The Platform Team provides standardized tools so product teams can work efficiently. The platform covers application runtime and compute, DevSecOps (automated security shifting left), access and identity (morning onboarding, evening offboarding), centralized security, observability and monitoring, and everything teams need to focus on feature development instead of infrastructure.\nThe Zühlke DevOps Offering # Zühlke is a global service provider with over 2,000 people across 17 offices in ten countries. Founded in 1968, it is still in the hands of partners. The capabilities span Digital Consulting, AI and Data, Cloud, Cybersecurity, Digital Experience, Software Excellence, Hardware and Electronic Development, and DevOps.\nOur DevOps offering has six pillars:\n1. DevOps Engineering and Consulting: Everything from value stream engineering to continuous delivery and release orchestration, helping you move from projects to products with state of the art product delivery.\n2. Quality and Continuous Testing: You cannot scale when your quality is bad. Shift left, build quality in from the beginning, invest in test automation and continuous testing.\n3. Digital Factory: A lean transformation approach for multiple teams, whole organizations, or the entire enterprise. It transforms your organization into a Digital Factory where you continuously deliver value, reduce lead times, improve quality, and increase customer satisfaction and employee happiness. It is completely tailor-made, based on blueprints and building blocks.\n4. Platform Engineering: Implementing an internal developer platform with all observability, metrics, and Kubernetes as a service. This is the foundation of the Digital Factory.\n5. Application Modernization: For companies with legacy applications and landscapes. We do software evaluation, enterprise architecture, and transformation of single applications or complete landscapes.\n6. Turnaround: When a project or product is in trouble, we help get it back on track, making it more reliable, resilient, and increasing its release ability.\nThe Platform Plane # The Platform Plane is an accelerator asset built at Zühlke. It links best of breed tools into an outstanding user experience. It is much more than just a developer portal.\nThe Platform Plane includes:\nApplication Runtime and Compute: Kubernetes as a service, API Gateway, service catalog, and managed ingress Developer Experience: Portal, CLI, application templates, networking, and tunneling DevSecOps: Automated software composition analysis, secret detection, SAST, and license scanning Access and Identity: Self-onboarding for teams with immediate access to all connected tools Centralized Security: Firewall support, WAF support, and network topologies out of the box Observability: Open Telemetry stack, managed dashboards, and FinOps KPIs GitOps: CI/CD pipelines, secret management, and ready-made pipeline templates The architecture integrates tools through adapters. Tools are not welded together into a big ball of mud. Each tool is integrated through an adapter and a unified integration block, then connected through an automation and provisioning layer. This allows new tools to be added easily and existing tools to be replaced when they become obsolete.\nWe are entering the Age of Industrialization of Software Development. Platform Engineering builds the platform, which is the foundation of your Digital Factory and enables teams to do DevOps.\nWhat a Holistic Digital Factory Requires # Building a Digital Factory requires a holistic approach:\nScalable Architecture with good APIs for product development DevOps and Software Engineering practices across the value stream A Platform as the foundation for product development Data and Analytics so management and teams can make the right decisions Customer Centricity with great end-to-end customer experience Agile Product Delivery with backlog management, dependency management, and team management Product Management with lean portfolio management connecting strategy to execution Key Takeaways # Broken value streams from silo organizations are the root cause of slow, low-quality software delivery DevOps at scale requires a Digital Factory approach with Lean Portfolio Management, Product Management, Product Teams, and a Platform Team The Platform Team provides a standardized platform so product teams can focus on delivering features Zühlke offers six DevOps services: Engineering and Consulting, Quality, Digital Factory, Platform Engineering, Application Modernization, and Turnaround The Platform Plane integrates best of breed tools through adapters, ensuring tools can be swapped without disrupting the platform The Digital Factory is a holistic lean transformation approach covering architecture, DevOps, platform, data, customer experience, and agile delivery ","date":"3 December 2023","externalUrl":null,"permalink":"/en/blogs/the-zuehlke-devops-offering/","section":"Blogs","summary":"As Chief of DevOps and Partner at Zühlke, I have spent over two decades helping companies continuously deliver value. In this video, I walk through the complete Zühlke DevOps offering, from our understanding of DevOps and the challenges of scaling it, to our concrete service offerings including the Digital Factory and the Platform Plane.\n","title":"The Zühlke DevOps Offering: From DevOps Engineering to the Digital Factory","type":"blogs"},{"content":"","date":"26 October 2023","externalUrl":null,"permalink":"/en/tags/operational-excellence/","section":"Tags","summary":"","title":"Operational Excellence","type":"tags"},{"content":"","date":"26. October 2023","externalUrl":null,"permalink":"/de/tags/operative-exzellenz/","section":"Tags","summary":"","title":"Operative Exzellenz","type":"tags"},{"content":"","date":"26 October 2023","externalUrl":null,"permalink":"/en/tags/production-systems/","section":"Tags","summary":"","title":"Production Systems","type":"tags"},{"content":"","date":"26. October 2023","externalUrl":null,"permalink":"/de/tags/produktionssysteme/","section":"Tags","summary":"","title":"Produktionssysteme","type":"tags"},{"content":"","date":"26. October 2023","externalUrl":null,"permalink":"/de/tags/standardisierung/","section":"Tags","summary":"","title":"Standardisierung","type":"tags"},{"content":"","date":"26 October 2023","externalUrl":null,"permalink":"/en/tags/standardization/","section":"Tags","summary":"","title":"Standardization","type":"tags"},{"content":"","date":"26 October 2023","externalUrl":null,"permalink":"/en/tags/value-creation/","section":"Tags","summary":"","title":"Value Creation","type":"tags"},{"content":" Ein Gespräch mit Romano Roth, DevOps Thought Leader, und Dr. Milan Milanović, Architecture Thought Leader. Quelle: https://newsletter.techworld-with-milan.com/p/what-are-digital-factories\n1. Romanos Kurzbiografie # Ich bin Romano Roth, Chief of DevOps und Partner bei Zühlke. Meine Reise mit Zühlke begann vor 21 Jahren. Im Laufe der Jahre habe ich mich vom Software Engineer und Softwarearchitekten zum Berater entwickelt. Während dieser gesamten Reise hat mich eine Frage immer angetrieben: Wie können wir kontinuierlich Wert liefern und gleichzeitig Qualität und Automatisierung sicherstellen?\nAls die DevOps-Bewegung an Fahrt gewann, war ich sofort begeistert. Heute bin ich einer der Organisatoren des monatlichen DevOps Meetup in Zürich und Präsident der DevOps Days Zürich, einer jährlichen Konferenz als Teil der globalen DevOps-Bewegung. DevOps ist nicht nur ein berufliches Interesse, sondern meine Leidenschaft. Deshalb habe ich meinen eigenen YouTube-Kanal, auf dem ich über 100 Videos zu DevOps, Architektur und Führung kuratiert habe.\n2. Was bedeutet DevOps für dich? # DevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken. Es sorgt für Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Personen, die nötig sind, um ein Produkt zu planen, zu entwickeln, zu testen, bereitzustellen, auszuliefern und zu warten.\nKurz gesagt: Menschen, Prozesse und Technologie zusammenbringen, um kontinuierlich Wert zu liefern!\n3. Was sind die größten Herausforderungen bei DevOps? # Es gibt mehrere Herausforderungen:\nKultureller Widerstand: Eine der größten Herausforderungen ist der Wandel der Organisationskultur. DevOps erfordert den Übergang von traditionellen Silorollen zu einem kollaborativen Ansatz mit geteilter Verantwortung. Dies kann auf Widerstand von Teams stoßen, die an die Arbeit in Siloorganisationen gewöhnt sind.\nKognitive Belastung: Es gibt zahlreiche technische Praktiken und Tools für die verschiedenen Phasen des DevOps-Lebenszyklus, von der Ideenfindung über Continuous Integration und Continuous Deployment bis hin zu Release on Demand. All diese technischen Praktiken und Tools zu integrieren und zu pflegen, um großartige Produkte zu entwickeln, kann herausfordernd sein.\nDevOps skalieren: Was für ein kleines Team oder ein einzelnes Projekt funktioniert, funktioniert möglicherweise nicht für eine gesamte Organisation. DevOps-Praktiken zu skalieren und dabei Geschwindigkeit und Zuverlässigkeit beizubehalten, ist eine erhebliche Herausforderung.\n4. Ist Continuous Deployment ein wesentlicher Teil des DevOps-Prozesses? # Continuous Deployment ist ein bedeutender Aspekt von DevOps, aber ob es «wesentlich» ist, hängt von den Zielen und der Reife der Organisation ab. In der DevOps-Philosophie liegt der Schwerpunkt auf der Automatisierung und Rationalisierung des Softwarelieferprozesses. Continuous Deployment unterstützt dies, indem jede Änderung, die die Pipeline durchläuft, automatisch in die Produktion überführt wird.\nEinige Organisationen entscheiden sich jedoch für Continuous Delivery, bei dem Änderungen automatisch für ein Release in der Staging-Umgebung vorbereitet werden, aber eine manuelle Freigabe für das Deployment erfordern. Die Wahl hängt oft von den geschäftlichen Anforderungen, der Risikobereitschaft und der Kritikalität der Anwendung ab. Im Wesentlichen gilt: Obwohl Continuous Deployment die Ideale von DevOps verkörpert, ist es nicht für alle Organisationen zwingend, diese DevOps-Praxis einzuführen.\n5. Wie können wir DevOps skalieren? # Die Skalierung von DevOps, insbesondere in größeren Organisationen, erfordert einen strategischen Ansatz, der über Tools und Technologien hinausgeht. Hier sind einige Überlegungen zur effektiven Skalierung von DevOps:\nKulturelle Transformation: Eine kollaborative Umgebung fördern, die das Lernen aus Fehlern wertschätzt. Standardisierung: Einheitliche Tools und Prozesse über Teams hinweg einführen, um Konsistenz zu gewährleisten. Automatisierung: Abläufe rationalisieren durch Automatisierung von Aufgaben, von der Ideenfindung über Continuous Integration und Continuous Deployment bis hin zu Release on Demand. Modulare Architektur: Architekturstile wie Microservices nutzen, um Abhängigkeiten zu reduzieren. Metriken: Kennzahlen verwenden, um die Leistung zu messen, Engpässe zu identifizieren und kontinuierliche Verbesserung voranzutreiben. Kontinuierliche Weiterbildung: In die fortlaufende Kompetenzentwicklung investieren, damit Teammitglieder die nötigen Fähigkeiten für die Arbeit in einer DevOps-Umgebung haben. Feedback-Schleifen: Effiziente Kanäle für Feedback einrichten, um Probleme schnell zu identifizieren und zu beheben. Dezentrale Entscheidungsfindung: Teams befähigen, Entscheidungen lokal zu treffen, um den Bedarf an Top-down-Genehmigungen zu reduzieren und den Entwicklungsprozess zu beschleunigen. Pilotprogramme: DevOps-Praktiken in spezifischen Pilotprojekten testen und verfeinern. Kollaborationsplattformen: Tools nutzen, die die Teamkommunikation verbessern, wie GitLab, GitHub und Azure DevOps. Regelmäßige Reviews: DevOps-Praktiken kontinuierlich bewerten und anpassen, wenn die Organisation wächst und sich verändert. 6. Ist Platform Engineering dasselbe wie DevOps? # Platform Engineering und DevOps sind nicht dasselbe, aber sie sind eng verwandt und überschneiden sich in vielen Organisationen.\nDevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken. Es sorgt für Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Personen, die nötig sind, um ein Produkt zu planen, zu entwickeln, zu testen, bereitzustellen, auszuliefern und zu warten und kontinuierlich Wert an den Kunden zu liefern.\nPlatform Engineering ist das Entwerfen und Bauen von Toolchains und Workflows, die Self-Service-Fähigkeiten für Produktteams ermöglichen, die kontinuierlich Wert an den Kunden liefern.\nPlatform Engineering nutzt DevOps-Praktiken, was es Produktteams ermöglicht, DevOps zu betreiben.\n7. Was ist eine Digitale Fabrik? # Durch meine Arbeit an verschiedenen Projekten in unterschiedlichen Branchen und bei verschiedenen Kunden habe ich beobachtet, dass viele Unternehmen gemeinsame Herausforderungen und Ziele haben. Ich denke, sie alle wollen großartige Produkte bauen, eine schnellere Markteinführung erreichen und effizienter sein. Und was sie aufbauen wollen, ist eine Digitale Fabrik.\nAn der Spitze eines Unternehmens stehen der Verwaltungsrat und die Geschäftsleitung. Sie prägen die Vision, Mission und Strategie des Unternehmens. Alle großen Ideen werden in einem Portfolio Kanban priorisiert. Der Verwaltungsrat priorisiert diese Ideen und gibt dem Produktmanagement die wichtigsten und vielversprechendsten Ideen. Zum Beispiel: Der Bau von Drohnen, die schwere Lasten tragen können, erhöht den Marktanteil. Das Produktmanagement nimmt diese Idee und definiert, welche Features für eine solche Drohne benötigt werden. Eine solche Drohne benötigt beispielsweise modifizierte Software, größere Batterien und bessere Motoren. Diese Features werden an die Teams weitergegeben. Die bestehenden Teams beginnen an diesen Features zu arbeiten. Für den neuen Motor muss ein neues Team aufgebaut werden. Dafür stellt das Platform Engineering Team eine standardisierte Continuous-Delivery-Umgebung bereit, damit dieses Team sofort loslegen kann. Alle Teile werden zusammengefügt, und die Drohnen können nun kontinuierlich an die Kunden ausgeliefert werden.\nDie Teams überwachen die Drohnen ständig. Telemetrie- und Geschäftsdaten werden gesammelt, wie zum Beispiel wie viele Drohnen verkauft wurden und wie hoch die Kundenzufriedenheit ist. Diese Kennzahlen fließen zurück auf die Portfolio-Ebene, wo diese Informationen die zukünftigen Entscheidungen des Verwaltungsrats beeinflussen.\nDamit konzentriert sich das Unternehmen effizient auf die wichtigsten und strategischsten Aufgaben und kann sich schnell an neue Marktbedürfnisse anpassen.\n8. Wie können wir eine Digitale Fabrik implementieren? # Um eine Digitale Fabrik aufzubauen, braucht man einen ganzheitlichen Ansatz.\nArchitektur: Architekturen entwerfen, die zur Technologiestrategie passen und Anpassungsfähigkeit, Skalierbarkeit und Flexibilität gewährleisten.\nDevOps: Platform Engineering nutzen, um Toolchains und Workflows zu entwerfen und aufzubauen, die Self-Service-Fähigkeiten für Produktteams ermöglichen, damit diese Qualität liefern und DevOps betreiben können.\nDaten: Datenpipelines optimieren für zeitnahe, handlungsorientierte Erkenntnisse. Data Science einsetzen, um Wert zu generieren und die Entscheidungsfindung zu unterstützen.\nKundenerlebnis: Nutzerfeedback ins Zentrum der Produktentwicklung stellen. Ein nahtloses End-to-End-Erlebnis anstreben.\nAgile Programmlieferung: Eine Multi-Team-Organisation einführen, um Workflows und Leistung zu optimieren. Kontinuierliche Entdeckung, verbunden mit transparentem Reporting, treibt das Wachstum voran.\nProduktmanagement für maximalen Wert: Die Strategie mit der Umsetzung verbinden. Produktinitiativen an den Unternehmenszielen ausrichten. Management-Praktiken kontinuierlich verfeinern und Feedback für die Priorisierung nutzen.\n9. Was ist mit den Menschen? Welche Herausforderungen gibt es bei der Arbeit mit Kunden und Entwicklern? # Im digitalen Zeitalter stehen Unternehmen vor vielen Herausforderungen, insbesondere diejenigen, die noch nach traditionellen Wasserfall-Softwarelieferprozessen arbeiten. Hier sind meiner Meinung nach die wichtigsten:\nKulturelle Hürden: Eine zentrale Herausforderung liegt in der Transformation der Organisationskultur. DevOps erfordert den Übergang von Silorollen zu einem einheitlichen, kollaborativen Modell mit geteilter Verantwortung. Ein solcher Wandel kann auf Widerstand von Teams stoßen, die an Siloorganisationen gewöhnt sind.\nKognitive Belastung der Teams: Die Flut neuer Informationen, Wissen, Prozesse und Tools kann Teams überfordern, ihre mentale Kapazität strapazieren und die Produktivität beeinträchtigen. Die Steuerung dieser kognitiven Belastung ist entscheidend, damit Teams sich effektiv anpassen und optimale Leistung aufrechterhalten können.\nVertrauen und psychologische Sicherheit: Vertrauen innerhalb von Teams aufzubauen, insbesondere zum und vom Management, ist entscheidend für offene Kommunikation und Lernen. Ohne das werden Organisationen sich nicht verändern und wachsen.\nWenn Sie mehr über Digitale Fabriken erfahren möchten, schauen Sie sich Romanos Präsentation von der Conf42 Platform Engineering 2023 an:\nBonus: DevOps Roadmap 2023 # Schauen Sie sich die DevOps 2023 Roadmap an, die Milan und ich erstellt haben.\nDie vollständige Roadmap mit Lernressourcen finden Sie im Repository.\n","date":"26. October 2023","externalUrl":null,"permalink":"/de/blogs/was-sind-digitale-fabriken/","section":"Blogs","summary":" Ein Gespräch mit Romano Roth, DevOps Thought Leader, und Dr. Milan Milanović, Architecture Thought Leader. Quelle: https://newsletter.techworld-with-milan.com/p/what-are-digital-factories\n1. Romanos Kurzbiografie # Ich bin Romano Roth, Chief of DevOps und Partner bei Zühlke. Meine Reise mit Zühlke begann vor 21 Jahren. Im Laufe der Jahre habe ich mich vom Software Engineer und Softwarearchitekten zum Berater entwickelt. Während dieser gesamten Reise hat mich eine Frage immer angetrieben: Wie können wir kontinuierlich Wert liefern und gleichzeitig Qualität und Automatisierung sicherstellen?\n","title":"Was sind Digitale Fabriken?","type":"blogs"},{"content":"","date":"26. October 2023","externalUrl":null,"permalink":"/de/tags/wertsch%C3%B6pfung/","section":"Tags","summary":"","title":"Wertschöpfung","type":"tags"},{"content":" a talk with Romano Roth, DevOps Thought Leader and Dr. Milan Milanović Architecture Thought Leader. Source: https://newsletter.techworld-with-milan.com/p/what-are-digital-factories\n1. Romano’s short biography # I\u0026rsquo;m Romano Roth, Chief of DevOps and Partner at Zühlke. My journey with Zuhlke began 21 years ago. Over the years, I\u0026rsquo;ve evolved from an expert software engineer and software architect to a consultant. Throughout this journey, one question has always fueled my passion: How can we continuously deliver value while ensuring quality and automation?\nWhen the DevOps movement began to gain momentum, I was naturally drawn to it. Today, I\u0026rsquo;m one of the organizers of the monthly DevOps Meetup in Zürich and president of DevOps Days Zürich, an annual conference part of the global DevOps movement. DevOps isn\u0026rsquo;t just a professional interest; it\u0026rsquo;s my passion. That\u0026rsquo;s why I\u0026rsquo;ve my own YouTube channel, where I\u0026rsquo;ve curated over 100 videos centered on DevOps, architecture, and leadership.\n2. What is DevOps for you? # DevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a product.\nIn short: Bringing People, Process, and Technology together to continuously deliver value!\n3. What are the significant challenges with DevOps? # There are multiple challenges:\nCultural Resistance: One of the biggest challenges is changing the organizational culture. DevOps requires shifting from traditional siloed roles to a collaborative approach with shared responsibility. This can be met with resistance from teams used to working in siloed organizations.\nCognitive Load: Numerous technical practices and tools exist for various stages of the DevOps lifecycle, from ideation over continuous integration over continuous deployment to release on demand. Integrating and maintaining all these technical practices and tools to develop great products can be challenging.\nScaling DevOps: What works for a small team or a single project might not work for an entire organization. Scaling DevOps practices while maintaining speed and reliability is a significant challenge.\n4. Is Continuous deployment an essential part of the DevOps process? # Continuous deployment is a significant aspect of DevOps, but whether it\u0026rsquo;s \u0026ldquo;essential\u0026rdquo; depends on the organization\u0026rsquo;s goals and maturity. In the DevOps philosophy, the emphasis is on automating and streamlining the software delivery process, and continuous deployment facilitates this by automatically deploying every change that passes through the pipeline into production.\nHowever, some organizations might opt for continuous delivery, where changes are automatically prepared for a release in the staging environment but require manual approval for deployment. The choice often depends on the business requirements, risk tolerance, and the criticality of the application. In essence, while continuous deployment exemplifies the ideals of DevOps, it\u0026rsquo;s not mandatory for all organizations to adopt this DevOps practice.\n5. How can we scale DevOps? # Scaling DevOps, especially in larger organizations, requires a strategic approach beyond tools and technologies. Here are some considerations to scale DevOps effectively:\nCultural Transformation: Foster a collaborative environment that values learning from failures. Standardization: Adopt consistent tools and processes across teams to maintain uniformity. Automation: Streamline operations by automating tasks from ideation over continuous integration over continuous deployment to release on demand. Modular Architecture: Utilize architecture styles like microservices to reduce interdependencies. Metrics: Use metrics to measure performance, identify bottlenecks, and drive continuous improvement. Continuous Training: Invest in ongoing skill development to ensure team members have the necessary skills to work in a DevOps environment. Feedback Loops: Establish efficient channels for feedback to identify and address issues quickly. Decentralized Decision-making: Empower teams to make decisions locally, reducing the need for top-down approvals and speeding up the development process. Pilot Programs: Test and refine DevOps practices through specific pilot projects. Collaboration Platforms: Use tools that enhance team communication like GitLab, GitHub, and Azure DevOps…. Regular Reviews: Continuously assess and adjust DevOps practices as the organization grows and changes. 6. Is Platform Engineering the same as DevOps? # Platform Engineering and DevOps are not the same, but they are closely related and often overlap in many organizations.\nDevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a product and deliver continuous value to the customer.\nPlatform engineering is designing and building toolchains and workflows that enable self-service capabilities for product teams that deliver continuous value to the customer.\nPlatform engineering uses DevOps practices, which enables product teams to do DevOps.\n7. What is a Digital Factory? # Throughout my work on various projects across diverse industries and clients, I\u0026rsquo;ve observed that many companies share common challenges and objectives. I think they all want to build great products, have a faster time to market, and be more efficient. And what they want is to build up a digital factory.\nAt the top of a company, you find the board of directors and the executive board. They shape the company\u0026rsquo;s vision, mission, and strategy. All big ideas are prioritized in a portfolio kanban. The board prioritizes these ideas and gives product management the most important and promising ideas. For example, building drones carrying heavy weight increases the market share. The product management takes that idea and defines what features are needed for such a drone. Such a drone, for example, needs to have modified software, bigger batteries, and better engines. They give these features down to the teams. The existing teams have started to work on those features. For the new engine, a new team needs to be established. For that, the platform engineering team will provide a standardized continuous delivery environment so that that team can start right away. All the parts get assembled, and the drones can now be continuously delivered to the customers.\nThe teams constantly monitor the drones. Telemetry and business data are collected, like how many drones we have sold and customer satisfaction. These metrics are fed back to the portfolio level, where this information informs the board\u0026rsquo;s future decisions.\nWith that, the company focuses efficiently on the most critical and strategic tasks and can quickly adapt to new market needs.\n8. How can we implement Digital Factory? # To build a digital factory, you need a holistic approach.\nArchitecture: Design architectures that align with your technology strategy, ensuring adaptability, scalability, and flexibility.\nDevOps: Utilize Platform Engineering to design and build toolchains and workflows that enable self-service capabilities for product teams to enable them to make quality and do DevOps.\nData: Streamline data pipelines for timely, actionable insights. Harness data science to extract value to inform decision-making.\nCustomer experience: Place user feedback at the heart of product development. Aim for a seamless end-to-end experience.\nAgile Programme Delivery: Adopt a multi-team organization to optimize workflows and performance. Continuous discovery, coupled with transparent reporting, drives growth.\nProduct Management for Maximized Value: Connect the strategy with the execution. Align product initiatives with the company goals. Continuously refine management practices and leverage feedback for prioritization.\n9. What about people? What are the challenges in working with clients and developers? # In the digital age, companies face many challenges, especially those still operating under traditional waterfall-style software delivery processes. Here are, in my opinion, the most important ones:\nCultural Hurdles: A primary challenge lies in transforming the organizational culture. DevOps demands a transition from siloed roles to a unified, collaborative model with shared responsibility. Such a shift can face opposition from teams accustomed to siloed organizations.\nCognitive Load on Teams: The flood of new information, knowledge, processes, and tools can overwhelm teams, stretching their mental capacity and affecting productivity. Managing this cognitive load is crucial to ensure units can effectively adapt and maintain optimal performance.\nTrust and Psychological Safety: Building trust within teams, especially to and from management, is pivotal for open communication and learning. Without that, organizations will not change and grow.\nIf you want to learn more about Digital Factories, you can check Romano\u0026rsquo;s presentation from the Conf42 Platform Engineering 2023:\nBonus: DevOps Roadmap 2023. # Check the DevOps 2023 Roadmap, which I and Milan created.\nSee the full roadmap, with learning resources in the repo.\n","date":"26 October 2023","externalUrl":null,"permalink":"/en/blogs/what-are-digital-factories/","section":"Blogs","summary":" a talk with Romano Roth, DevOps Thought Leader and Dr. Milan Milanović Architecture Thought Leader. Source: https://newsletter.techworld-with-milan.com/p/what-are-digital-factories\n1. Romano’s short biography # I’m Romano Roth, Chief of DevOps and Partner at Zühlke. My journey with Zuhlke began 21 years ago. Over the years, I’ve evolved from an expert software engineer and software architect to a consultant. Throughout this journey, one question has always fueled my passion: How can we continuously deliver value while ensuring quality and automation?\n","title":"What are Digital Factories ?","type":"blogs"},{"content":"","date":"23 September 2023","externalUrl":null,"permalink":"/en/tags/change-management/","section":"Tags","summary":"","title":"Change Management","type":"tags"},{"content":"","date":"23 September 2023","externalUrl":null,"permalink":"/en/tags/communication/","section":"Tags","summary":"","title":"Communication","type":"tags"},{"content":"","date":"23. September 2023","externalUrl":null,"permalink":"/de/tags/kommunikation/","section":"Tags","summary":"","title":"Kommunikation","type":"tags"},{"content":"In this podcast episode, I have a conversation with Peyton Einhaus about one of the most challenging aspects of any transformation: dealing with resistance. Whether you are running an agile transformation, a DevOps transformation, or any organizational change, resistance is always present. The question is how you handle it effectively.\nResistance from Managers vs. Team Members # One of the first questions Peyton asked was whether you need to address resistance differently depending on who it comes from. The answer is absolutely yes.\nWhen dealing with management, the resistance usually comes from concerns about budgeting, strategic alignment, or the potential negative impact on their department. With managers, you need to present facts, figures, and data. You need to argue on the data level.\nWith team members, the resistance is different. It comes from concerns about workload, skill set, or how the change affects their day-to-day work. There you need much more empathy, clear communication, and you need to show them what the benefits are. The key question for team members is always: \u0026ldquo;What is in it for me?\u0026rdquo;\nIdentifying the Root Cause # Being transparent and having open communication alone does not eliminate resistance. You need to invest significant time in identifying the actual cause. If someone is afraid of losing their job, that requires a completely different approach than someone who fears losing control or simply lacks understanding.\nOne method I use is a trade-off analysis. I show the options: stay where you are, join the journey of change, or move to a different department or company. Then we go through criteria together and evaluate what the best option is for that person. It sounds straightforward, but having this structured conversation can be very powerful.\nAdapting Your Communication Style # There is a framework where you categorize people with colors. Red people are tough and direct. Blue people are very analytical and need numbers, data, and facts. Yellow people are more emotional. Most people are a combination.\nWhen you know you will face resistance, preparation is essential. I learned this the hard way. Going into a meeting unprepared when you know resistance is coming can be dangerous. You need to have your arguments ready, research the people you are meeting, understand their personality type, and then adapt your tone accordingly.\n\u0026ldquo;Always prepare for a meeting. Especially when you know you will face resistance, have your arguments ready and understand the people you are talking to.\u0026rdquo;\nPeyton added an excellent point about the Rose of Leary framework. When facing a dominant person, you should first please their ego before gently asking for help. With analytical people, provide examples and metrics. With emotional people, address their feelings first and show empathy before making your request.\nThe Four Essential Skills # For anyone working in agile coaching, scrum mastering, or DevOps consulting, there are four skills essential for dealing with resistance:\nActive listening: This is the most important communication skill. In my early career, I talked too much and did not listen enough. You need to truly hear and understand the other person\u0026rsquo;s perspective, emotions, and challenges.\nNegotiation and persuasion: This is a tough skill. Hard negotiations are difficult, and I openly admit it is not my strongest area. But it is critical for transformation work.\nEmotional intelligence: You need to control your own emotions. When someone gets very emotional because they fear losing their job, you must keep your composure and respond constructively.\nProblem solving: You need to flexibly adapt to new challenges, understand different viewpoints, and find good solutions for difficult situations.\nTraining Emotional Intelligence # Emotional intelligence is one of the hardest skills to train. Unlike active listening or negotiation, which you can learn through practice, emotional intelligence feels more like a trait than a skill.\nTwo things have helped me the most. First, meditation. I meditate daily or at least weekly. It calms me down and, importantly, helps me control my breathing. Controlled breathing calms your emotions, and meditation is an excellent technique to train that.\nSecond, sleep. Sleep eight hours every night. When you sleep less, you have a very thin skin, as we say. You become emotional because you are tired and exhausted. Proper sleep is the foundation for emotional regulation.\n\u0026ldquo;Sleep eight hours every night. When you sleep less, you have very thin skin and get emotional easily because you are tired and exhausted.\u0026rdquo;\nThe Top Five Causes of Resistance # From my experience, these are the top five causes of resistance in transformations:\nFear of change: People have their comfort zone and are happy where they are. Every change means stepping out of that zone.\nLack of understanding: Not understanding what the change is about or why it is needed. As leaders, we must communicate the \u0026ldquo;why\u0026rdquo; clearly.\nFear of losing the job: People worry they are not good enough for the new setting or that their role will disappear.\nNegative past experience: Many people have been through multiple changes that were only half-completed or failed entirely. They simply do not believe in change anymore.\nLack of involvement: When change is dictated from the top without involving the people who are affected, resistance is guaranteed.\nLeaders Must Lead by Example # Peyton raised an important sixth point: leaders must lead by example. Many managers say the teams need to change, but they do not account for the impact of their own behaviors on the transformation. If you want a successful change and want to deal with resistance effectively, leaders need to embody the change themselves.\nI always say: leaders need to go first. They need to lead the change and embody it. Steve Ballmer once said \u0026ldquo;developers, developers, developers.\u0026rdquo; I usually say \u0026ldquo;leaders, leaders, leaders.\u0026rdquo; Leadership is the most important thing when it comes to transformation.\nKey Takeaways # Differentiate your approach. Resistance from managers requires data and facts. Resistance from team members requires empathy and clear benefits. Find the root cause. Surface-level transparency is not enough. Invest time in understanding why someone resists. Prepare for difficult conversations. Know who you are talking to, adapt your communication style, and have your arguments ready. Develop active listening. Hear and understand before responding. Invest in emotional intelligence. Meditation, breathing techniques, and proper sleep are your foundations. Leaders must go first. Without leadership embodying the change, no transformation will succeed. ","date":"23 September 2023","externalUrl":null,"permalink":"/en/blogs/overcoming-resistance-the-powerful-method-you-need/","section":"Blogs","summary":"In this podcast episode, I have a conversation with Peyton Einhaus about one of the most challenging aspects of any transformation: dealing with resistance. Whether you are running an agile transformation, a DevOps transformation, or any organizational change, resistance is always present. The question is how you handle it effectively.\n","title":"Overcoming Resistance: The Powerful Method You Need","type":"blogs"},{"content":"In dieser Podcast-Episode unterhalte ich mich mit Peyton Einhaus über einen der herausforderndsten Aspekte jeder Transformation: den Umgang mit Widerstand. Ob agile Transformation, DevOps-Transformation oder jede andere organisatorische Veränderung, Widerstand ist immer präsent. Die Frage ist, wie man damit effektiv umgeht.\nWiderstand von Managern vs. Teammitgliedern # Eine der ersten Fragen von Peyton war, ob man Widerstand unterschiedlich angehen muss, je nachdem, von wem er kommt. Die Antwort ist eindeutig ja.\nIm Umgang mit dem Management kommt der Widerstand meist aus Bedenken über Budgetierung, strategische Ausrichtung oder mögliche negative Auswirkungen auf ihre Abteilung. Bei Managern muss man Fakten, Zahlen und Daten präsentieren. Man muss auf der Datenebene argumentieren.\nBei Teammitgliedern ist der Widerstand anders. Er kommt aus Bedenken über Arbeitsbelastung, Kompetenzprofil oder wie sich die Veränderung auf ihren Arbeitsalltag auswirkt. Dort braucht man viel mehr Empathie, klare Kommunikation und muss zeigen, welche Vorteile es gibt. Die Schlüsselfrage für Teammitglieder ist immer: „Was habe ich davon?\u0026quot;\nDie eigentliche Ursache identifizieren # Transparenz und offene Kommunikation allein beseitigen den Widerstand nicht. Man muss erheblich Zeit investieren, um die tatsächliche Ursache zu identifizieren. Wenn jemand Angst hat, seinen Job zu verlieren, erfordert das einen komplett anderen Ansatz, als wenn jemand den Verlust von Kontrolle fürchtet oder einfach nicht genug versteht.\nEine Methode, die ich verwende, ist die Trade-off-Analyse. Ich zeige die Optionen: Bleiben, wo man ist, die Reise der Veränderung mitmachen oder in eine andere Abteilung oder ein anderes Unternehmen wechseln. Dann gehen wir gemeinsam Kriterien durch und bewerten, was die beste Option für diese Person ist. Es klingt einfach, aber dieses strukturierte Gespräch kann sehr wirkungsvoll sein.\nDen Kommunikationsstil anpassen # Es gibt ein Framework, das Menschen mit Farben kategorisiert. Rote Menschen sind hart und direkt. Blaue Menschen sind sehr analytisch und brauchen Zahlen, Daten und Fakten. Gelbe Menschen sind emotionaler. Die meisten Menschen sind eine Kombination.\nWenn man weiss, dass Widerstand kommen wird, ist Vorbereitung essenziell. Das habe ich auf die harte Tour gelernt. Unvorbereitet in ein Meeting zu gehen, wenn man Widerstand erwartet, kann gefährlich sein. Man braucht die Argumente bereit, muss die Menschen recherchieren, mit denen man sich trifft, ihren Persönlichkeitstyp verstehen und dann den Ton entsprechend anpassen.\n„Bereite dich immer auf ein Meeting vor. Besonders wenn du weisst, dass Widerstand kommen wird. Habe deine Argumente bereit und verstehe die Menschen, mit denen du sprichst.\u0026quot;\nPeyton ergänzte einen ausgezeichneten Punkt über das Rose-of-Leary-Framework. Bei dominanten Personen sollte man zuerst deren Ego schmeicheln, bevor man sanft um Hilfe bittet. Bei analytischen Menschen liefert man Beispiele und Metriken. Bei emotionalen Menschen geht man zuerst auf ihre Gefühle ein und zeigt Empathie, bevor man seine Anfrage stellt.\nDie vier essenziellen Fähigkeiten # Für alle, die im Bereich Agile Coaching, Scrum Mastering oder DevOps-Beratung arbeiten, gibt es vier Fähigkeiten, die für den Umgang mit Widerstand essenziell sind:\nAktives Zuhören: Dies ist die wichtigste Kommunikationsfähigkeit. In meiner frühen Karriere habe ich zu viel geredet und zu wenig zugehört. Man muss die Perspektive, Emotionen und Herausforderungen der anderen Person wirklich hören und verstehen.\nVerhandlung und Überzeugung: Eine schwierige Fähigkeit. Harte Verhandlungen sind anspruchsvoll, und ich gebe offen zu, dass es nicht meine stärkste Seite ist. Aber sie ist entscheidend für die Transformationsarbeit.\nEmotionale Intelligenz: Man muss die eigenen Emotionen kontrollieren können. Wenn jemand sehr emotional wird, weil er Angst hat, seinen Job zu verlieren, muss man die Ruhe bewahren und konstruktiv reagieren.\nProblemlösung: Man muss sich flexibel an neue Herausforderungen anpassen, verschiedene Standpunkte verstehen und gute Lösungen für schwierige Situationen finden.\nEmotionale Intelligenz trainieren # Emotionale Intelligenz ist eine der am schwierigsten zu trainierenden Fähigkeiten. Anders als aktives Zuhören oder Verhandlung, die man durch Übung lernen kann, fühlt sich emotionale Intelligenz eher wie eine Eigenschaft als eine Fähigkeit an.\nZwei Dinge haben mir am meisten geholfen. Erstens: Meditation. Ich meditiere täglich oder mindestens wöchentlich. Es beruhigt mich und hilft mir, meine Atmung zu kontrollieren. Kontrollierte Atmung beruhigt die Emotionen, und Meditation ist eine hervorragende Technik, das zu trainieren.\nZweitens: Schlaf. Acht Stunden jede Nacht schlafen. Wenn man weniger schläft, hat man eine sehr dünne Haut, wie wir sagen. Man wird emotional, weil man müde und erschöpft ist. Guter Schlaf ist die Grundlage für emotionale Regulation.\n„Schlafe jede Nacht acht Stunden. Wenn du weniger schläfst, hast du eine sehr dünne Haut und wirst schnell emotional, weil du müde und erschöpft bist.\u0026quot;\nDie fünf häufigsten Ursachen von Widerstand # Aus meiner Erfahrung sind dies die fünf häufigsten Ursachen von Widerstand bei Transformationen:\nAngst vor Veränderung: Menschen haben ihre Komfortzone und sind zufrieden, wo sie sind. Jede Veränderung bedeutet, diese Zone zu verlassen.\nMangelndes Verständnis: Nicht zu verstehen, worum es bei der Veränderung geht oder warum sie nötig ist. Als Führungskräfte müssen wir das „Warum\u0026quot; klar kommunizieren.\nAngst vor Jobverlust: Menschen befürchten, nicht gut genug für die neue Situation zu sein oder dass ihre Rolle verschwinden könnte.\nNegative Erfahrungen aus der Vergangenheit: Viele Menschen haben bereits mehrere Veränderungen durchgemacht, die nur halb umgesetzt oder komplett gescheitert sind. Sie glauben einfach nicht mehr an Veränderung.\nMangelnde Einbeziehung: Wenn Veränderung von oben diktiert wird, ohne die betroffenen Menschen einzubeziehen, ist Widerstand garantiert.\nFührungskräfte müssen mit gutem Beispiel vorangehen # Peyton brachte einen wichtigen sechsten Punkt ein: Führungskräfte müssen mit gutem Beispiel vorangehen. Viele Manager sagen, die Teams müssten sich ändern, berücksichtigen aber nicht die Auswirkungen ihres eigenen Verhaltens auf die Transformation. Wer eine erfolgreiche Veränderung will und Widerstand effektiv begegnen möchte, muss als Führungskraft die Veränderung selbst verkörpern.\nIch sage immer: Führungskräfte müssen vorangehen. Sie müssen die Veränderung anführen und vorleben. Steve Ballmer sagte einst „developers, developers, developers.\u0026quot; Ich sage: „leaders, leaders, leaders.\u0026quot; Führung ist das Wichtigste bei einer Transformation.\nKernaussagen # Differenziere deinen Ansatz. Widerstand von Managern erfordert Daten und Fakten. Widerstand von Teammitgliedern erfordert Empathie und klare Vorteile. Finde die Ursache. Oberflächliche Transparenz reicht nicht. Investiere Zeit, um zu verstehen, warum jemand Widerstand leistet. Bereite dich auf schwierige Gespräche vor. Wisse, mit wem du sprichst, passe deinen Kommunikationsstil an und habe deine Argumente bereit. Entwickle aktives Zuhören. Höre und verstehe, bevor du antwortest. Investiere in emotionale Intelligenz. Meditation, Atemtechniken und ausreichend Schlaf sind deine Grundlagen. Führungskräfte müssen vorangehen. Ohne Führungskräfte, die die Veränderung vorleben, wird keine Transformation gelingen. ","date":"23. September 2023","externalUrl":null,"permalink":"/de/blogs/widerstand-ueberwinden-die-methode-die-du-brauchst/","section":"Blogs","summary":"In dieser Podcast-Episode unterhalte ich mich mit Peyton Einhaus über einen der herausforderndsten Aspekte jeder Transformation: den Umgang mit Widerstand. Ob agile Transformation, DevOps-Transformation oder jede andere organisatorische Veränderung, Widerstand ist immer präsent. Die Frage ist, wie man damit effektiv umgeht.\n","title":"Widerstand überwinden: Die Methode, die du brauchst","type":"blogs"},{"content":"","date":"28 August 2023","externalUrl":null,"permalink":"/en/tags/continuous-integration/","section":"Tags","summary":"","title":"Continuous Integration","type":"tags"},{"content":"Embedded and IoT devices are becoming increasingly popular in today\u0026rsquo;s world. These devices are used in various industries, such as healthcare, manufacturing, consumer goods and home automation. Ensuring the quality of these devices is crucial to ensure their reliability, safety, and functionality. But how to do that?\nFrom Nikolaus Naredi-Rainer \u0026amp; Markus Zahner \u0026amp; Romano Roth\nIn recent years, the software that runs on embedded or IoT devices has become more and more the feather that tips the scales on whether these devices are successful on the market or if they fail in the customer’s eyes. When looking at companies that disrupted their market with their innovative hardware products, it becomes apparent that they often treat the product with a ‘software-first’ approach on top of Minimal Viable Product on the hardware side. On the other side are companies that often have established their market share over years and work with incremental innovation. In this software development scenario, oodles of resources are consumed, and manual steps are carried out, due to the organic growth of the companies and their processes. Although some companies may use the term “agile” in their development, usually the process phases run consecutively and separated from each other. After completing a phase (whether successful or not), the work results are tossed over the so-called ‘wall of confusion’, true to the motto of ‘devil-may-care’. This procedure results in the following main problems, which can be encountered in the same ways in a wide variety of organisations:\nMany manual steps, which make the overall process slow and susceptible to errors. Quality assurance and testing as separate phases at the end of the overall process. Security requirements and other non-functional requirements, such as load and performance or maintainability, are only discussed and checked just before final delivery. Lack of collaboration due to separate working areas and phases. DevOps in an embedded world: Make experimentation possible and speed up the time-to-market # Since people started to recognise a pattern in these behaviours and problems, a solution has emerged: DevOps.\nDevOps is a mindset, a culture and a series of technical practices. It provides communication, integration, automation and close collaboration between all persons across the whole value stream who are required for the planning, development, testing, provision, approval and maintenance of a product.\nDevOps tools in an Embedded world: automation is key # The goal of DevOps is to speed up the market launch, make experimentation possible, release software at shorter intervals, reduce the lead time for bug fixing and improve the average restoration time.\nWhile DevOps is a well-established practice in pure software domains, the embedded world has not yet fully embraced the DevOps mindset in many places. One of the many reasons for this lack of adaption is that embedded applications and the employed tools are often tailored to the specific application and its environment. The tools in use are diverse and the range of solutions to achieve some sort of automation is wide. For this reason, many standard DevOps tools and practices can only partially be used in an Embedded environment without adaption. This is especially true for the following 3 steps:\nTesting Monitoring Deployment This blog post will focus on testing, especially automated testing as automation is key in a DevOps setup.\nTo understand why automated testing is harder in the world of embedded device development, we need to look at the testing pyramid. The testing pyramid is a framework that helps developers to prioritize their testing efforts. A typical pyramid consists of three or more layers which typically contain at least unit tests, integration tests, and end-to-end tests. In general, tests that are lower in the pyramid, i.e. unit tests, are more isolated and faster and therefore cheap to automate, while tests that are higher in the pyramid, i.e. end-to-end or system tests, are more complex and expensive to automate.\nSuccess Stories: How to tackle the DevOps challenges for IoT devices # If we want to effectively bring DevOps to the Embedded world, we must facilitate the automation of the more complex system and end-to-end tests. Let’s see how leading manufacturers of IoT devices have tackled this challenge!\nEnd-to-end testing for a parking meter # The parking meter of Digital Parking is a typical IoT application: Data (e.g. what Vehicles are allowed to park on which parking lot for how long) is acquired and displayed on the device while the same information is available online to facilitate controlling and even provide live utilization data of the parking area. To enable automated end-to-end testing of the full system, a complete device was equipped with additional hardware such that user inputs (e.g. pressing a button or feeding coins) could be triggered on the real hardware.\nUsing such a setup, more than 50 test cases can be automated. They range from user interactions, e.g. paying for your parked car, to checking whether data had arrived in the cloud. Also, more sophisticated maintenance and installation use cases are possible to automate.\nThis test setup is on one hand used to periodically perform regression tests to ensure the IoT device is running stable, but also to replicate issues discovered in the field. Learn more in our success story \u0026ldquo;Parking meter for the Internet of Things\u0026rdquo;.\nPower Consumption Tests # To ensure the power efficiency of their devices, Texas Instruments (TI), a global semiconductor design and manufacturing company, has developed a suite of automated power measurement and analysis tools called the EnergyTrace™ software. This software enables developers to measure and analyse the power consumption of their devices in real time, both during development and in the field. The EnergyTrace software includes several features that enable developers to automate power consumption testing, including Continuous power profiling, Power measurement automation, Power analysis tools. By automating power consumption testing, TI can identify power consumption issues early in the development process and make iterative improvements to the design of their devices. This enables TI to deliver more power-efficient devices that meet the needs of their customers.\nSecurity Testing for IoT applications # While security testing on a running system (e.g. pen-testing) is challenging to automate because it involves testing the device\u0026rsquo;s vulnerability to various types of attacks, static testing of code is automatable with reasonable effort. Static application security testing (SAST) uses tools (e.g. Sonar Cube) to analyse the source code at compile time for vulnerabilities. When integrated into a CI pipeline (described here for GitLab and GitHub), such tools can be used to even prevent vulnerable code from being committed to the code base. Often, as part of static code analysis, secret scanning is also used to detect whether secrets are mistakenly committed to the source code. These tools help to prevent security issues in the application code (described here for GitLab and GitHub). Of course, there may also be security issues in third-party libraries that the application depends on. Software composition analysis (SCA) is checking these dependencies against public databases of known vulnerabilities. Several tools may be used to automate this task and can therefore be run periodically to not miss any newly found vulnerabilities (described here for GitLab and GitHub). Discover more possibilities with our \u0026ldquo;Industrial IoT Starterkit\u0026rdquo;.\nContinuous Integration for a medical oven # For the development and maintenance of a specialized, high-temperature oven for medical products, an automated testing framework has been developed by Zühlke. Building onto the Robot Framework, a test system was implemented such that many system tests could be executed automatically. The tests included user-centric use cases as well as factory use cases like calibration or maintenance cases such as updating the firmware. The test automation was finally integrated into the daily development flow and used in a dedicated pipeline such that these system tests would be performed for all changes committed to the code base. This setup greatly enabled the development team to move quicker on new features while having confidence that no regression would slip into a new release.\nConclusion: DevOps ensures market success and customer satisfaction # Continuous quality assurance of embedded and IoT devices is critical to ensuring their reliability, safety, and functionality. As the software running on these devices becomes increasingly important in determining their success in the market, it is essential to adopt a DevOps approach that prioritizes automated testing and collaboration across all phases of the development process.\nUnfortunately, this automation is not readily available for embedded devices as it requires dedicated effort on the developer side for every new product. In this article, we\u0026rsquo;ve shown how far companies go in their efforts to automate their testing for IoT devices which underlines the importance of closing the DevOps cycle and reaping its benefits.\nUltimately, investing in robust testing processes will not only ensure the success of these devices in the market but also promote user satisfaction and trust in their functionality and security.\nDo you want to explore the possibilities of DevOps? Please get in touch with us!\n","date":"28 August 2023","externalUrl":null,"permalink":"/en/blogs/devops-in-an-embedded-world-challenges-for-embedded-and-iot-devices/","section":"Blogs","summary":"Embedded and IoT devices are becoming increasingly popular in today’s world. These devices are used in various industries, such as healthcare, manufacturing, consumer goods and home automation. Ensuring the quality of these devices is crucial to ensure their reliability, safety, and functionality. But how to do that?\n","title":"DevOps in an Embedded World: Challenges for Embedded and IoT Devices","type":"blogs"},{"content":"Embedded- und IoT-Geräte werden in der heutigen Welt immer beliebter. Diese Geräte werden in verschiedenen Branchen eingesetzt, etwa im Gesundheitswesen, in der Fertigung, bei Konsumgütern und in der Heimautomation. Die Sicherstellung der Qualität dieser Geräte ist entscheidend, um deren Zuverlässigkeit, Sicherheit und Funktionalität zu gewährleisten. Aber wie macht man das?\nVon Nikolaus Naredi-Rainer \u0026amp; Markus Zahner \u0026amp; Romano Roth\nIn den vergangenen Jahren ist die Software, die auf Embedded- oder IoT-Geräten läuft, immer mehr zu dem Zünglein an der Waage geworden, das darüber entscheidet, ob diese Geräte am Markt erfolgreich sind oder in den Augen der Kundinnen und Kunden scheitern. Wenn man Unternehmen betrachtet, die ihren Markt mit innovativen Hardwareprodukten disruptiert haben, wird deutlich, dass sie das Produkt häufig mit einem «Software-first»-Ansatz angehen, aufgesetzt auf einem Minimal Viable Product auf der Hardwareseite. Auf der anderen Seite stehen Unternehmen, die ihren Marktanteil oft über Jahre etabliert haben und mit inkrementeller Innovation arbeiten. In diesem Software-Entwicklungsszenario werden Unmengen an Ressourcen verbraucht und manuelle Schritte ausgeführt, bedingt durch das organische Wachstum der Unternehmen und ihrer Prozesse. Auch wenn manche Unternehmen den Begriff «agil» in ihrer Entwicklung verwenden, laufen die Prozessphasen üblicherweise hintereinander und voneinander getrennt ab. Nach Abschluss einer Phase (ob erfolgreich oder nicht) werden die Arbeitsergebnisse über die sogenannte «Wall of Confusion» geworfen, ganz nach dem Motto «nach mir die Sintflut». Dieses Vorgehen führt zu folgenden Hauptproblemen, die in den unterschiedlichsten Organisationen in gleicher Weise anzutreffen sind:\nViele manuelle Schritte, die den Gesamtprozess langsam und fehleranfällig machen. Qualitätssicherung und Tests als separate Phasen am Ende des Gesamtprozesses. Sicherheitsanforderungen und andere nicht-funktionale Anforderungen wie Last und Performance oder Wartbarkeit werden erst kurz vor der Endauslieferung diskutiert und überprüft. Mangelnde Zusammenarbeit aufgrund getrennter Arbeitsbereiche und Phasen. DevOps in der Embedded-Welt: Experimentieren ermöglichen und die Time-to-Market beschleunigen # Seit man begonnen hat, ein Muster in diesen Verhaltensweisen und Problemen zu erkennen, hat sich eine Lösung herauskristallisiert: DevOps.\nDevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken. Es schafft Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Personen über den gesamten Wertstrom hinweg, die für die Planung, Entwicklung, Testung, Bereitstellung, Freigabe und Wartung eines Produkts erforderlich sind.\nDevOps-Werkzeuge in einer Embedded-Welt: Automatisierung ist der Schlüssel # Das Ziel von DevOps ist es, den Markteintritt zu beschleunigen, Experimente zu ermöglichen, Software in kürzeren Abständen freizugeben, die Vorlaufzeit für die Fehlerbehebung zu reduzieren und die durchschnittliche Wiederherstellungszeit zu verbessern.\nWährend DevOps in reinen Software-Domänen eine etablierte Praxis ist, hat die Embedded-Welt das DevOps-Mindset vielerorts noch nicht vollständig aufgegriffen. Einer der vielen Gründe für diese mangelnde Adaption ist, dass Embedded-Anwendungen und die eingesetzten Werkzeuge oft auf die spezifische Anwendung und deren Umgebung zugeschnitten sind. Die eingesetzten Werkzeuge sind vielfältig und das Spektrum an Lösungen, um eine Form der Automatisierung zu erreichen, ist breit. Aus diesem Grund können viele Standard-DevOps-Werkzeuge und -Praktiken in einer Embedded-Umgebung nur teilweise und nicht ohne Anpassung verwendet werden. Dies gilt insbesondere für die folgenden 3 Schritte:\nTesten Monitoring Deployment Dieser Blogbeitrag konzentriert sich auf das Testen, insbesondere auf automatisiertes Testen, da Automatisierung in einem DevOps-Setup zentral ist.\nUm zu verstehen, warum automatisiertes Testen in der Welt der Embedded-Geräteentwicklung schwieriger ist, müssen wir uns die Testpyramide ansehen. Die Testpyramide ist ein Framework, das Entwicklerinnen und Entwicklern hilft, ihre Testbemühungen zu priorisieren. Eine typische Pyramide besteht aus drei oder mehr Schichten, die in der Regel mindestens Unit-Tests, Integrationstests und End-to-End-Tests enthalten. Allgemein gilt: Tests, die in der Pyramide weiter unten stehen, also Unit-Tests, sind isolierter und schneller und daher kostengünstig zu automatisieren, während Tests, die weiter oben in der Pyramide stehen, also End-to-End- oder Systemtests, komplexer und teurer zu automatisieren sind.\nErfolgsgeschichten: Wie man die DevOps-Herausforderungen für IoT-Geräte angeht # Wenn wir DevOps wirksam in die Embedded-Welt bringen wollen, müssen wir die Automatisierung der komplexeren System- und End-to-End-Tests ermöglichen. Sehen wir uns an, wie führende Hersteller von IoT-Geräten diese Herausforderung angegangen sind!\nEnd-to-End-Test für eine Parkuhr # Die Parkuhr von Digital Parking ist eine typische IoT-Anwendung: Daten (z. B. welche Fahrzeuge wie lange auf welchem Parkplatz stehen dürfen) werden erfasst und auf dem Gerät angezeigt, während dieselben Informationen online verfügbar sind, um die Kontrolle zu erleichtern und sogar Live-Auslastungsdaten des Parkbereichs bereitzustellen. Um automatisierte End-to-End-Tests des Gesamtsystems zu ermöglichen, wurde ein vollständiges Gerät mit zusätzlicher Hardware ausgestattet, sodass Benutzereingaben (z. B. das Drücken einer Taste oder das Einwerfen von Münzen) auf der echten Hardware ausgelöst werden können.\nMit einem solchen Setup können mehr als 50 Testfälle automatisiert werden. Sie reichen von Benutzerinteraktionen, etwa dem Bezahlen für das geparkte Auto, bis hin zur Prüfung, ob Daten in der Cloud angekommen sind. Auch komplexere Wartungs- und Installations-Use-Cases lassen sich automatisieren.\nDieses Test-Setup wird zum einen verwendet, um regelmässig Regressionstests durchzuführen und sicherzustellen, dass das IoT-Gerät stabil läuft, zum anderen aber auch, um im Feld entdeckte Probleme zu reproduzieren. Erfahren Sie mehr in unserer Erfolgsgeschichte «Parkuhr für das Internet of Things».\nTests des Stromverbrauchs # Um die Energieeffizienz ihrer Geräte sicherzustellen, hat Texas Instruments (TI), ein global tätiges Halbleiter-Design- und Fertigungsunternehmen, eine Suite automatisierter Werkzeuge zur Strommessung und -analyse entwickelt, die EnergyTrace™-Software. Diese Software ermöglicht es Entwicklerinnen und Entwicklern, den Stromverbrauch ihrer Geräte in Echtzeit zu messen und zu analysieren – sowohl während der Entwicklung als auch im Feld. Die EnergyTrace-Software enthält mehrere Funktionen, mit denen Entwicklerinnen und Entwickler Tests des Stromverbrauchs automatisieren können, darunter kontinuierliches Power-Profiling, Automatisierung von Strommessungen und Power-Analyse-Tools. Durch die Automatisierung der Stromverbrauchstests kann TI Probleme beim Stromverbrauch frühzeitig im Entwicklungsprozess erkennen und das Design seiner Geräte iterativ verbessern. Dadurch kann TI energieeffizientere Geräte liefern, die den Bedürfnissen seiner Kundinnen und Kunden entsprechen.\nSicherheitstests für IoT-Anwendungen # Während Sicherheitstests an einem laufenden System (z. B. Pen-Testing) schwer zu automatisieren sind, weil sie das Testen der Anfälligkeit des Geräts gegenüber verschiedenen Angriffsarten umfassen, ist statisches Testen von Code mit vertretbarem Aufwand automatisierbar. Static Application Security Testing (SAST) verwendet Tools (z. B. SonarCube), um den Quellcode zur Compile-Zeit auf Schwachstellen zu analysieren. Wenn solche Tools in eine CI-Pipeline integriert werden (hier beschrieben für GitLab und GitHub), können sie sogar verhindern, dass anfälliger Code in die Codebasis eingecheckt wird. Häufig wird im Rahmen der statischen Codeanalyse auch Secret Scanning eingesetzt, um zu erkennen, ob Geheimnisse versehentlich in den Quellcode eingecheckt wurden. Diese Tools helfen, Sicherheitsprobleme im Anwendungscode zu verhindern (hier beschrieben für GitLab und GitHub). Natürlich kann es auch Sicherheitsprobleme in Drittanbieter-Bibliotheken geben, von denen die Anwendung abhängt. Software Composition Analysis (SCA) prüft diese Abhängigkeiten gegen öffentliche Datenbanken bekannter Schwachstellen. Mehrere Tools können verwendet werden, um diese Aufgabe zu automatisieren, und können daher regelmässig ausgeführt werden, um keine neu entdeckten Schwachstellen zu verpassen (hier beschrieben für GitLab und GitHub). Entdecken Sie weitere Möglichkeiten mit unserem «Industrial IoT Starterkit».\nContinuous Integration für einen medizinischen Ofen # Für die Entwicklung und Wartung eines spezialisierten Hochtemperaturofens für medizinische Produkte hat Zühlke ein automatisiertes Test-Framework entwickelt. Aufbauend auf dem Robot Framework wurde ein Testsystem implementiert, sodass viele Systemtests automatisch ausgeführt werden konnten. Die Tests umfassten benutzerzentrierte Use Cases sowie Fabrik-Use-Cases wie Kalibrierung oder Wartungsfälle wie das Aktualisieren der Firmware. Die Testautomatisierung wurde schliesslich in den täglichen Entwicklungsfluss integriert und in einer dedizierten Pipeline genutzt, sodass diese Systemtests für alle in die Codebasis eingecheckten Änderungen ausgeführt würden. Dieses Setup ermöglichte es dem Entwicklungsteam, sich bei neuen Features schneller zu bewegen, mit der Sicherheit, dass keine Regression in ein neues Release rutscht.\nFazit: DevOps sichert Markterfolg und Kundenzufriedenheit # Eine kontinuierliche Qualitätssicherung von Embedded- und IoT-Geräten ist entscheidend, um deren Zuverlässigkeit, Sicherheit und Funktionalität sicherzustellen. Da die auf diesen Geräten laufende Software zunehmend wichtiger für deren Erfolg am Markt wird, ist es essenziell, einen DevOps-Ansatz zu verfolgen, der automatisiertes Testen und die Zusammenarbeit über alle Phasen des Entwicklungsprozesses hinweg priorisiert.\nLeider ist diese Automatisierung für Embedded-Geräte nicht ohne Weiteres verfügbar, da sie für jedes neue Produkt einen dedizierten Aufwand auf der Entwicklerseite erfordert. In diesem Artikel haben wir gezeigt, wie weit Unternehmen in ihren Bemühungen gehen, ihre Tests für IoT-Geräte zu automatisieren, was die Bedeutung des Schliessens des DevOps-Zyklus und des Erntens seiner Vorteile unterstreicht.\nLetztlich werden Investitionen in robuste Testprozesse nicht nur den Erfolg dieser Geräte am Markt sicherstellen, sondern auch die Zufriedenheit der Nutzerinnen und Nutzer sowie das Vertrauen in deren Funktionalität und Sicherheit fördern.\nMöchten Sie die Möglichkeiten von DevOps erkunden? Bitte nehmen Sie Kontakt mit uns auf!\n","date":"28. August 2023","externalUrl":null,"permalink":"/de/blogs/devops-in-der-embedded-welt-herausforderungen-fuer-embedded-und-iot-geraete/","section":"Blogs","summary":"Embedded- und IoT-Geräte werden in der heutigen Welt immer beliebter. Diese Geräte werden in verschiedenen Branchen eingesetzt, etwa im Gesundheitswesen, in der Fertigung, bei Konsumgütern und in der Heimautomation. Die Sicherstellung der Qualität dieser Geräte ist entscheidend, um deren Zuverlässigkeit, Sicherheit und Funktionalität zu gewährleisten. Aber wie macht man das?\n","title":"DevOps in der Embedded-Welt: Herausforderungen für Embedded- und IoT-Geräte","type":"blogs"},{"content":"","date":"28 August 2023","externalUrl":null,"permalink":"/en/tags/hardware/","section":"Tags","summary":"","title":"Hardware","type":"tags"},{"content":"","date":"28 August 2023","externalUrl":null,"permalink":"/en/tags/iot/","section":"Tags","summary":"","title":"IoT","type":"tags"},{"content":"","date":"28. August 2023","externalUrl":null,"permalink":"/de/tags/qualit%C3%A4tssicherung/","section":"Tags","summary":"","title":"Qualitätssicherung","type":"tags"},{"content":"","date":"28 August 2023","externalUrl":null,"permalink":"/en/tags/quality-assurance/","section":"Tags","summary":"","title":"Quality Assurance","type":"tags"},{"content":"","date":"28 August 2023","externalUrl":null,"permalink":"/en/tags/test-automation/","section":"Tags","summary":"","title":"Test Automation","type":"tags"},{"content":"","date":"28. August 2023","externalUrl":null,"permalink":"/de/tags/testautomatisierung/","section":"Tags","summary":"","title":"Testautomatisierung","type":"tags"},{"content":"","date":"13. August 2023","externalUrl":null,"permalink":"/de/tags/achtsamkeit/","section":"Tags","summary":"","title":"Achtsamkeit","type":"tags"},{"content":"","date":"13 August 2023","externalUrl":null,"permalink":"/en/tags/fun/","section":"Tags","summary":"","title":"Fun","type":"tags"},{"content":"Manchmal müssen wir in der Welt des Platform Engineering innehalten und die digitalen Landschaften würdigen, die wir jeden Tag bauen. Dieses kurze, spielerische Video ist eine geführte Meditation für Platform Engineers. Finde eine bequeme Position, atme tief ein und lass dich durch die Welt führen, die du erschaffst.\nDie digitale Landschaft # Stell dir vor, du stehst an der Schwelle einer weiten digitalen Landschaft. Dieses Reich ist eine Manifestation der Plattformen und Infrastrukturen, die du entwirfst, erstellst und pflegst. Es ist weit, vernetzt und harmonisch ausbalanciert.\nVor dir erheben sich Türme aus Code. Sie repräsentieren die Infrastructure-as-Code-Praktiken, die du anwendest. Sie stehen hoch aufragend, ihre Fundamente tief und solide, ein Zeugnis ihrer Widerstandsfähigkeit und Stabilität.\nClouds, Microservices und Pipelines # Über dir schweben Wolken. Das sind keine gewöhnlichen Wolken. Sie schimmern vor Konnektivität und repräsentieren die Cloud-Services von Anbietern wie AWS, Azure oder Google Cloud. Spüre ihre expansive Reichweite, die Lücken überbrückt und grenzenloses Potenzial bietet.\nWeiter vorne bemerkst du Cluster kleiner, miteinander verbundener Einheiten: Microservices. Wie ein blühendes Ökosystem hat jede Einheit ihren Zweck und funktioniert nahtlos mit den anderen. Container stellen sicher, dass sie gekapselt, geschützt und effizient ausgeliefert werden.\nEine Brise weht über diese Landschaft. Das ist deine CI/CD-Pipeline, die jedes Teil dieses komplexen Puzzles rationalisiert, automatisiert und integriert. Mit jedem Windstoss spürst du ein Gefühl der Erfüllung, wenn Deployments reibungslos durchgeführt werden.\nObservability, Service Meshes und Security # Unter deinen Füssen pulsiert der Boden lebendig mit Daten. Hier liegen die Observability- und Monitoring-Tools, die du integriert hast. Jeder Puls ist eine Metrik, ein Log, ein Trace, der die Gesundheit und Performance deiner Plattformen sicherstellt.\nBäche schlängeln sich durch das Land, ihr Wasser klar und fliessend. Das sind deine Service Meshes, die Kommunikation ermöglichen, Lasten verteilen und Resilienz in deiner Microservices-Umgebung sicherstellen.\nUm diese Landschaft herum liegt eine schützende Aura, eine sanfte, undurchdringliche Kraft. Das ist die Security, die du in jede Schicht eingebettet hast. Spüre ihre Stärke, wie sie deine Plattformen und die Daten, die sie halten, schützt.\nKernaussagen # Nimm dir einen Moment, um die Komplexität und Schönheit der Plattformen zu würdigen, die du baust. Infrastructure as Code, Cloud-Services, Microservices, CI/CD-Pipelines, Observability, Service Meshes und Security sind nicht nur Tools. Sie bilden ein lebendiges, atmendes digitales Ökosystem. Möge Platform Engineering stets mit dir sein. ","date":"13. August 2023","externalUrl":null,"permalink":"/de/blogs/gefuehrte-platform-engineering-meditation/","section":"Blogs","summary":"Manchmal müssen wir in der Welt des Platform Engineering innehalten und die digitalen Landschaften würdigen, die wir jeden Tag bauen. Dieses kurze, spielerische Video ist eine geführte Meditation für Platform Engineers. Finde eine bequeme Position, atme tief ein und lass dich durch die Welt führen, die du erschaffst.\n","title":"Geführte Platform Engineering Meditation","type":"blogs"},{"content":"Sometimes in the world of platform engineering, we need to pause and appreciate the digital landscapes we build every day. This short, playful video is a guided meditation for platform engineers. Find a comfortable position, take a deep breath, and let me guide you through the world you create.\nThe Digital Landscape # Imagine standing at the threshold of a vast digital landscape. This realm is a manifestation of the platforms and infrastructures you design, create, and maintain. It is vast, interconnected, and harmoniously balanced.\nIn front of you, towers of code rise from the ground. These represent the infrastructure-as-code practices you employ. They stand tall, their foundations deep and solid, a testament to their resilience and stability.\nClouds, Microservices, and Pipelines # Above you, clouds hover. These are not ordinary clouds. They shimmer with connectivity, representing the cloud services from providers like AWS, Azure, or Google Cloud. Feel their expansive reach, bridging gaps and providing limitless potential.\nFurther ahead, you notice clusters of small, interlinked units: microservices. Like a thriving ecosystem, each unit has its purpose, functioning seamlessly with the others. Containers ensure they are encapsulated, protected, and efficiently delivered.\nA breeze flows across this landscape. This is your CI/CD pipeline, streamlining, automating, and integrating every piece of this intricate puzzle. With every gust, you feel a sense of accomplishment as deployments are made without hiccups.\nObservability, Service Meshes, and Security # Beneath your feet, the ground pulses alive with data. Here lie the observability and monitoring tools you have integrated. Each pulse is a metric, a log, a trace, ensuring the health and performance of your platforms.\nStreams meander through the land, their waters clear and flowing. These are your service meshes, facilitating communication, balancing loads, and ensuring resilience in your microservices environment.\nSurrounding this landscape is a protective aura, a gentle, impenetrable force. This is the security you have embedded into every layer. Feel its strength, safeguarding your platforms and the data they hold.\nKey Takeaways # Take a moment to appreciate the complexity and beauty of the platforms you build. Infrastructure as code, cloud services, microservices, CI/CD pipelines, observability, service meshes, and security are not just tools. They form a living, breathing digital ecosystem. May platform engineering be with you, always. ","date":"13 August 2023","externalUrl":null,"permalink":"/en/blogs/guided-platform-engineering-meditation/","section":"Blogs","summary":"Sometimes in the world of platform engineering, we need to pause and appreciate the digital landscapes we build every day. This short, playful video is a guided meditation for platform engineers. Find a comfortable position, take a deep breath, and let me guide you through the world you create.\n","title":"Guided Platform Engineering Meditation","type":"blogs"},{"content":"","date":"13 August 2023","externalUrl":null,"permalink":"/en/tags/mindfulness/","section":"Tags","summary":"","title":"Mindfulness","type":"tags"},{"content":"","date":"13. August 2023","externalUrl":null,"permalink":"/de/tags/spass/","section":"Tags","summary":"","title":"Spass","type":"tags"},{"content":"","date":"5 August 2023","externalUrl":null,"permalink":"/en/tags/business-case/","section":"Tags","summary":"","title":"Business Case","type":"tags"},{"content":"Jeder DevOps-Enthusiast steht irgendwann vor derselben Herausforderung: Sie wissen, dass DevOps funktioniert, Ihr Team weiss es auch, aber die Entscheidungsträger wollen Beweise. Sie wollen einen Business Case. In diesem Vortrag bei den ContainerDays 2019 stelle ich ein praktisches Framework vor, um CIOs und Manager davon zu überzeugen, Ihre DevOps-Transformation zu finanzieren.\nDer aktuelle Zustand der IT # Heutige Unternehmen kämpfen mit einem bekannten Set von Problemen. Es gibt technische Schulden in der Applikationslandschaft, der Infrastruktur und den Applikationen selbst. Silos arbeiten nicht zusammen, sondern gegeneinander. Es gibt eine Kultur, die Risiko und Innovation nicht akzeptiert. Vertrauen fehlt. Und über allem schweben die ständigen Kosteneinsparungen: mehr leisten mit weniger Geld.\nEntscheidungsträger sagen, sie wollen DevOps. Aber wenn Sie mit ihnen über die DevOps-Kernwerte sprechen (Verantwortlichkeit, Vertrauen, Befähigung, kontinuierliche Verbesserung, Kundenzentrierung), nicken sie. Wenn Sie die DevOps-Ziele erklären (häufigere Releases, schnellere Deployments, verbesserte Mean Time to Recovery, kürzere Durchlaufzeit für Bugfixes, schnellere Experimentierung), werden sie begeistert. Dann fragen sie: \u0026ldquo;Kostet dieses DevOps etwas? Weil wir haben Kosteneinsparungen.\u0026rdquo; Und wenn Sie bestätigen, dass ja, sagen sie: \u0026ldquo;Also sagen Sie mir, was ist der Business Case?\u0026rdquo;\nWas ist ein Business Case? # Ein Business Case teilt Nutzen und Chancen durch Kosten und Risiken. Wenn das Ergebnis positiv ist, sollten Sie es tun. Wenn negativ, sollten Sie es lassen. Und wenn Sie eine Division durch Null erhalten, sollten Sie den Business Case debuggen.\nFür Entscheidungsträger zählt vor allem eine Frage: Wann bekommen sie ihren Return on Investment? Das ist der Punkt, an dem sich die Investition amortisiert und sie das Geld in neue Initiativen reinvestieren können. Sie müssen ihnen genau zeigen, wann das passiert.\nWo Wert generiert wird # Dies ist das wichtigste Konzept. In einer typischen Wertschöpfungskette wird eine Idee zur User Story, wird implementiert, deployed und an den Kunden released. Während der gesamten Kette von der Idee bis zum Release wird kein Wert generiert. Wert entsteht erst, wenn das Feature oder Produkt den Kunden erreicht, wenn er es nutzt und dafür bezahlt.\n\u0026ldquo;Während der gesamten Wertschöpfungskette wird kein Wert generiert. Nur wenn das Feature oder Produkt beim Kunden ist, wird Wert generiert.\u0026rdquo;\nDas Geld, das Kunden zahlen, fliesst als Einnahmen zurück, die in neue Ideen reinvestiert werden können, die wieder durch den Wertstrom fliessen. Die DevOps-Investition entsteht, indem Sie einen Teil dieses Geldes nehmen und in die Verbesserung der Durchlaufzeit der Wertschöpfungskette investieren, anstatt alles in neue Features zu stecken.\nDer Zeitwert des Geldes # Das ökonomische Konzept des Zeitwerts des Geldes besagt, dass ein Euro heute immer mehr wert ist als ein Euro morgen. Die Schlussfolgerung ist klar: Sie sollten so früh wie möglich investieren wegen der Ertragskraft in der Zukunft.\nOhne DevOps haben grosse Unternehmen typischerweise dreimonatige Release-Zyklen. Während dieser drei Monate durchlaufen Features Definition, Implementierung und Deployment, aber kein Wert wird generiert. Erst nach dem dreimonatigen Release beginnt der Kunde, Features zu nutzen und dafür zu bezahlen. In diesem Beispiel kommt der Return on Investment etwa zwei Monate nach dem Release, also insgesamt fünf Monate.\nMit DevOps liefern Sie Wert schneller an den Kunden. Release-Zyklen schrumpfen. Kleinere Features erreichen den Kunden früher. Der Return on Investment kommt schneller. Und dieser schnellere Return ermöglicht es Ihnen, in neue Ideen oder weitere DevOps-Transformation zu reinvestieren.\nDer Reinvestitions-Kreislauf # Der Ausgangspunkt ist einfach: Investieren Sie einen Teil des Geldes, das in neue Ideen gehen könnte, in die Verbesserung des Wertstroms. Verbessern Sie die Durchlaufzeit. Sobald verbessert, haben Sie einen schnelleren Wertstrom von Definition über Implementierung bis Deployment. Sie können häufiger releasen, Features schneller zu Kunden bringen und einen schnelleren Return on Investment erzielen.\nDies erzeugt einen Zinseszins-Kreislauf. Jede Verbesserung finanziert die nächste. Jeder schnellere Return on Investment ermöglicht weitere DevOps-Investitionen. Der Wertstrom wird immer schneller, und der Abstand zu Wettbewerbern, die kein DevOps machen, wächst stetig.\n\u0026ldquo;Fokussieren Sie sich auf schnelle Wertgenerierung. Damit wird nicht nur Ihr Produkt erfolgreich sein, das gesamte Unternehmen wird erfolgreich sein.\u0026rdquo;\nDie wahren Gewinner # Wenn dieser Kreislauf läuft, gewinnen alle. Das Unternehmen wird erfolgreicher, weil es schneller Wert generiert. Kunden sind zufrieden, weil sie Features schnell erhalten. Und das Geld fliesst weiter und ermöglicht kontinuierliche Verbesserung.\nDas ist das Werkzeug, das Sie brauchen, um Ihren Entscheidungsträger zu überzeugen. Sprechen Sie nicht über abstrakte Werte und Praktiken. Zeigen Sie den Business Case: in die Verkürzung des Wertstroms investieren, schneller Wert generieren, schnelleren Return on Investment erzielen und die Renditen reinvestieren. Es ist eine einfache, überzeugende Geschichte, die jeder CIO versteht.\nKernaussagen # Wert wird nur beim Kunden generiert. Nicht während Definition, Implementierung oder Deployment. Das ist das Fundament des DevOps-Business-Case.\nDer Zeitwert des Geldes gilt für DevOps. Jetzt zu investieren ist mehr wert als später. Jeder Monat, den Sie warten, kostet Sie Zinseszins-Renditen.\nBeginnen Sie mit der Verbesserung der Durchlaufzeit. Die erste DevOps-Investition sollte die Zeit von der Idee bis zum Kundenwert verkürzen. Alles andere folgt daraus.\nZeigen Sie den Reinvestitions-Kreislauf. Entscheidungsträger verstehen Zinseszins-Renditen. Jede DevOps-Verbesserung finanziert die nächste und erzeugt beschleunigende Wertschöpfung.\nMit DevOps gewinnen alle. Schnellere Wertgenerierung nutzt dem Unternehmen, den Teams und den Kunden. Das ist kein Nullsummenspiel.\n","date":"5. August 2023","externalUrl":null,"permalink":"/de/blogs/business-case-von-devops-containerdays/","section":"Blogs","summary":"Jeder DevOps-Enthusiast steht irgendwann vor derselben Herausforderung: Sie wissen, dass DevOps funktioniert, Ihr Team weiss es auch, aber die Entscheidungsträger wollen Beweise. Sie wollen einen Business Case. In diesem Vortrag bei den ContainerDays 2019 stelle ich ein praktisches Framework vor, um CIOs und Manager davon zu überzeugen, Ihre DevOps-Transformation zu finanzieren.\n","title":"Der Business Case von DevOps: So überzeugen Sie Ihre Entscheidungsträger","type":"blogs"},{"content":"","date":"5 August 2023","externalUrl":null,"permalink":"/en/tags/return-on-investment/","section":"Tags","summary":"","title":"Return on Investment","type":"tags"},{"content":"Every DevOps enthusiast faces the same challenge at some point: you know DevOps works, your team knows it works, but the decision makers want proof. They want a business case. In this talk at ContainerDays 2019, I break down a practical framework for convincing CIOs and managers to fund your DevOps transformation.\nThe Current State of IT # Today\u0026rsquo;s enterprises struggle with a familiar set of problems. There is technical debt in the application landscape, the infrastructure, and the applications themselves. Silos are not working together but fighting against each other. There is a culture that does not accept risk and innovation. Trust is lacking. And on top of everything, there are constant cost cuts: do more with less money.\nDecision makers say they want DevOps. But when you talk to them about the DevOps core values (accountability, trust, empowerment, continuous improvement, customer centricity), they nod along. When you explain the DevOps targets (more frequent releases, faster deployments, improved mean time to recovery, shorter lead time for bug fixes, faster experimentation), they get excited. Then they ask: \u0026ldquo;Does this DevOps thing cost anything? Because we have cost cuts.\u0026rdquo; And when you confirm it does, they say: \u0026ldquo;So tell me, what is the business case?\u0026rdquo;\nWhat Is a Business Case? # A business case divides benefits and chances by costs and risks. If the result is positive, you should proceed. If negative, you should not. And if you get a division by zero, you should debug that business case.\nFor decision makers, one question matters above all: when do they get their return on investment? That is the point where the investment pays for itself and they can reinvest the money into new initiatives. You need to show them exactly when that happens.\nWhere Value Is Generated # This is the most critical concept to understand. In a typical value chain, an idea becomes a user story, gets implemented, deployed, and released to the customer. During the entire chain from idea to release, no value is generated. Value is only generated when the feature or product reaches the customer, when they use it and pay for it.\n\u0026ldquo;During the whole value chain, no value is generated. Only when the feature or product is at the customer site is value generated.\u0026rdquo;\nThe money customers pay flows back as earnings, which can be reinvested into new ideas that flow through the value stream again. The DevOps investment comes from taking some of this money and using it to improve the lead time of the value chain, instead of putting all of it into new features.\nThe Time Value of Money # The economic concept of Time Value of Money states that a Euro today is always worth more than a Euro tomorrow. The implication is clear: you should invest as early as possible because of the earning capacity in the future.\nWithout DevOps, large enterprises typically have three-month release cycles. During those three months, features flow through definition, implementation, and deployment, but no value is generated. Only after the three-month release does the customer start using features and paying for them. In this example, the return on investment might come about two months after release, so five months total.\nWith DevOps, you deliver value to the customer faster. Release cycles shrink. Smaller features reach the customer sooner. The return on investment arrives earlier. And this faster return enables you to reinvest into either new ideas or further DevOps transformation.\nThe Reinvestment Cycle # The starting point is simple: invest some of the money that could go into new ideas into improving the value stream. Improve the lead time. Once improved, you have a faster value stream from definition through implementation to deployment. You can release more often, bring features to customers faster, and achieve faster return on investment.\nThis creates a compounding cycle. Each improvement funds the next. Each faster return on investment enables more DevOps investment. The value stream keeps getting faster, and the gap between you and competitors who are not doing DevOps keeps growing.\n\u0026ldquo;Focus on fast value generation. With that, not only your product will be successful, the whole enterprise will be successful.\u0026rdquo;\nThe Real Winners # When you get this cycle going, everybody wins. The enterprise becomes more successful because it generates value faster. Customers are happy because they get features quickly. And the money keeps flowing, enabling continuous improvement.\nThis is the tool you need to convince your decision maker. Do not talk about abstract values and practices. Show the business case: invest in shortening the value stream, generate value faster, achieve faster return on investment, and reinvest the returns. It is a simple, compelling story that every CIO understands.\nKey Takeaways # Value is generated only at the customer. Not during definition, implementation, or deployment. This is the foundation of the DevOps business case.\nTime Value of Money applies to DevOps. Investing now is worth more than investing later. Every month you wait costs you compounding returns.\nStart by improving lead time. The first DevOps investment should reduce the time from idea to customer value. Everything else follows from that.\nShow the reinvestment cycle. Decision makers understand compound returns. Each DevOps improvement funds the next, creating accelerating value.\nEverybody wins with DevOps. Faster value generation benefits the enterprise, the teams, and the customers. This is not a zero-sum game.\n","date":"5 August 2023","externalUrl":null,"permalink":"/en/blogs/business-case-of-devops-containerdays/","section":"Blogs","summary":"Every DevOps enthusiast faces the same challenge at some point: you know DevOps works, your team knows it works, but the decision makers want proof. They want a business case. In this talk at ContainerDays 2019, I break down a practical framework for convincing CIOs and managers to fund your DevOps transformation.\n","title":"The Business Case of DevOps: How to Convince Your Decision Makers","type":"blogs"},{"content":"Many companies are suffering from a lack of alignment between business and IT, silo thinking, and inefficiencies in product development, while time to market is becoming increasingly important.\nThe Problem # These companies try to adopt DevOps in their organizations, but unfortunately, sometimes the DevOps approach is misunderstood, wrongly implemented, and it does not scale as expected.\nThe Digital Factory # We are entering the age of the industrialization of software development. The Digital Factory together with Platform Engineering will help industrialize digital product development across teams to efficiently develop products and improve the lives of our staff, time to market, quality, and alignment.\nWhat You Will Learn # What are the current challenges in scaling software delivery What is DevOps and what it is not How to scale DevOps across an organization How Platform Engineering provides the foundation How to implement a Digital Factory step by step ","date":"5 August 2023","externalUrl":null,"permalink":"/en/speaking/the-digital-factory/","section":"Speaking","summary":"Many companies are suffering from a lack of alignment between business and IT, silo thinking, and inefficiencies in product development, while time to market is becoming increasingly important.\nThe Problem # These companies try to adopt DevOps in their organizations, but unfortunately, sometimes the DevOps approach is misunderstood, wrongly implemented, and it does not scale as expected.\n","title":"The Digital Factory","type":"speaking"},{"content":"","date":"5 August 2023","externalUrl":null,"permalink":"/en/tags/value-generation/","section":"Tags","summary":"","title":"Value Generation","type":"tags"},{"content":"Sie wollen DevOps einführen. Ihr Team will DevOps einführen. Sogar Ihr CIO will DevOps einführen. Aber dann kommt die unvermeidliche Frage: \u0026ldquo;Was ist der Business Case?\u0026rdquo; In diesem fünfminütigen Ignite Talk bei den DevOpsDays teile ich ein einfaches, aber wirkungsvolles Werkzeug, um Entscheidungsträger davon zu überzeugen, dass sich die Investition in DevOps lohnt.\nDas Problem: Entscheidungsträger wollen Zahlen # Heutige Unternehmen kämpfen mit technischen Schulden, organisatorischen Silos und Kosteneinsparungen. Entscheidungsträger wollen DevOps einführen, verstehen aber nicht, was es wirklich bedeutet. Wenn Sie über Vertrauen, Verantwortlichkeit und datengesteuerte Entscheidungsfindung sprechen, nicken sie. Wenn Sie schnellere Deployments und verbesserte Mean Time to Recovery erwähnen, stimmen sie zu. Aber dann sagen sie: \u0026ldquo;Sie können kein Geld haben. Wir haben Kosteneinsparungen. Was ist der Business Case?\u0026rdquo;\nVerstehen, wo Wert generiert wird # Ein Business Case ist einfach: Teilen Sie Nutzen und Chancen durch Kosten und Risiken. Wenn das Ergebnis positiv ist, tun Sie es. Entscheidungsträger interessiert vor allem eines: Wann bekommen sie ihren Return on Investment?\nDie entscheidende Erkenntnis ist diese: Wert wird nur beim Kunden generiert. Von der Idee über die Implementierung bis zum Deployment wird kein Wert erzeugt. Erst wenn der Kunde das Produkt nutzt und dafür bezahlt, entsteht Wert. Dieses Geld kann dann in neue Ideen reinvestiert werden, die durch den Wertstrom fliessen.\n\u0026ldquo;Wert wird nur beim Kunden generiert. Von der Idee über die Implementierung bis zum Deployment wird kein Wert erzeugt.\u0026rdquo;\nDer Zeitwert des Geldes # Das ökonomische Konzept des Zeitwerts des Geldes besagt, dass ein Euro heute immer mehr wert ist als ein Euro morgen. Das bedeutet: Sie sollten früh investieren und jetzt investieren.\nTraditionelle Unternehmen haben dreimonatige Release-Zyklen. Während dieser drei Monate wird kein Wert generiert. Erst nach dem Release fliesst Wert. Mit DevOps schrumpfen die Release-Zyklen. Wert erreicht den Kunden schneller. Der Return on Investment kommt früher. Und dieser schnellere Return kann in weitere DevOps-Verbesserungen reinvestiert werden, was einen Zinseszinseffekt erzeugt.\nDer positive Kreislauf # Der erste Schritt ist einfach: Nehmen Sie einen Teil Ihrer Einnahmen und investieren Sie in die Verbesserung der Durchlaufzeit Ihrer Wertschöpfungskette. Wenn der Wertstrom schneller wird, können Sie mehr Deployments machen und einen schnelleren Return on Investment erzielen, den Sie wieder reinvestieren.\nDies erzeugt einen positiven Kreislauf: Schnelle Wertgenerierung führt zu schnellem Return on Investment, der weitere DevOps-Verbesserungen finanziert, die die Wertgenerierung noch weiter beschleunigen. Alle gewinnen: das Unternehmen, die Teams und die Kunden.\nKernaussagen # Fokus auf schnelle Wertgenerierung. Der Kern des DevOps-Business-Case ist die Verkürzung der Zeit von der Idee bis zum Kundenwert.\nNutzen Sie den Zeitwert des Geldes. Jetzt in DevOps zu investieren ist mehr wert als später, weil frühere Wertgenerierung sich über die Zeit aufaddiert.\nZeigen Sie den Reinvestitions-Kreislauf. DevOps ist keine einmalige Ausgabe. Jede Verbesserung finanziert die nächste und erzeugt beschleunigende Renditen.\n","date":"5. August 2023","externalUrl":null,"permalink":"/de/blogs/business-case-von-devops-ignite-talk/","section":"Blogs","summary":"Sie wollen DevOps einführen. Ihr Team will DevOps einführen. Sogar Ihr CIO will DevOps einführen. Aber dann kommt die unvermeidliche Frage: “Was ist der Business Case?” In diesem fünfminütigen Ignite Talk bei den DevOpsDays teile ich ein einfaches, aber wirkungsvolles Werkzeug, um Entscheidungsträger davon zu überzeugen, dass sich die Investition in DevOps lohnt.\n","title":"Was ist der Business Case von DevOps? Ein Ignite Talk","type":"blogs"},{"content":"","date":"5. August 2023","externalUrl":null,"permalink":"/de/tags/wertgenerierung/","section":"Tags","summary":"","title":"Wertgenerierung","type":"tags"},{"content":"You want to do DevOps. Your team wants to do DevOps. Even your CIO wants to do DevOps. But then comes the inevitable question: \u0026ldquo;What is the business case?\u0026rdquo; In this five-minute Ignite Talk at DevOpsDays, I share a simple but powerful tool to convince decision makers that DevOps is worth the investment.\nThe Problem: Decision Makers Want Numbers # Today\u0026rsquo;s enterprises struggle with technical debt, organizational silos, and cost cuts. Decision makers want to adopt DevOps, but they do not understand what it actually is. When you talk about trust, accountability, and data-driven decision making, they nod. When you mention faster deployments and improved mean time to recovery, they agree. But then they say: \u0026ldquo;You cannot have any money. We have cost cuts. What is the business case?\u0026rdquo;\nUnderstanding Where Value Is Generated # A business case is simple: divide benefits and chances by costs and risks. If the result is positive, do it. Decision makers care about one thing above all: when do they get their return on investment?\nThe critical insight is this: value is only generated at the customer site. From idea through implementation to deployment, no value is generated. Only when the customer uses the product and pays for it does value appear. That money can then be reinvested into new ideas flowing through the value stream.\n\u0026ldquo;Value is only generated at the customer site. From the idea through implementation till deployment, no value is generated.\u0026rdquo;\nThe Time Value of Money # The economic concept of Time Value of Money states that a dollar today is always worth more than a dollar tomorrow. This means you should invest early and invest now.\nTraditional enterprises have three-month release cycles. During those three months, no value is generated. Only after release does value flow. With DevOps, release cycles shrink. Value reaches the customer faster. Return on investment comes sooner. And that faster return can be reinvested into further DevOps improvements, creating a compounding effect.\nThe Virtuous Cycle # The first step is straightforward: take part of your earnings and invest them into improving the lead time of your value chain. As the value stream gets faster, you can do more deployments and achieve faster return on investment, which you reinvest again.\nThis creates a virtuous cycle: fast value generation leads to fast return on investment, which funds more DevOps improvements, which accelerates value generation even further. Everybody wins: the company, the teams, and the customers.\nKey Takeaways # Focus on fast value generation. The core of the DevOps business case is shortening the time from idea to customer value.\nUse the Time Value of Money. Investing in DevOps now is worth more than investing later, because earlier value generation compounds over time.\nShow the reinvestment cycle. DevOps is not a one-time cost. Each improvement funds the next, creating accelerating returns.\n","date":"5 August 2023","externalUrl":null,"permalink":"/en/blogs/business-case-of-devops-ignite-talk/","section":"Blogs","summary":"You want to do DevOps. Your team wants to do DevOps. Even your CIO wants to do DevOps. But then comes the inevitable question: “What is the business case?” In this five-minute Ignite Talk at DevOpsDays, I share a simple but powerful tool to convince decision makers that DevOps is worth the investment.\n","title":"What Is the Business Case of DevOps? An Ignite Talk","type":"blogs"},{"content":"","date":"2 August 2023","externalUrl":null,"permalink":"/en/tags/cloud-migration/","section":"Tags","summary":"","title":"Cloud Migration","type":"tags"},{"content":"By Anna Redbond and Romano Roth on August 2, 2023\nA lot of banks are moving to modern software development despite the traditional industry hurdles like compliance, regulations, and legacy architecture. The shared goal: becoming more adaptable to meet customers’ changing demands.\nWe sat down with Romano Roth, Chief of DevOps at Zühlke, who shared his insights on how major banks are moving to modern software development processes and getting features to market faster. He covers the debate between moving to the cloud vs developing on-premises, continuous integration, and how teams can move away from legacy architecture.\nWhat Prompts Banks to Start Modernising Software Development? # Three main things drive change:\nFaster time to market More value for money Customer satisfaction It often starts by noticing inefficiencies. Management and teams realise they’re paying a lot and waiting a long time for simple changes. The legacy processes, mindsets, infrastructure, tools, organisation and regulations start to stand in the way and make things move slower than teams would like.\nThis makes the development of products and services quite expensive, and teams can end up investing a lot of time and money to make even simple things happen.\nModernising Development Processes # The solution is usually modernising the whole development process, which can involve migrating development to the cloud or adopting a hybrid approach with on-premises deployments.\nDeveloping in the Cloud # Teams can move the whole development approach out of the back so that they’re developing in the cloud with modern tools and modern approaches. This means they don’t need to worry about the bank’s internal regulations.\nThis requires some, potentially substantial, investment, though. There are other options but if teams invest their development processes can run about 25% faster.\nThere’s often a massive amount of resistance to moving to the cloud, though, especially from the people that have built, operated and maintained the internal legacy infrastructure and applications. There’s also resistance from the security side because it seems easier to implement security restrictions on-premises than in the cloud. Lastly, teams need to remove confidential data and use synthetic test data (which many would argue they already should have done in the first place.)\nA Hybrid Approach: Developing Outside and Deploying On-Premises # One solution, in the case of confidential data, is to develop the software outside and bring the source code or compiled code into the bank, and deploy it to the on-premises infrastructure. So it’s running on-premises (and meeting the security requirements and regulations) with development happening outside.\nGetting Products to Market Faster # Efficiency is one of the main things teams notice when they start modernising their processes. Companies will simply get more value for money.\nWhat also happens is a faster time to market, which is usually the business driver. If development was too slow, costly, and the developer experience wasn’t working well, then changing that and getting products to market faster is always a good thing.\nThis is where teams start to use the practice of continuous deployment. This means that every code change that passes automated testing goes into the production environment with the feature flag off. Teams can then deploy small changes with low risk and release on demand.\nTo make this possible, teams often start using tools like Flagsmith and feature flags. They can then continuously deploy and easily enable or turn off features, the developer experience improves exponentially and things start to get released much faster.\nWhen teams can continuously deploy, they will inevitably adopt other modern software development practices and engineering practices as well. This means things like introducing test-driven development, separating deployment, canary releases, A/B-testing, dark releases, etc.\nThis is what it starts to look like:\nLooking Ahead: The Future Development for Processes in Banks # The journey to modern software development is a vital process for banks looking to compete in today\u0026rsquo;s dynamic market where adapting modern techniques lets teams higher efficiency, value, and customer satisfaction. When they can overcome the resistance tied to legacy systems and regulations, banks can leverage the advantages of continuous deployment and use feature flags to transform their development processes.\nThis transition is not just about cutting costs or speeding up development; it\u0026rsquo;s about creating a more agile, responsive, and innovative banking landscape that meets the ever-evolving needs of the customers. The pathways to modernization may vary, but the goal remains the same: a future where banks are more adaptable, efficient, and tuned in to the market\u0026rsquo;s demands.\nRead More About Modern Development Processes # Rob Moffat (FINOS) on open source in banking Back to the Future of Software Development Decoupling deployment from release with feature flags Original blogpost: Modern Software Development with Romano Roth (Zühlke) | Flagsmith\n","date":"2 August 2023","externalUrl":null,"permalink":"/en/blogs/moving-to-modern-software-development-and-continuous-integration-for-banks-insights-from-romano/","section":"Blogs","summary":"By Anna Redbond and Romano Roth on August 2, 2023\nA lot of banks are moving to modern software development despite the traditional industry hurdles like compliance, regulations, and legacy architecture. The shared goal: becoming more adaptable to meet customers’ changing demands.\n","title":"Moving to Modern Software Development and Continuous Integration for Banks: Insights from Romano","type":"blogs"},{"content":"Von Anna Redbond und Romano Roth am 2. August 2023\nViele Banken bewegen sich trotz traditioneller Branchenhürden wie Compliance, Regulierungen und Legacy-Architektur in Richtung moderner Softwareentwicklung. Das gemeinsame Ziel: anpassungsfähiger zu werden, um die sich verändernden Anforderungen der Kunden zu erfüllen.\nWir haben uns mit Romano Roth, Chief of DevOps bei Zühlke, zusammengesetzt, der seine Einsichten darüber teilte, wie grosse Banken zu modernen Softwareentwicklungsprozessen übergehen und Features schneller auf den Markt bringen. Er behandelt die Debatte zwischen dem Wechsel in die Cloud und der On-Premises-Entwicklung, Continuous Integration und wie Teams sich von Legacy-Architektur lösen können.\nWas veranlasst Banken, mit der Modernisierung der Softwareentwicklung zu beginnen? # Drei Hauptfaktoren treiben den Wandel an:\nSchnellere Time-to-Market Mehr Wert für investiertes Geld Kundenzufriedenheit Es beginnt oft damit, dass Ineffizienzen bemerkt werden. Management und Teams stellen fest, dass sie viel zahlen und lange auf einfache Änderungen warten. Die Legacy-Prozesse, -Mindsets, -Infrastrukturen, -Tools, -Organisationen und -Regulierungen stehen im Weg und sorgen dafür, dass die Dinge langsamer vorangehen, als die Teams es sich wünschen.\nDies macht die Entwicklung von Produkten und Dienstleistungen ziemlich teuer, und Teams können viel Zeit und Geld investieren müssen, um selbst einfache Dinge umzusetzen.\nModernisierung der Entwicklungsprozesse # Die Lösung besteht meist darin, den gesamten Entwicklungsprozess zu modernisieren, was die Migration der Entwicklung in die Cloud oder die Adoption eines hybriden Ansatzes mit On-Premises-Deployments umfassen kann.\nEntwicklung in der Cloud # Teams können den gesamten Entwicklungsansatz nach hinten herausverlagern, sodass sie in der Cloud mit modernen Tools und modernen Ansätzen entwickeln. Das bedeutet, dass sie sich keine Sorgen um die internen Regulierungen der Bank machen müssen.\nDies erfordert allerdings eine, möglicherweise erhebliche, Investition. Es gibt andere Optionen, aber wenn Teams investieren, können ihre Entwicklungsprozesse etwa 25 % schneller laufen.\nEs gibt allerdings oft massiven Widerstand gegen den Wechsel in die Cloud, besonders von den Personen, die die internen Legacy-Infrastrukturen und -Anwendungen aufgebaut, betrieben und gewartet haben. Es gibt auch Widerstand auf der Sicherheitsseite, weil es einfacher erscheint, Sicherheitsbeschränkungen on-premises als in der Cloud umzusetzen. Schliesslich müssen Teams vertrauliche Daten entfernen und synthetische Testdaten verwenden (was viele argumentieren würden, sie hätten ohnehin schon längst tun sollen).\nEin hybrider Ansatz: Aussen entwickeln und on-premises deployen # Eine Lösung im Falle vertraulicher Daten ist, die Software ausserhalb zu entwickeln und den Quellcode oder kompilierten Code in die Bank zu bringen und ihn in die On-Premises-Infrastruktur zu deployen. So läuft sie on-premises (und erfüllt die Sicherheitsanforderungen und Regulierungen), während die Entwicklung ausserhalb stattfindet.\nProdukte schneller auf den Markt bringen # Effizienz ist eine der wichtigsten Sachen, die Teams bemerken, wenn sie ihre Prozesse zu modernisieren beginnen. Unternehmen erhalten schlicht mehr Wert für ihr Geld.\nWas ebenfalls passiert, ist eine schnellere Time-to-Market, was üblicherweise der Business-Treiber ist. Wenn die Entwicklung zu langsam und kostspielig war und die Developer Experience nicht gut funktionierte, dann ist es immer eine gute Sache, dies zu ändern und Produkte schneller auf den Markt zu bringen.\nHier beginnen Teams, die Praxis des Continuous Deployments zu nutzen. Das bedeutet, dass jede Codeänderung, die automatisierte Tests besteht, mit deaktiviertem Feature Flag in die Produktionsumgebung geht. Teams können dann kleine Änderungen mit geringem Risiko deployen und nach Bedarf releasen.\nUm dies zu ermöglichen, beginnen Teams oft, Tools wie Flagsmith und Feature Flags zu verwenden. Sie können dann kontinuierlich deployen und Features einfach aktivieren oder deaktivieren, die Developer Experience verbessert sich exponentiell und Dinge werden viel schneller released.\nWenn Teams kontinuierlich deployen können, werden sie unweigerlich auch andere moderne Softwareentwicklungs- und Engineering-Praktiken übernehmen. Das bedeutet Dinge wie die Einführung von Test-Driven Development, die Trennung von Deployment, Canary Releases, A/B-Testing, Dark Releases usw.\nSo sieht es dann aus:\nAusblick: Die Zukunft der Entwicklungsprozesse in Banken # Die Reise zur modernen Softwareentwicklung ist ein vitaler Prozess für Banken, die im heutigen dynamischen Markt mithalten wollen, in dem die Adoption moderner Techniken Teams höhere Effizienz, Wert und Kundenzufriedenheit ermöglicht. Wenn sie den Widerstand überwinden können, der mit Legacy-Systemen und Regulierungen verbunden ist, können Banken die Vorteile von Continuous Deployment nutzen und Feature Flags einsetzen, um ihre Entwicklungsprozesse zu transformieren.\nDieser Übergang dreht sich nicht nur um Kostensenkung oder die Beschleunigung der Entwicklung; es geht darum, eine agilere, reaktionsfähigere und innovativere Bankenlandschaft zu schaffen, die den sich ständig wandelnden Bedürfnissen der Kunden gerecht wird. Die Wege zur Modernisierung mögen variieren, aber das Ziel bleibt dasselbe: eine Zukunft, in der Banken anpassungsfähiger, effizienter und auf die Anforderungen des Marktes eingestimmt sind.\nMehr über moderne Entwicklungsprozesse lesen # Rob Moffat (FINOS) on open source in banking Back to the Future of Software Development Decoupling deployment from release with feature flags Originaler Blogpost: Modern Software Development with Romano Roth (Zühlke) | Flagsmith\n","date":"2. August 2023","externalUrl":null,"permalink":"/de/blogs/moderne-softwareentwicklung-continuous-integration-fuer-banken-insights-romano/","section":"Blogs","summary":"Von Anna Redbond und Romano Roth am 2. August 2023\nViele Banken bewegen sich trotz traditioneller Branchenhürden wie Compliance, Regulierungen und Legacy-Architektur in Richtung moderner Softwareentwicklung. Das gemeinsame Ziel: anpassungsfähiger zu werden, um die sich verändernden Anforderungen der Kunden zu erfüllen.\n","title":"Übergang zu moderner Softwareentwicklung und Continuous Integration für Banken: Insights von Romano","type":"blogs"},{"content":"","date":"20 July 2023","externalUrl":null,"permalink":"/en/tags/best-practices/","section":"Tags","summary":"","title":"Best Practices","type":"tags"},{"content":" I had the honor of being interviewed by 📈 Matt Warcholinski 💾 from Brainhub in his 𝐏𝐨𝐝𝐜𝐚𝐬𝐭🎙️ on 𝐁𝐞𝐭𝐭𝐞𝐫 𝐓𝐞𝐜𝐡 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩.\n🔎 If you\u0026rsquo;ve ever wondered about the ins and outs of introducing 𝐃𝐞𝐯𝐎𝐩𝐬 into your organization, this episode is a must-listen! We delved into some fascinating topics, and I\u0026rsquo;m thrilled to share a few highlights from our conversation:\n🛑 Avoiding the 𝐁𝐢𝐠𝐠𝐞𝐬𝐭 𝐌𝐢𝐬𝐭𝐚𝐤𝐞𝐬: We discussed some common pitfalls organizations encounter when implementing DevOps and how to steer clear of them. Learning from mistakes is key to ensuring a smooth DevOps journey!\n💪 Overcoming 𝐂𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞𝐬 with DevOps: DevOps isn\u0026rsquo;t without its challenges, but fear not! We explored the various roadblocks that may arise and how DevOps can help your teams tackle them head-on.\n💡 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 from a 𝐁𝐮𝐬𝐢𝐧𝐞𝐬𝐬 Perspective: Understanding DevOps from a business standpoint is vital. Matt and I explored how aligning DevOps with your business objectives can lead to enhanced productivity and innovation.\nSo, if you\u0026rsquo;re eager to supercharge your organization\u0026rsquo;s software delivery, enhance collaboration, and boost your team\u0026rsquo;s overall efficiency, this podcast episode is a goldmine of valuable information! 💎\nYouTube # Spotify # ","date":"20 July 2023","externalUrl":null,"permalink":"/en/blogs/d-for-devops-the-philosophy-of-software-engineering/","section":"Blogs","summary":" I had the honor of being interviewed by 📈 Matt Warcholinski 💾 from Brainhub in his 𝐏𝐨𝐝𝐜𝐚𝐬𝐭🎙️ on 𝐁𝐞𝐭𝐭𝐞𝐫 𝐓𝐞𝐜𝐡 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩.\n🔎 If you’ve ever wondered about the ins and outs of introducing 𝐃𝐞𝐯𝐎𝐩𝐬 into your organization, this episode is a must-listen! We delved into some fascinating topics, and I’m thrilled to share a few highlights from our conversation:\n","title":"D for DevOps: The Philosophy of Software Engineering","type":"blogs"},{"content":" Ich hatte die Ehre, von 📈 Matt Warcholinski 💾 von Brainhub in seinem 𝐏𝐨𝐝𝐜𝐚𝐬𝐭🎙️ 𝐁𝐞𝐭𝐭𝐞𝐫 𝐓𝐞𝐜𝐡 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩 interviewt zu werden.\n🔎 Falls Sie sich jemals gefragt haben, was bei der Einführung von 𝐃𝐞𝐯𝐎𝐩𝐬 in Ihrer Organisation alles zu beachten ist, dann ist diese Episode ein Muss! Wir haben einige faszinierende Themen besprochen, und ich freue mich, einige Highlights aus unserem Gespräch zu teilen:\n🛑 Die 𝐠𝐫öß𝐭𝐞𝐧 𝐅𝐞𝐡𝐥𝐞𝐫 vermeiden: Wir haben häufige Stolperfallen besprochen, auf die Organisationen bei der Einführung von DevOps stoßen, und wie man sie umgehen kann. Aus Fehlern zu lernen ist der Schlüssel für eine erfolgreiche DevOps-Reise!\n💪 𝐇𝐞𝐫𝐚𝐮𝐬𝐟𝐨𝐫𝐝𝐞𝐫𝐮𝐧𝐠𝐞𝐧 mit DevOps meistern: DevOps kommt nicht ohne Herausforderungen, aber keine Sorge! Wir haben die verschiedenen Hindernisse untersucht, die auftreten können, und wie DevOps Ihren Teams hilft, diese direkt anzugehen.\n💡 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 aus 𝐆𝐞𝐬𝐜𝐡ä𝐟𝐭𝐬𝐬𝐢𝐜𝐡𝐭: DevOps aus einer geschäftlichen Perspektive zu verstehen ist entscheidend. Matt und ich haben untersucht, wie die Ausrichtung von DevOps an Ihren Geschäftszielen zu höherer Produktivität und Innovation führen kann.\nWenn Sie also die Softwarelieferung Ihrer Organisation auf das nächste Level bringen, die Zusammenarbeit verbessern und die Gesamteffizienz Ihres Teams steigern möchten, ist diese Podcast-Episode eine Fundgrube wertvoller Informationen! 💎\nYouTube # Spotify # ","date":"20. July 2023","externalUrl":null,"permalink":"/de/blogs/d-wie-devops-die-philosophie-des-software-engineering/","section":"Blogs","summary":" Ich hatte die Ehre, von 📈 Matt Warcholinski 💾 von Brainhub in seinem 𝐏𝐨𝐝𝐜𝐚𝐬𝐭🎙️ 𝐁𝐞𝐭𝐭𝐞𝐫 𝐓𝐞𝐜𝐡 𝐋𝐞𝐚𝐝𝐞𝐫𝐬𝐡𝐢𝐩 interviewt zu werden.\n🔎 Falls Sie sich jemals gefragt haben, was bei der Einführung von 𝐃𝐞𝐯𝐎𝐩𝐬 in Ihrer Organisation alles zu beachten ist, dann ist diese Episode ein Muss! Wir haben einige faszinierende Themen besprochen, und ich freue mich, einige Highlights aus unserem Gespräch zu teilen:\n","title":"D wie DevOps: Die Philosophie des Software Engineering","type":"blogs"},{"content":"","date":"20 July 2023","externalUrl":null,"permalink":"/en/tags/mindset/","section":"Tags","summary":"","title":"Mindset","type":"tags"},{"content":"","date":"20. July 2023","externalUrl":null,"permalink":"/de/tags/philosophie/","section":"Tags","summary":"","title":"Philosophie","type":"tags"},{"content":"","date":"20 July 2023","externalUrl":null,"permalink":"/en/tags/philosophy/","section":"Tags","summary":"","title":"Philosophy","type":"tags"},{"content":"An der DEVOPS Conference habe ich über ein Thema gesprochen, das seit über zwei Jahrzehnten im Mittelpunkt meiner Arbeit steht: Wie man die Architektur für Continuous Delivery gestaltet. Dieser Vortrag behandelt den kaputten Wertstrom, den ich in den meisten Unternehmen sehe, warum Produktdenken wichtiger ist als Projektdenken, die Wissenschaft hinter der Software-Delivery-Performance und wie Platform Engineering es Organisationen ermöglicht, DevOps durch digitale Fabriken zu skalieren.\nDer kaputte Wertstrom # Wenn ich Unternehmen besuche, sehe ich immer wieder dasselbe Muster. Das Business und die Kunden haben gute Ideen. Sie schreiben diese Ideen in Word-Dokumente und Jira-Tickets. Dann werfen sie sie über die Mauer der Verwirrung zum Entwicklungsteam. Das Entwicklungsteam sagt „klar, das können wir umsetzen\u0026quot; und wirft das Ergebnis zum QA-Team. QA sagt „passt nicht zu den Anforderungen, aber es ist grün\u0026quot; und wirft es zum Betrieb. Der Betrieb sagt „wie sollen wir das betreiben?\u0026quot; und schafft es irgendwie, es zum Laufen zu bringen. Dann schaut das Business auf das Ergebnis und sagt: „Was ist das? Das löst unser Problem nicht.\u0026quot;\nDieses Bild wird angetrieben von Silo-Organisationen mit unterschiedlichen Zielen, einem vollständigen Mangel an Abstimmung und einem Mangel an Software-Engineering-Exzellenz. Die Erfahrung für alle Beteiligten ist schlecht.\nVon Waterfall über Agile zu Produkten # Um die Wurzel dieses Problems zu verstehen, müssen wir in die Geschichte schauen. Zuerst hatten wir Waterfall, wo wir grosse Softwarepakete planten, designten, entwickelten, testeten und deployten. Zeit, Umfang und Budget waren fix. Viele Projekte scheiterten.\nDann sagten kluge Leute „gehen wir agil vor\u0026quot; und liefern in kleineren Inkrementen. Zeit und Budget sind fix, der Umfang ist variabel. Das war eine sehr gute Verbesserung. Aber wir arbeiteten immer noch in Projekten.\nDer entscheidende Wandel ist der Wechsel von Projekten zu Produkten. Ein Projekt hat einen Anfang und ein Ende, einen Satz Ressourcen und ein Lieferergebnis. Es fokussiert auf den Output: Maximierung der Anzahl von Features. Ein Produkt fokussiert auf das Ergebnis: das Problem des Kunden lösen. Den Kunden interessieren keine zehn Features. Er interessiert sich für das eine Feature, das sein Problem löst.\n„DevOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken, die Kommunikation, Integration, Automatisierung und enge Zusammenarbeit aller Menschen ermöglicht, die nötig sind, um ein Produkt zu planen, entwickeln, testen, deployen, releasen und zu warten.\u0026quot;\nDie Wissenschaft: Accelerate und die DORA-Metriken # Das Buch Accelerate hat wissenschaftlich untersucht, warum manche Unternehmen hervorragend darin sind, Produkte zu erstellen, während andere scheitern. Es wurden 24 Schlüsselfähigkeiten identifiziert, organisiert in technische Praktiken, Kultur und Mindset, die die Software-Delivery-Performance antreiben.\nDie DORA-Metriken sind der wissenschaftlich bewiesene Weg, diese Performance zu messen:\nLead Time for Changes: Vom Code-Commit bis zur Produktion. Elite schafft das in weniger als einer Stunde. Deployment Frequency: Wie oft man deployt. Elite deployt auf Abruf, mehrmals täglich. Das Schlüsselprinzip: Deployment (Code in Produktion mit Feature Toggle aus) ist nicht dasselbe wie Release (Toggle ein). Time to Restore Service: Wie schnell man sich von einem Fehler erholt. Elite schafft das in weniger als einer Stunde. Change Failure Rate: Prozentsatz der Deployments, die Fehler verursachen. Elite liegt bei 0 bis 15 %. Die State-of-DevOps-Berichte zeigen den Unterschied zwischen Low-Performern und Elite-Performern: 208x häufigere Deployments, 106x schnellere Lead Time, 2604x schnellere Wiederherstellung und 7x niedrigere Change Failure Rate. Die Vorteile sind klar: schnellere Time to Market, mehr Wert für das Geld, höhere Qualität und höhere Kundenzufriedenheit.\nDie Herausforderung der DevOps-Skalierung # Wenn Unternehmen DevOps skalieren wollen, ist ein häufiger Fehler, ein „DevOps-Team\u0026quot; zu erstellen, das nur ein weiteres Silo ist. Der richtige Ansatz ist, Entwicklung und Betrieb in crossfunktionalen Produkt-Teams zusammenzubringen.\nAber dann erfindet jedes Team das Rad neu. Es gibt Inkonsistenz, Redundanz, mangelnde Betriebserfahrung und enorme Komplexität bei den Tools. Wenn man sich eine Continuous-Delivery-Pipeline anschaut, gibt es eine enorme Menge an Tooling, und alle diese Tools müssen zusammenarbeiten und gewartet werden.\nSelbst Plattformen wie GitLab, GitHub und Azure DevOps decken nicht alles ab. Man muss trotzdem Komponenten ersetzen oder ergänzen. Die kognitive Last für die Teams ist hoch. Das Onboarding dauert Monate. Die Bereitstellung einer neuen Datenbank oder eines Kubernetes-Clusters dauert Monate. Es fehlt an Standardisierung, und das Ergebnis ist langsame Time to Market und niedrige Qualität.\nPlatform Engineering: Der Enabler # Die Lösung ist Platform Engineering. Das Zielbild ist eine digitale Fabrik mit einem Fliessband der Automatisierung, wo Teams sich auf die eigentliche Arbeit konzentrieren können.\nDie Organisationsarchitektur sieht so aus: Produkt-Teams fokussieren sich auf das Bauen, Betreiben und Warten ihrer Produkte. Das Plattform-Team stellt die Plattform bereit. Das Plattform-Team ist kein weiteres Silo. Es ist ein Produkt-Team, dessen Kunden die anderen Produkt-Teams sind.\nDas Plattform-Team baut die CI/CD-Pipeline, die API-Entkopplungsschicht, die Kubernetes-Infrastruktur, die synthetischen Testdaten und alles andere, was die Produkt-Teams brauchen. Die Produkt-Teams nutzen diese Plattform, um DevOps zu praktizieren.\n„Das Plattform-Team schafft Wert für die Teams. Die Produkt-Teams schaffen Wert für den Kunden. Platform Engineering ermöglicht es Produkt-Teams, DevOps zu betreiben.\u0026quot;\nSo gestaltet man die Architektur für kontinuierliche Wertlieferung. So reduziert man die kognitive Last. Und so skaliert man DevOps.\nThreat Modeling und Sicherheit # In der Fragerunde fragte jemand, wie man Threat Modeling in CI/CD integriert. Meine Antwort: Man muss die Architektur auf Sicherheit ausrichten, genauso wie man sie auf Testbarkeit und Betreibbarkeit ausrichtet.\nThreat Modeling funktioniert so: Man versammelt das Team und einen Sicherheitsexperten in einem Raum. Man zeichnet das Kontextdiagramm der Applikation. Man identifiziert die Angriffsvektoren und Bedrohungen. Man definiert Massnahmen, nimmt sie ins Backlog auf, implementiert sie und testet sie in der Pipeline. Man integriert Container Scanning, Software Composition Analysis, Dependency Scanning und SAST. In der Produktion überwacht man kontinuierlich auf Angriffe.\nKernaussagen # Reisse die Mauern der Verwirrung ein. Organisiere dich entlang des Wertstroms, nicht in Silos. Denke in Produkten, nicht in Projekten. Fokussiere dich auf das Ergebnis für den Kunden, nicht auf den Output für die Organisation. Nutze die DORA-Metriken. Sie sind der wissenschaftlich bewiesene Weg, Software-Delivery-Performance zu messen. Baue digitale Fabriken. Schaffe Fliessbänder der Automatisierung, die kontinuierliche Wertlieferung ermöglichen. Investiere in Platform Engineering. Das Plattform-Team ermöglicht es Produkt-Teams, DevOps zu betreiben, indem es die kognitive Last reduziert und standardisierte Self-Service-Fähigkeiten bereitstellt. Gestalte die Architektur auf Sicherheit. Nutze Threat Modeling und Shift-Left-Security-Praktiken, um deine Applikationen von Anfang an zu schützen. ","date":"6. July 2023","externalUrl":null,"permalink":"/de/blogs/architektur-fuer-continuous-delivery-von-silos-zu-digitalen-fabriken/","section":"Blogs","summary":"An der DEVOPS Conference habe ich über ein Thema gesprochen, das seit über zwei Jahrzehnten im Mittelpunkt meiner Arbeit steht: Wie man die Architektur für Continuous Delivery gestaltet. Dieser Vortrag behandelt den kaputten Wertstrom, den ich in den meisten Unternehmen sehe, warum Produktdenken wichtiger ist als Projektdenken, die Wissenschaft hinter der Software-Delivery-Performance und wie Platform Engineering es Organisationen ermöglicht, DevOps durch digitale Fabriken zu skalieren.\n","title":"Architektur für Continuous Delivery: Von Silos zu digitalen Fabriken","type":"blogs"},{"content":"At The DEVOPS Conference, I presented on a topic that has been at the heart of my work for over two decades: how to architect for continuous delivery. This talk covers the broken value stream I see in most companies, why product thinking matters more than project thinking, the science behind software delivery performance, and how platform engineering enables organizations to scale DevOps through digital factories.\nThe Broken Value Stream # When I join companies, I consistently see the same pattern. The business and the clients have bright ideas. They put these ideas into Word documents and Jira tickets. Then they throw them over the wall of confusion to the development team. The development team says \u0026ldquo;sure, we can implement that\u0026rdquo; and throws the result over to the QA team. QA says \u0026ldquo;doesn\u0026rsquo;t match the requirements, but it is green\u0026rdquo; and throws it to operations. Operations says \u0026ldquo;how should we operate that?\u0026rdquo; and somehow manages to get it running. Then the business looks at the result and says: \u0026ldquo;What is that? That does not solve our problem.\u0026rdquo;\nThis picture is driven by silo organizations with different goals, a complete lack of alignment, and a lack of software engineering excellence. The experience for everyone involved is bad.\nFrom Waterfall to Agile to Products # To understand the root of this problem, we need to look at history. First we had waterfall, where we planned, designed, developed, tested, and deployed big chunks of software. Time, scope, and budget were all fixed. Many projects failed.\nThen smart people said \u0026ldquo;let\u0026rsquo;s go agile\u0026rdquo; and deliver in smaller increments. Time and budget are fixed, scope is variable. This was a very good improvement. But we were still working in projects.\nThe shift that matters is from projects to products. A project has a start and end, a set of resources, and a deliverable. It focuses on output: maximizing the number of features. A product focuses on outcome: solving the customer\u0026rsquo;s problem. The customer does not care about ten features. They care about that one feature that solves their problem.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices which provides communication, integration, automation, and close collaboration among all the people needed to plan, develop, test, deploy, release, and maintain a product.\u0026rdquo;\nThe Science: Accelerate and the DORA Metrics # The book Accelerate scientifically examined why some companies excel at creating products while others fail. They identified 24 key capabilities organized into technical practices, culture, and mindset that drive software delivery performance.\nThe DORA metrics are the scientifically proven way to measure this performance:\nLead Time for Changes: From code commit to production. Elite is less than an hour. Deployment Frequency: How often you deploy. Elite deploys on demand, multiple times per day. The key principle: deployment (code in production with feature toggle off) is not the same as release (toggle on). Time to Restore Service: How fast you recover from a failure. Elite is less than an hour. Change Failure Rate: Percentage of deployments causing failure. Elite is 0 to 15%. The State of DevOps reports show the difference between low performers and elite performers: 208x more frequent deployments, 106x faster lead time, 2604x faster time to restore, and 7x lower change failure rate. The benefits are clear: faster time to market, more value for money, higher quality, and higher customer satisfaction.\nThe Challenge of Scaling DevOps # When companies try to scale DevOps, a common mistake is creating a \u0026ldquo;DevOps team,\u0026rdquo; which is just another silo. The correct approach is to bring development and operations together into cross-functional product teams.\nBut then each team reinvents the wheel. There is inconsistency, redundancy, lack of operational experience, and huge complexity in tooling. When you look at a continuous delivery pipeline, there is an enormous amount of tooling, and all those tools need to work together and be maintained.\nEven platforms like GitLab, GitHub, and Azure DevOps do not cover everything. You still need to replace or add components. The cognitive load on teams is high. Onboarding takes months. Provisioning a new database or Kubernetes cluster takes months. There is a real lack of standardization, and the result is slow time to market and low quality.\nPlatform Engineering: The Enabler # The solution is platform engineering. The target picture is a digital factory with a conveyor belt of high automation, where teams can focus on the real work.\nThe organizational architecture looks like this: product teams focus on building, running, and maintaining their products. The platform team provides the platform. The platform team is not another silo. They are a product team whose customers are the other product teams.\nThe platform team builds the CI/CD pipeline, the API decoupling layer, the Kubernetes infrastructure, the synthetic test data, and everything else the product teams need. The product teams use this platform to practice DevOps.\n\u0026ldquo;The platform team generates value for the teams. The product teams generate value for the customer. Platform engineering enables product teams to do DevOps.\u0026rdquo;\nThis is how you architect for continuous value delivery. This is how you reduce cognitive load. And this is how you scale DevOps.\nThread Modeling and Security # During the Q\u0026amp;A, someone asked about integrating thread modeling into CI/CD. My answer: you need to architect for security, just as you architect for testability and operability.\nThread modeling works like this: gather your team and a security expert in a room. Draw the context diagram of your application. Identify the attack vectors and threats. Define mitigations, put them on the backlog, implement them, and test them in your pipeline. Include container scanning, software composition analysis, dependency scanning, and SAST. In production, continuously monitor for attacks.\nKey Takeaways # Break down the walls of confusion. Organize across the value stream, not in silos. Think in products, not projects. Focus on outcome for the customer, not output for the organization. Use the DORA metrics. They are the scientifically proven way to measure software delivery performance. Build digital factories. Create conveyor belts of automation that enable continuous value delivery. Invest in platform engineering. The platform team enables product teams to do DevOps by reducing cognitive load and providing standardized, self-service capabilities. Architect for security. Use thread modeling and shift-left security practices to protect your applications from the start. ","date":"6 July 2023","externalUrl":null,"permalink":"/en/blogs/how-to-architect-for-continuous-delivery-the-devops-conference/","section":"Blogs","summary":"At The DEVOPS Conference, I presented on a topic that has been at the heart of my work for over two decades: how to architect for continuous delivery. This talk covers the broken value stream I see in most companies, why product thinking matters more than project thinking, the science behind software delivery performance, and how platform engineering enables organizations to scale DevOps through digital factories.\n","title":"How to Architect for Continuous Delivery: From Silos to Digital Factories","type":"blogs"},{"content":"","date":"26. June 2023","externalUrl":null,"permalink":"/de/tags/schweiz/","section":"Tags","summary":"","title":"Schweiz","type":"tags"},{"content":"","date":"26 June 2023","externalUrl":null,"permalink":"/en/tags/state-of-devops/","section":"Tags","summary":"","title":"State of DevOps","type":"tags"},{"content":"At the State of DevOps in Switzerland 2023 event, I joined Adrian Kosmaczewski from VSHN to present the latest findings on DevOps adoption in the Swiss market. Adrian shared four years of survey data, while I focused on how to successfully scale DevOps through platform engineering and the concept of the digital factory. This event brought together DevOps professionals both on-site and virtually for presentations and a lively panel discussion.\nFour Years of DevOps Data in Switzerland # Adrian kicked things off with a summary of the State of DevOps Report Switzerland, now in its fourth edition since 2020. The data paints a clear picture: DevOps in Switzerland is here to stay. Around 85% of respondents consistently report positive experiences with DevOps, and adoption continues to grow year over year.\nThe technology landscape shows strong trends. Linux dominates production environments. Python, Java, JavaScript, Go, and C# remain the top five programming languages. Container technology has reached over 84% adoption. Kubernetes has clearly won the orchestration battle, with Red Hat OpenShift 4 leading as the most popular distribution, followed by managed Kubernetes offerings like AKS, EKS, and GKE.\n\u0026ldquo;DevOps in Switzerland is here to stay. Companies are applying DevOps, they\u0026rsquo;re very happy with it, and the perception of DevOps is really good on the Swiss market.\u0026rdquo; — Adrian Kosmaczewski\nAn interesting finding: Microsoft Azure remains the leading cloud provider in Switzerland, though AWS is showing strong growth after establishing a Swiss region. The CI/CD tooling landscape is dominated by Terraform, GitLab, GitHub, Ansible, and Jenkins, with ArgoCD emerging as a rising star that Adrian predicted would break into the top five.\nWhy DevOps Matters: From Projects to Products # In my presentation, I shared the challenge I see repeatedly when joining companies: the broken value stream. Business teams throw requirements over a wall of confusion to developers, who throw code over to testers, who hand off to operations, and the final result disappoints everyone. These walls of confusion come from silo organizations and a lack of alignment.\nThe root cause often lies in the project mindset. Projects have fixed start and end dates, fixed budgets, and focus on maximizing output: the number of features delivered. Products, on the other hand, focus on understanding the customer, solving their problems, and achieving real outcomes. DevOps supports this product mindset by aligning the entire organization around the value stream.\nThe science backs this up. The DORA metrics from the Accelerate research show that elite DevOps performers achieve 208 times more frequent deployments, 106 times faster lead times, 2,604 times faster recovery from failures, and 7 times lower change failure rates. And these numbers continue to accelerate.\nScaling DevOps with Platform Engineering # While doing DevOps in a single team is already challenging, scaling it across an organization is even harder. About 50% of Swiss companies have combined Dev and Ops teams, but many still struggle with the cognitive load this creates. New team members often take one to three months just to get access to all tools and become productive.\nThe solution I presented is platform engineering. Instead of each product team building and maintaining their own tooling, you create a dedicated platform team that provides a shared foundation: API gateways, CI/CD pipelines, Kubernetes clusters, repositories, synthetic test data, and everything else teams need to be productive.\n\u0026ldquo;The platform team creates a product which is consumed by the product teams. With platform engineering, you are building a platform which is the foundation of your digital factory.\u0026rdquo;\nThis is not about creating another silo. The platform team delivers a product that enables product teams to focus on what they do best: building features for their customers. It is the industrialization of software development, automating the boring stuff so developers can focus on real value creation.\nDevOps Adoption Challenges in Switzerland # The panel discussion surfaced important challenges specific to the Swiss market. Switzerland has a historically hierarchical culture, which can clash with the cross-functional, autonomous teams that DevOps requires. When you break down silos and create product teams, some management positions become redundant, which creates resistance.\nAdrian made a powerful point about trust: \u0026ldquo;You hired these people to solve problems that you don\u0026rsquo;t know how to solve. If you hire somebody, just trust them.\u0026rdquo; This trust enables the processes, the people, and the technology choices that make DevOps successful.\nWe also discussed the common misconception that speed alone is the goal. As I emphasized, you can deploy faster and still deliver the wrong thing. The real goal is solving customer problems, and faster delivery simply shortens the feedback loop so you can learn and adapt more quickly.\nReal-World Business Value # I shared a concrete example from a private bank where we moved the entire development environment from slow, painful virtual machines inside the bank to the cloud. This required removing confidential data from source code, creating synthetic test data, and building simulators for interfaces. The result: a 25% improvement in delivery speed, the ability to hire distributed teams, and eventually reducing deployment cycles from three months to two weeks. The risk dropped dramatically, and the organization could finally deliver continuous value.\nKey Takeaways # DevOps in Switzerland is firmly established with 85% positive perception and growing adoption across all company sizes and industries. Container technology and Kubernetes have become standard, with over 84% adoption and managed Kubernetes offerings growing strongly. Platform engineering is the key to scaling DevOps by reducing cognitive load on product teams and providing a shared foundation for continuous delivery. The shift from projects to products is essential for unlocking the real benefits of DevOps, focusing on outcomes rather than output. Trust and cultural change are the hardest parts of DevOps adoption, especially in Switzerland\u0026rsquo;s traditionally hierarchical organizations. Science proves DevOps works: elite performers dramatically outperform others on all four DORA metrics, and these gaps continue to widen. ","date":"26 June 2023","externalUrl":null,"permalink":"/en/blogs/state-of-devops-in-switzerland-2023/","section":"Blogs","summary":"At the State of DevOps in Switzerland 2023 event, I joined Adrian Kosmaczewski from VSHN to present the latest findings on DevOps adoption in the Swiss market. Adrian shared four years of survey data, while I focused on how to successfully scale DevOps through platform engineering and the concept of the digital factory. This event brought together DevOps professionals both on-site and virtually for presentations and a lively panel discussion.\n","title":"State of DevOps in Switzerland 2023: Key Insights and How to Scale DevOps","type":"blogs"},{"content":"","date":"26 June 2023","externalUrl":null,"permalink":"/en/tags/switzerland/","section":"Tags","summary":"","title":"Switzerland","type":"tags"},{"content":"","date":"20 June 2023","externalUrl":null,"permalink":"/en/tags/github-copilot/","section":"Tags","summary":"","title":"GitHub Copilot","type":"tags"},{"content":"GitHub Copilot is reshaping software development by introducing AI-assisted coding into everyday engineering work. But what does this mean in practice?\nWhat This Talk Covers # This presentation explains what GitHub Copilot is, how it works in practice, and how it supports developers through context-aware code suggestions, faster problem-solving, and reduced effort for repetitive tasks.\nKey Messages # 1. AI-Assisted Coding in Practice GitHub Copilot provides context-aware code suggestions that help developers write code faster, solve problems more efficiently, and reduce the effort spent on repetitive tasks.\n2. Benefits and Concerns Key benefits include improved productivity, faster task completion, and a better developer experience. At the same time, important concerns around trust, accuracy, and the need for human review must be addressed.\n3. The Future of AI in Software Engineering The broader impact of AI on coding, debugging, DevOps, and software engineering as a whole will not eliminate developers, but instead increase the importance of creativity, critical thinking, and strong problem-solving skills.\n","date":"20 June 2023","externalUrl":null,"permalink":"/en/speaking/github-copilot-hackathon/","section":"Speaking","summary":"GitHub Copilot is reshaping software development by introducing AI-assisted coding into everyday engineering work. But what does this mean in practice?\nWhat This Talk Covers # This presentation explains what GitHub Copilot is, how it works in practice, and how it supports developers through context-aware code suggestions, faster problem-solving, and reduced effort for repetitive tasks.\n","title":"GitHub Copilot Hackathon: How AI-Powered Coding Changes Software Development","type":"speaking"},{"content":"","date":"13 June 2023","externalUrl":null,"permalink":"/en/tags/github/","section":"Tags","summary":"","title":"GitHub","type":"tags"},{"content":"","date":"13 June 2023","externalUrl":null,"permalink":"/en/tags/github-actions/","section":"Tags","summary":"","title":"GitHub Actions","type":"tags"},{"content":"After eleven sessions building a full DevSecOps pipeline with GitHub — covering Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines, and Vulnerability Management — Patrick Steger and I close the series with our recommendations. What works on GitHub, where the gaps are, and what we would tell anyone setting out to build the same pipeline.\nStructure Workflows Hierarchically # The first thing we would recommend is to structure your workflows top-down. Build a main pipeline workflow that orchestrates smaller, single-purpose workflows — one for Build, one for SCA, one for SAST, and so on. Each sub-workflow does one thing well, and the main pipeline composes them. This is much easier to maintain over time than one giant YAML file. When something breaks or needs to change, you fix it in one small workflow and every pipeline that consumes it picks up the fix.\nDefine Branches and Schedules Explicitly # You need to be explicit about which workflow runs on which branch. You can — and often should — have different pipelines for different branches. And you must schedule your pipelines. Here is why: your pipeline normally only runs when something changes, but the application sitting in production does not change every day. New vulnerabilities are disclosed daily. Without a scheduled pipeline you will never re-scan production code, and you will never catch the vulnerabilities that surfaced after the last commit. Setting the default branch in GitHub is straightforward — Settings, General, default branch — but the scheduled pipeline is what keeps production protected.\nPull Requests as the Security Gate # Pull Requests work well for surfacing newly introduced security issues. Wire your security workflows into every PR, and define a review and approval process for what happens when a critical vulnerability shows up. Combine that with branch protection rules to actually enforce it. In Settings → Branches you can define a rule (we use * to apply it to all branches) that requires reviews, status checks, and whatever else you need before a merge can happen. Without branch protection, all your PR gating is theatre.\nSecurity-Review Marketplace Actions # This one matters in confidential and enterprise contexts. Anything you pull from the GitHub Marketplace is community-provided code running inside your pipeline with access to your secrets and source. Review what you are using. In the best case, fork it into your own repository and manage it from there so you control updates and can audit changes. Treat marketplace actions like any other third-party dependency — because that is what they are.\nSecret Management: Use Azure Key Vault # For secrets, the GitHub secret store is the baseline. It works. But if you want a better solution, use Azure Key Vault. The integration is excellent and you get advanced management capabilities — rotation, access policies, audit logs — that the built-in store does not provide. Other key vaults work too, but the Azure integration stands out.\nYou Will Have to Choose Your Security Tools # Unlike GitLab, GitHub does not ship a default set of security scanners. That means you have to evaluate and pick what fits your stack. The upside is freedom; the downside is the work. Our previous episodes walked through specific candidates for SCA, SAST, Container Scanning, Secret Detection, and DAST — start there if you want a shortlist.\nWhen you get to DAST specifically, customize the scanner configuration. An uncustomized DAST scan barely scratches the surface. Without authentication, crawl rules, and input definitions, the scanner cannot exercise the application meaningfully and the benefit is very limited.\nThe Vulnerability Management Gap # Even a small Java project produces a lot of findings. Managing those findings is essential. GitHub\u0026rsquo;s Vulnerability Management is okay — you can work with it — but there is a real gap: you cannot create your own findings. If your pen-tester finds a vulnerability that the automated scanners did not, you cannot record it in GitHub\u0026rsquo;s Vulnerability Management. That limits the platform significantly. Our recommendation, unfortunately, is to plan for an external Vulnerability Management tool.\nBring a Security Expert into the Team # Like with GitLab, our final recommendation is the same: add a security expert to the team. You will have a lot of findings, you have to configure each tool correctly, and you have to make sense of what comes out. That requires expertise. Without it, the pipeline either drowns the team in noise or quietly lets real issues through.\nKey Takeaways # Compose small workflows into big ones. A main pipeline that orchestrates focused sub-workflows (Build, SCA, SAST, etc.) is far easier to maintain than one monolithic YAML.\nSchedule pipelines to protect production code. Code in production stops getting scanned the day commits stop. Scheduled runs keep it covered against newly disclosed vulnerabilities.\nPull Requests plus branch protection are your gate. PRs surface issues; branch protection rules enforce that the gate is actually closed.\nMarketplace actions are third-party code. Review them, ideally fork into your own repo and manage updates yourself — especially in enterprise contexts.\nUse Azure Key Vault for serious secret management. GitHub\u0026rsquo;s built-in secret store works; Azure Key Vault integrates cleanly and gives you the management capabilities you eventually need.\nGitHub Vulnerability Management has a real gap. You cannot add your own findings. Plan for an external Vulnerability Management tool, and bring a security expert onto the team.\n","date":"13 June 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-recommendations/","section":"Blogs","summary":"After eleven sessions building a full DevSecOps pipeline with GitHub — covering Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines, and Vulnerability Management — Patrick Steger and I close the series with our recommendations. What works on GitHub, where the gaps are, and what we would tell anyone setting out to build the same pipeline.\n","title":"GitHub DevSecOps Part 12: Our Recommendations and Lessons Learned","type":"blogs"},{"content":"","date":"13 June 2023","externalUrl":null,"permalink":"/en/tags/lessons-learned/","section":"Tags","summary":"","title":"Lessons Learned","type":"tags"},{"content":"","date":"13 June 2023","externalUrl":null,"permalink":"/en/tags/vulnerability-management/","section":"Tags","summary":"","title":"Vulnerability Management","type":"tags"},{"content":"Across ten sessions we wired security checks into a GitHub Actions pipeline that fires on every commit and every Pull Request. That covers code we are actively changing. It does not cover the code that is already running in production while researchers keep finding new CVEs in the libraries it uses. In Part 11 of the GitHub DevSecOps series, Patrick Steger and I add a scheduled workflow that re-scans the production branch — and we run straight into a GitHub limitation worth knowing about up front.\nWhy Commit Triggers Are Not Enough # Every check we built — SAST, SCA, container scanning, DAST, the lot — runs when somebody pushes code. That model assumes the risk surface only changes when the code changes. It does not. A library you depended on two months ago could be clean back then and have a critical CVE today. Nothing in your repo moved, and yet your application is now vulnerable.\nThe fix is to run the security tests on a regular schedule against the branch that holds your production code. New CVEs in old dependencies surface within a day instead of whenever the next hotfix forces a build.\nPick the Right Jobs for the Schedule # A scheduled run is not a re-run of the entire pipeline. The jobs that earn their keep are the ones whose results can change without the code changing — anything based on Software Composition Analysis. Concretely, in our pipeline:\nBuild stays in. SCA needs the resolved dependency graph the build produces. SCA / Dependency Scanning stays in. This is the whole reason for the schedule. Container Image Scan stays in. The base image you shipped may have new OS-level CVEs. License Compliance comes out. Licenses do not change while you sleep. DAST comes out. We are not redeploying to a test environment to scan it. Three jobs, on a cron, against production. That is the shape.\nThe GitHub Limitation: Default Branch Only # In GitHub Actions you add on: schedule: with a cron expression to a workflow file, and the workflow runs on that schedule. Easy. Then you read the small print: the schedule always runs against the default branch, on the latest commit on that branch.\nThat is a real constraint. If you keep main as your development trunk and ship from a release branch, the schedule will not touch the release branch. The workarounds — using GitHub hooks, references, or external triggers — exist, but they require real custom code. Patrick and I keep things simple in this video and accept the implication: if you want scheduled scans against production, your production branch has to be the default branch. That has knock-on effects (Pull Requests default there, merges go there) so handle it deliberately.\nBuilding the Scheduled Workflow # Rather than crowd the existing main pipeline with conditionals, we create a second workflow file. We copy main-pipeline.yml, paste it as schedule.yml, and rename the workflow to \u0026ldquo;Schedule Main CI/CD Pipeline.\u0026rdquo;\nThe trigger swaps from on: push (and friends) to on: schedule with a cron expression. For the demo we set every six minutes so we can see runs back-to-back; in real life you would pick daily or weekly. Then we strip out the jobs we do not need for a scheduled scan: license compliance and DAST go. Build, SCA, and container image scan stay.\nCommit, push, and we are back in the Actions tab. The next normal pipeline run gets cancelled. A few minutes later the scheduled run kicks off, and the only jobs in the run are the ones we kept. Six minutes later it runs again. The mechanism works.\nTwo Workflows, Two Responsibilities # The two-file approach has a real advantage over packing everything into one workflow with if: conditions: each file has one job. main-pipeline.yml is what runs on developer activity. schedule.yml is what runs on a clock. New job? You decide which file it belongs in. That clarity is worth the small duplication.\nThe downside is that the two files can drift. If you add a new SCA-style scanner to the main pipeline, remember to add it to the scheduled one too. A short comment at the top of each file pointing at the other goes a long way.\nAre We Secure Now? # With everything built across the series — SAST, secret detection, SCA, container scanning, DAST, Pull Request gating, and now a scheduled re-scan of production — you are about as far as the GitHub-native tooling takes you without significant custom work. You will still find vulnerabilities. You will still need to triage them. But you will find them on a clock instead of by accident.\nIn the next and last session, Patrick and I lay out our recommendations for a team running DevSecOps on GitHub.\nKey Takeaways # Commit triggers do not catch CVEs in unchanged code. New vulnerabilities in your dependencies surface every day. A schedule is the only way to see them without redeploying.\nSchedule only the SCA-style jobs. Build, SCA, and container scanning earn their keep on a cron. License compliance and DAST do not.\nGitHub schedules only run on the default branch. Plan for it. If your production branch is not your default branch, schedules will not see it without serious workarounds.\nUse a second workflow file, not conditionals. main-pipeline.yml for commits, schedule.yml for cron. Each file has one purpose; new jobs go in the right place.\nCron interval is a real-life decision. Every six minutes is a demo cadence. Pick daily or weekly based on how fast your team can act on a new finding.\nGitHub\u0026rsquo;s defaults push you toward main as production. That has consequences for Pull Requests, merges, and human error. Make the choice consciously, not by accident.\n","date":"5 June 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-schedule-pipeline/","section":"Blogs","summary":"Across ten sessions we wired security checks into a GitHub Actions pipeline that fires on every commit and every Pull Request. That covers code we are actively changing. It does not cover the code that is already running in production while researchers keep finding new CVEs in the libraries it uses. In Part 11 of the GitHub DevSecOps series, Patrick Steger and I add a scheduled workflow that re-scans the production branch — and we run straight into a GitHub limitation worth knowing about up front.\n","title":"GitHub DevSecOps Part 11: Scheduled Pipelines for Production Code","type":"blogs"},{"content":"","date":"5 June 2023","externalUrl":null,"permalink":"/en/tags/pipeline-automation/","section":"Tags","summary":"","title":"Pipeline Automation","type":"tags"},{"content":"","date":"5 June 2023","externalUrl":null,"permalink":"/en/tags/sca/","section":"Tags","summary":"","title":"SCA","type":"tags"},{"content":"","date":"5 June 2023","externalUrl":null,"permalink":"/en/tags/scheduled-pipelines/","section":"Tags","summary":"","title":"Scheduled Pipelines","type":"tags"},{"content":"","date":"30 May 2023","externalUrl":null,"permalink":"/en/tags/branch-protection/","section":"Tags","summary":"","title":"Branch Protection","type":"tags"},{"content":"","date":"30 May 2023","externalUrl":null,"permalink":"/en/tags/code-review/","section":"Tags","summary":"","title":"Code Review","type":"tags"},{"content":"In the previous nine sessions Patrick Steger and I built a GitHub DevSecOps pipeline with build, SCA, License Compliance, SAST, Container Scanning, Secret Detection and DAST. All useful — but only if it actually runs before code lands in main, and only if the merge is blocked when something serious shows up. In Part 10 we wire that gate together with Pull Requests and Branch Protection rules.\nPull Requests Are a Discussion, Not a Submit Button # To understand a Pull Request you first have to understand a branch. The main branch holds the project. When I want to make a change, I create a feature branch, commit on it, and when I am ready I open a Pull Request to pull those commits back into main.\nPatrick asked the obvious question: do I only open the PR when I am completely done? Absolutely not. The whole point of a modern Pull Request is the discussion. Open it early, discuss with the team, push more commits as the conversation evolves. The \u0026ldquo;pull\u0026rdquo; in the name is historical. Today the PR is where reviews happen, where workflows report results, and where the eventual merge decision is made.\nWhen everything is validated — both human reviews and automated workflows — the last step of a Pull Request is merging it back to main.\nBranch Protection Is What Enforces It # Branch Protection is the means to enforce those steps before anything reaches the target branch. The rules can require workflows to run, require approvals from a security expert or architect, and require specific status checks to pass.\nYou configure it under Settings → Branches → Branch Protection rules. There are many options, and we walk through the ones that matter for DevSecOps in the demo.\nThe Best Practices # Before the demo we line up the practices we recommend whenever Pull Requests are used:\nOpen Pull Requests early and often, and keep them small. The smaller the batch size, the faster the feedback loop. A Pull Request does not have to be merged. It can be rejected, or used to explore alternatives in the team. Use Pull Request templates so reviewers always get the context they need. Define Branch Protection rules — that is the whole point of this video. Take advantage of the different merge methods (merge, squash, rebase) and choose deliberately. The Demo: PR Without Protection # I edit the POM file to bump Spring Boot from 2.0.1 to 2.0.9, and I add a new MD5 hash on a message — a deliberate insecure crypto algorithm to trigger SAST. Patrick reminds me I forgot to create a branch first. No problem in GitHub: you create a new branch and move the changes onto it directly.\nWe open a Pull Request from fixes into main. We see space for conversation, the commits, the file changes — but only one security check is running, not the full pipeline. The reason: when we built the pipeline workflow, we restricted it with on: push: branches: [main]. The pipeline only runs on main.\nThe other thing missing: nothing forces an approval, nothing blocks the merge.\nConfiguring Branch Protection # Settings → Branches → Add Branch Protection rule. We use * so the rule applies to every branch. Then we enable:\nRequire a Pull Request before merging. No more pushing straight to main. Require approvals. With just Patrick and me on the repo we set the count to 1. Require status checks before merging, and require branches to be up to date before merging. For status checks you have to add each job by name: Build, SCA, License Compliance, SAST, Docker Image, Container Image Scan, DAST, License Compliance, Test Results. Patrick called the usability of this part not great, and he is right — it is detailed work, one job at a time. We also enable \u0026ldquo;Do not allow bypassing the above settings\u0026rdquo;, which is exactly what you want on a production branch.\nBack on the Pull Request the required checks are now listed but still not executing — because the workflow itself is still pinned to main. So I edit the workflow, remove the branch filter so the pipeline runs on every branch, and commit it on main. Because that change happened on main, the existing PR has to be closed and reopened (and the branch updated) before the new workflow definition picks it up.\nReading the Results on the PR # Now the pipeline runs against the PR. Build runs, SCA runs, test results show up directly on the Pull Request, and the GitHub code scanning report surfaces our new findings — including the MD5 issue. It even shows up twice, because both Semgrep and CodeQL detect it. Each finding has \u0026ldquo;show paths\u0026rdquo; and \u0026ldquo;dismiss this alert\u0026rdquo; actions, plus a per-finding conversation thread.\nOne honest gap: GitHub does not show what findings a commit resolved, only what it introduced. DAST also failed, but in our case because of a rate limit on the open-source service we are using, not because of a real issue.\nThe merge is still blocked because we have not approved yet. Patrick approves with a note that the MD5 hash is just an internal hash function. The merge button unlocks and we confirm the merge — the Pull Request is closed, the changes are in main, and the workflow runs again on main as expected.\nRecap # Pull Requests are the discussion surface; Branch Protection is the enforcement. Without the protection rules the PR is just a UI. With protection rules requiring PRs, approvals, and the full set of pipeline status checks, the PR becomes a real DevSecOps gate. New findings are visible per PR, conversations happen on findings, and merges are blocked until both humans and tooling agree.\nNext session we look at scheduled pipelines — making sure code already in production keeps getting scanned, even when nobody is committing.\nKey Takeaways # A Pull Request is a discussion, not a final submit. Open it early, keep batches small, and let the conversation and the workflows shape the change as it evolves.\nBranch Protection is what makes the PR a gate. Without it, the PR is a nice UI on top of a merge button. Required PRs, required approvals and required status checks turn it into something that blocks bad changes.\nPin your workflows to the right branches. Restricting the pipeline to main only means PR scans never run. Either remove the branch filter or add explicit pull-request triggers.\nAdd every status check by name. GitHub does not let you require \u0026ldquo;all checks\u0026rdquo;. You list them: Build, SCA, License Compliance, SAST, Container Scan, DAST, Tests. Tedious — but explicit and auditable.\nPRs surface new findings, not resolved ones. Code scanning shows what this PR introduced, sometimes from multiple tools (Semgrep and CodeQL both flagged the MD5). Useful for review; just know that \u0026ldquo;what got fixed\u0026rdquo; is not in the PR view.\n\u0026ldquo;Do not allow bypassing the above settings\u0026rdquo; exists for a reason. Turn it on for production branches so even admins go through the rules. The whole point is that nobody — including future-you in a hurry — can skip the gate.\n","date":"30 May 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-pull-request/","section":"Blogs","summary":"In the previous nine sessions Patrick Steger and I built a GitHub DevSecOps pipeline with build, SCA, License Compliance, SAST, Container Scanning, Secret Detection and DAST. All useful — but only if it actually runs before code lands in main, and only if the merge is blocked when something serious shows up. In Part 10 we wire that gate together with Pull Requests and Branch Protection rules.\n","title":"GitHub DevSecOps Part 10: Branch Protection and Pull Requests","type":"blogs"},{"content":"","date":"30 May 2023","externalUrl":null,"permalink":"/en/tags/pull-request/","section":"Tags","summary":"","title":"Pull Request","type":"tags"},{"content":"","date":"30 May 2023","externalUrl":null,"permalink":"/en/tags/shift-left/","section":"Tags","summary":"","title":"Shift Left","type":"tags"},{"content":"","date":"22 May 2023","externalUrl":null,"permalink":"/en/tags/application-security/","section":"Tags","summary":"","title":"Application Security","type":"tags"},{"content":"","date":"22 May 2023","externalUrl":null,"permalink":"/en/tags/code-scanning/","section":"Tags","summary":"","title":"Code Scanning","type":"tags"},{"content":"We have spent the previous eight sessions adding scanners to our GitHub DevSecOps pipeline — SCA, SAST, container scanning, secret detection, DAST. The scanners now produce a steady stream of findings, and the question is: where do we manage them? In Part 9, Patrick Steger and I look at GitHub\u0026rsquo;s built-in Vulnerability Management — the Security Tab — and call out what it does well and what is still missing.\nWhere Vulnerabilities Live on GitHub # Everything happens in the Security Tab. There are two distinct sections. Code Scanning holds findings from the scanners we wired into the pipeline — CodeQL plus any SARIF-producing tool. Secret Scanning is GitHub\u0026rsquo;s own integrated secret detection, with its own UI.\nWhy two different UIs? We do not really know. Our best guess is that Secret Scanning is treated as a platform feature with a special workflow, while Code Scanning is the generic ingestion point for everything else. In practice you switch between them often, and the inconsistency takes some getting used to.\nVulnerabilities are tracked across all branches where the pipeline ran the scanners. The branches close to production are obviously the ones to focus on, but you can filter by branch when you need to.\nThe Capabilities GitHub Gives You # For each finding you can sort and filter by tool, branch, severity, and rule (the rule filter is honestly not very useful unless you know exactly what you are looking for). From a finding you can:\nCreate an issue to hand work off to a developer. The vulnerability and the issue link both ways. Dismiss with a reason: false positive, won\u0026rsquo;t fix (we accept the risk), or used in tests (it is in test code, not production). Crucially, you can — and should — add a comment explaining the decision. Track history. GitHub shows when the finding was first detected, on which branch it appeared, when it was fixed, and if it reappeared. There is no explicit \u0026ldquo;resolved\u0026rdquo; button. When the scanner stops reporting a finding on the next pipeline run, GitHub closes it automatically.\nYou can integrate additional scanners as long as they produce SARIF format. SARIF is at least a standard, so this is not a heavy constraint.\nThe Limitations to Plan Around # Patrick is direct about where GitHub falls short.\nNo time-boxed dismissal. You cannot dismiss a finding for two weeks or two months. Sometimes you want a finding to go away \u0026ldquo;for now\u0026rdquo; — there is no fix yet, or the team needs to ship something else first — but GitHub does not let you defer cleanly.\nYou cannot change the severity. If the tool says \u0026ldquo;high,\u0026rdquo; it stays \u0026ldquo;high.\u0026rdquo; Compensating controls in your environment may genuinely make it medium or low, but GitHub does not let you reflect that.\nManual triage is unavoidable. Every Vulnerability Management tool needs human review for false positives and duplicates. That is not a GitHub-specific issue, but plan for the effort.\nNo manual entries. This is the one Patrick really hates. If you commission an external penetration test and the tester finds ten new vulnerabilities, you cannot add them to the GitHub Vulnerability Management. You need a separate tool for anything found outside the platform — a serious limitation if penetration testing is part of your process.\nTriage Workflow in Practice # In the demo we worked through the realistic flow. In Secret Scanning the findings are clear: a title, a reference to the secret, and a remediation recommendation. You know what the problem is and what to do.\nIn Code Scanning we filtered to CodeQL and opened a \u0026ldquo;use of broken or risky cryptography\u0026rdquo; finding — an MD5 instance we had assessed before. We use it for indexing, not for security, so we dismissed as false positive with the comment \u0026ldquo;it\u0026rsquo;s just for indexing.\u0026rdquo; That comment is the difference between a useful audit trail and a black box.\nNext we opened a real cross-site scripting finding — a message returned to the caller and reflected. Real issue. We created an issue directly from the finding. GitHub jumps to the new issue with the link back to the vulnerability, and the vulnerability page shows the linked issue. Two-way linking works well.\nTo fix it we used the file view to navigate to the source, switched to the main branch, edited inline, and saved. The pipeline ran in Actions, CodeQL re-scanned, and the open count for the rule dropped to zero. Under the closed filter the cross-site scripting finding shows up as resolved minutes ago.\nOne thing to know: the issue we created is not auto-closed when the vulnerability is. The developer (or you) has to close it manually. Arguably acceptable — closing it by hand is the developer\u0026rsquo;s confirmation that the fix is deployed — but it is not automatic.\nKey Takeaways # One tab, two UIs. Secret Scanning and Code Scanning live in the same Security Tab but have different UIs. Get used to switching.\nDefault branch is not the only branch. GitHub tracks findings across branches, which is more flexible than the default-branch-only view some other platforms give you.\nDismissal reasons are first-class. False positive vs won\u0026rsquo;t fix vs used in tests, plus a comment field. Use them — they are the audit trail.\nNo time-boxed dismissal. If you need \u0026ldquo;ignore for two months,\u0026rdquo; you have to track it outside GitHub. A label and a calendar reminder is the realistic workaround.\nNo manual entries is the biggest gap. Findings from external penetration tests cannot be added. If pen-testing is part of your process, plan for a second tool.\nIssues and vulnerabilities link both ways but close independently. Create an issue from a finding, fix the code, the vulnerability auto-closes — but remember to close the issue too.\n","date":"22 May 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-vulnerability-management/","section":"Blogs","summary":"We have spent the previous eight sessions adding scanners to our GitHub DevSecOps pipeline — SCA, SAST, container scanning, secret detection, DAST. The scanners now produce a steady stream of findings, and the question is: where do we manage them? In Part 9, Patrick Steger and I look at GitHub’s built-in Vulnerability Management — the Security Tab — and call out what it does well and what is still missing.\n","title":"GitHub DevSecOps Part 9: Vulnerability Management","type":"blogs"},{"content":"","date":"22 May 2023","externalUrl":null,"permalink":"/en/tags/sarif/","section":"Tags","summary":"","title":"SARIF","type":"tags"},{"content":" Join Eveline Oehrlich and Romano Roth, to discuss whether DevOps is Dead.\nTranscript # Narrator 00:02 You\u0026rsquo;re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the skil framework.\nRomano Roth 00:16 We have not yet progressed really into the direction of DevOps, but many companies are doing is they say we have that DevOps silo introduced or we have the DevOps engineer, but that’s not really doing DevOps.\nEveline Oehrlich 00:33 Welcome to humans of DevOps Podcast. I’m Evelyn early Chief Research Officer at DevOps Institute. Our podcast today titled today is a really, huh, I’m not saying it. Let’s wait. DevOps is dead. Question mark, exclamation mark. You’ll know why when we are finished. Today, we have with us, Romano Ross, who is chief of DevOps at a service provider software service provider. Hello, Romano. Hi, Evelyn. How are you doing? I’m very well. All good. All good already to roll up the sleeves and tell us more about a variety of things. But before we go there, I want to just quickly introduce him and Romano. If you have anything to add, please do so. So Romana is a leader, Senior Consultant, architect and software development expert. He has over 20 years of professional experience in many different domains, including the financial insurance, cybersecurity, medical aviation. What did I leave out? Is there anything else you want to add or motto?\nRomano Roth 01:49 No, I think that’s it more or less. The only thing I could add is, I’m also organizing the DevOps meetup Zurich, which is monthly meetup we’re doing it’s free to join. And I’m also the president of the DevOps days, Eric, which is a two day conference, we are organizing, and there are all over the place all over the world in all the big cities. Therefore, these conferences,\nEveline Oehrlich 02:16 Excellent, great addition, I actually went to the tourist one, and, of course, many of the other ones. So that’s great. I did not forget that, that. That was a great experience. All right. Welcome, again to our podcast today. So my first question is chief of DevOps. I love that title. Chief of DevOps is fantastic title tell us what does the chief of DevOps to?\nRomano Roth 02:44 Yeah, it’s an awesome title. So the chief of DevOps is a thought leader. So, as a thought leader, you are speaking, you do conference, speaking, you are doing videos and doing a blog post. But when it comes to Chief of DevOps in a company, you are the solid leader about DevOps in that company, you define the strategy, and also the offering that this company has, and what skills and capabilities are needed to, to be on the market and to do all of these offerings. And of course, you also define the education program, and you also educate the people in terms of DevOps. But the most important thing, what you need to do is you need to work in projects. And only by working the real projects and making your hands dirty, you can really be a thought leader and the chief of DevOps.\nEveline Oehrlich 03:51 I agree with that. Of course, that’s fantastic. Now I was listening and watching a video you did, which really is I’m referring to that video, in our title of the podcast, DevOps is dead. And in that or DevOps is dead, kind of like a surprise. You talked about business, the developers wall of confusion. And what I am curious about, of course, you do your work in dark, but I think you travel, as you said, across Europe and globally. What I’m sorry, what I thought I would ask you Well, I am going to ask you is have we not been through this conversation of DevOps versus developer? You know, Dev versus ops versus business in this wall of confusion and we really progressed yet to a modern way of developing and delivering custom products to customers and service and clients or are our wish I was still asking, what is DevOps? DevOps is dead. I mean, all of that. Give us your perspective on all of that.\nRomano Roth 04:58 So I would also say, yeah, there are also people, which is say it, everything about DevOps has already been set it, everything is clear, it’s everything is there, you just need to do it. But when I go into companies, I nowadays still see the same picture of the business, together with the customers, they have bright ideas. And still, they write it down into Word documents and into into JIRA tickets, and then they are thrown over the wall of confusion to the development team. And the development team then develops these bright ideas. And they just do it and then they throw it over the wall of confusion to a QA team, which is still there. And then they test something and then they throw it over the wall of confusion to the operation team. And still the operation team has difficulties to to operate this software. So these were all of confusions, they are still there. And what we can clearly see is they are still there, because we still have silo organization, many companies have not yet organized themselves across the value stream. So that they really have product teams, still, the companies are working in projects, they still have project and the project always has a start and it has an end and has a budget. And it all boils down to yearly budget goals to KPIs that we that we still have, we have not yet progressed really into the direction of DevOps, what many companies are doing is they say, Yeah, we are doing DevOps, or we have that DevOps silo introduced, or we have the DevOps engineer, but that’s not really doing DevOps.\nEveline Oehrlich 06:59 So really, what I hear you say, is that, even if we say DevOps, without starting at the higher level, in the organization, where there is that common thinking in terms of product, or as you said, value stream, it is going to be a challenge to truly live DevOps or whatever ops, whatever dev x Ops is, right? We’ll get to that. Without having that perspective. Is that what you’re saying?\nRomano Roth 07:31 Yes, absolutely. Because also, when you look at DevOps at the definition of DevOps, and of course, there are 1000s of definition. But as I always say, DevOps is a mindset and the culture and the set of technical practices. I think, when it comes to technical practices, we are more or less okay with with that you know them, but then changing the culture or the mindset is a difficult thing. And it can always only come from the top management. And this is something that all of the companies nowadays are lacking that cultural change, and that mindset change, which my opinion needs to come from top down.\nEveline Oehrlich 08:18 Yeah, so from a pessimistic perspective, which I usually don’t take, but I wanted to just point it out. Some of those DevOps teams are fighting against windmills, because if there is not the top down support on changing the culture, and as a product team, it makes it a challenge. However, we know that they are, as you said, on the technology side on the processes within the DevOps that have been ordered within DevOps to have been a lot of advancements. And those organizations are bubbling up the outcomes and the results of their great work. And hopefully, more and more of that will go up to those executive leaders to see that it’s an overall cultural change. Now, I want to stay on that theme, quickly relative to one DevOps versus multiple DevOps, right? Kind of, so if I have multiple, if I have one DevOps team, small company, blah, blah, blah, might pass be possible, but most of our listeners, excuse me, are in enterprise organizations. So what is a model going forward? Well, what’s the model when there are multiple DevOps teams in an organization?\nRomano Roth 09:28 So this is exactly one of the topics I’m talking quite a lot nowadays. And as you pointed out, when you are a small company, or just building one product, then it’s quite easy to do DevOps more or less, but scaling that up is is difficult. And when we look at that, then what usually happens is that companies tend to do a little bit of DevOps. They build the DevOps silo between Dev and Ops, which is just again a silo until you don’t really get the efficiency that you wanted to see, then when you look at how DevOps really should be is that Dev and Ops are moving together, all of the people are coming together across the value stream, and they are building a cross functional team, then you really are doing DevOps. And now when you think about that, and you have multiple of these value streams, or product teams, then you can clearly see that, out of that, you will have a lot of inefficiencies, because many of these teams are reinventing the wheel, they are doing their own stuff, which is of course good, but they are not really reusing things. So the this this aspect is, is quite critical. Because it you also have a quite a lot of cognitive load in these teams, they need to really care about building the product, operating the product and maintaining the product. This also means that they need to know quite a lot of tools. And this is difficult. And the new kid around the corner, or the new kid in the block is this platform engineering that that we are seeing coming up, where you have a platform team, which builds the platform, and also the API’s and everything so that the product teams can build, maintain and operate the product and do DevOps.\nEveline Oehrlich 11:37 So we have seen that platform engineering team, what is a skill I need, if I want to become a platform engineer? What would you say?\nRomano Roth 11:55 You need to be a software engineer. A platform is nothing else than also a product. So when it comes to skills, in my opinion, it’s really that software engineering skill, because also building that platform requires you to to build a product, the platform, which has a user interface, a self service portal, a marketplace so that you can enable the other teams. So you need to know how to program a user interface, you need to know how to program API’s, you need to know how to program databases. And but you also need to have is the, of course DevOps mindset, DevOps skills. And you need to know a lot about how software is built. So what kind of tools are good to use, so that you can build up this platform so that the teams can most efficient work with these technologies, which means nowadays, you need to know a lot about the cloud technologies, cloud native technologies.\nNarrator 13:15 Scale up it learning is the perfect online destination to learn about DevOps and digital transformation, anytime, anywhere. Our digital learning platform provides you with all the resources you need to upskill and learn about these important topics, including expert led course videos, access to certification, prep courses, and a community of supportive peers. Our subscription based model makes it easy for you to gain the skills needed for success in the modern workplace, visit DevOps institute.com now and explore our different learning plans.\nEveline Oehrlich 13:49 Okay, great. I would certainly not qualify for a DevOps engineer, as a platform engineer, but I probably would be going down the SRE path Site Reliability Engineering, because I have an infrastructure and operations background. But I have another question. There was always this, you know, when we do research on DevOps and read in whatever magazines or whatever events we go to there is or whatever vendor I talk to, because I do speak to quite a few vendors, as I’m also having an industry analyst position. There are these different terms def sec, ops, Biz Ops, dev x ops DevOps, there’s more and more coming out of the closet. So I, and then of course, there’s value stream management, right? VSM. And all of them are related SRE and keep going, all of them are related, but it seems to me and I know you you had this argument with yourself as well. I was listening to your video, it seems to me when we sometimes when we use the word DevOps people or individuals or whoever thinks that this is just as movement lol level somewhere in the development and operations team, but it is bigger. So is DevOps, the term itself not really serving our purpose? Should we call it DevOps? Or Should this be called something else? What’s your thought on that?\nRomano Roth 15:15 Yeah. So let’s, let’s be, quite frankly, when we look at the term DevOps, then this term, DevOps is not very good. The term DevOps says development and operation. And back in that time, it was okay ish. I think it was around 2008. When this term came up, it was occasioned as he pointed out, more and more of these terms are coming up like dev SEC ops, which is development, security and operation or biz dev ops, business, development and operation. And but as I pointed out, DevOps is about bringing all the people together, where you would need sort of a term like def beats our QA, ops, and I’m pretty sure I have forgotten someone. You can also call it ethics ops, or Deathstar ops. For me, DevOps is really about bringing all the people all the technology and all the process together to continuously deliver value. It’s really about how we can continuously deliver a product or service to our customers. That’s the important thing. Now, of course, we can now argue what could be a better term. In my opinion, this is secondary. As long as we have a good understanding of what DevOps is, and what what it what it is all about, then this term is okay. I also don’t believe belief that we really can find a very good term to describe that.\nEveline Oehrlich 17:00 So what you’re saying is stop talking about what it is just go on, do follow the paths, try to adopt the practices and change the culture on the way, expanding it from a pilot, expanding it into something more good executive buy in, and so on. And so, as we have different maturity levels, I don’t know if that is even the right term, I’m questioning myself when I say maturity, because as we know, we’re never done with it, right? We, we move into the next technology, we are adopting whatever Mehta or AR VR rpa, different server lists, blah, blah, blah, all of that wonderful stuff, wonderful stuff, our environment keeps getting more complex, our demands for services and products are tied to customer experience, etc, etc. So we will never be done. But it’s it’s a two part question. The first one is, when I am somewhere in a kind of good DevOps, journey, high performing, and I am somewhere a DevOps Chief Chief of DevOps. What can I in this case, you know, you are the chief of DevOps, what would you recommend to those folks to actually scale it further among that maybe high performing team? What are some of the things they should be doing to expand their their journey in their culture in towards the bigger foot print of DevOps? And I don’t mean it from a sorry to clarify, I don’t mean it from a technology perspective, I mean, or from maybe not a process perspective, but really from a people from a culture perspective.\nRomano Roth 18:57 So, what, what do you need to do is you need to organize across the value stream, I think this is really the magic you need to do you need to identify the value streams in your in your company, how you generate value, what kind of steps are needed and what people are in there, and then organize these people in these value streams. You can also call it product teams. Of course, a value stream can also have multiple products, but it is very important to organize around that value stream. And secondly, what is also important important is to empower the people and so empower this value stream give this value stream budget. So that’s the value stream itself can decide what is necessary to do to make a great product or multiple great products for For the customers, and now you can also see we are shifting away from from projects from, we need to have these 10 features to a point where the customer is in the center, and we want to have happy customers, but also of course happy employees. So that we really are focusing on the on the customer and building absolutely great products with building and quality. So that will be my recommendation to organize across the value stream, bring the customer into the center half KPIs, according to to the customer. And also employees as satisfaction and giving really empower the people in this value stream give it giving them the budget and the power to decide.\nEveline Oehrlich 20:54 Excellent. I wanted to do a quick shout out to a project I’m involved in with Helen Beal I believe, you know, Helen, right? Maybe you don’t know you don’t you have to meet her. She is basically besides her being a colleague of mine at the DevOps Institute. She’s also the chair of the value stream Consortium, which is a, I think the first time ever since I’ve been in this space, a variety of vendors are getting together, and are researching and are applying common thinking and thought leadership together on value stream management, and one of the projects we’re doing is the second notice the third year we’re doing research in the state of value stream management. And just recently, Helen did a fantastic it’s called a pier scape with IDC. And if you just type in anybody listening, if you type in pure scape, IDC value stream management, you should be able to see the video and the conversation around a value stream management a fantastic ability to learn how to start that journey. And one of the customers there actually was Netflix, a product manager of Netflix, who has talked about how they are doing value stream management in their company. Excellent. All right, looking at the clock, why do fun conversations always go by so fast? So pull out your crystal ball. Besides the conversation on value stream management, let’s hope there is more and more interest and adoption of that product thinking in the value stream management thinking. But if we, if we go down the road, if we even can, right? If we look maybe two years from now, what do you think? What is the future of DevOps, then? Two years? What is that that is 2025? When you and I will be sitting somewhere in soulish to have a cup of coffee or cappuccino or an adult beverage doesn’t matter? What would we then see in DevOps.\nRomano Roth 23:00 But we can clearly see at the moment is Alta Vista was platform engineering, and they were all of the toolings there is a lot of standardization coming in, you can not clearly see that it’s more under the hood. But we are going to into an area where software development gets standardized. And in my opinion, it gets industrialized, we are going away, let’s say from just always reinventing the wheel it into a direction of where you are using different things together. And they fit together because they are standardized. In my opinion, what we will see is the build up of digital factories, you can already see that together with the platform engineering companies are building their own digital factories, where in this digital factory, the teams are organized across the value stream where they are producing digital products or cyber physical products. And the platform engineering team provides the convenient belt for these digital factories in the companies. So my prediction is we will see a lot of digital factories coming up.\nEveline Oehrlich 24:22 I would I would bet you but I am agreeing with you. So I will buy the drink because I ordered a coffee or a cup of tea. No, I agree with you. This is a great, great conversation digital factories. That’s something I’d love to explore further. But not today. But really, really great insight. I love that crystal ball vision you have there in the future. For my No this was great. Now I have one more question. It’s a closing question. It has nothing to do with digital factories, DevOps, or any of those terms. What do you do for fun?\nRomano Roth 24:57 Oh, I love to travel around the world. I love to see new countries and in these countries, I do a lot of photography. I also have my Instagram channel and I have a second YouTube channel where I post also some videos at the moment. I do a lot of 360 degree videos, which I love. And of course, I love playing computer games and I also read a lot.\nEveline Oehrlich 25:27 Fantastic. Well, if you ever make it to my region of as I’m only really an hour and a half north of you, stop by give me a buzz. We’ll go and travel my hometown together, you can take 360 degree videos, I will check out the videos you have done. Thank you so much. We have been talking to Romana Ross, Chief of DevOps at SilkAir, which is a service provider software consulting organization. He does a lot of work and talk leading so check him out. Again, Amanda, thank you so much for joining me today on humans of DevOps podcast. Thank you for having me. Humans of DevOps podcast is produced by DevOps Institute. Our audio production team includes Julia pape, Daniel Newman, Schultz and Brendan Leigh. Shout out to my wonderful colleagues. I’m humans of DevOps podcast, Executive Producer, Evelyn early. If you would like to join us on a podcast, please contact us at this very long email humansofdevopspodcast@devopsinstitute.com. I’m Evelyn early. I’ll talk to you soon.\nNarrator 26:42 Thanks for listening to this episode of the humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong\nOriginal Post: DevOps Institute: EP101: DevOps Is NOT Dead\n","date":"10 May 2023","externalUrl":null,"permalink":"/en/blogs/devops-is-not-dead/","section":"Blogs","summary":" Join Eveline Oehrlich and Romano Roth, to discuss whether DevOps is Dead.\nTranscript # Narrator 00:02 You’re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the skil framework.\n","title":"DevOps Is NOT Dead","type":"blogs"},{"content":" Begleiten Sie Eveline Oehrlich und Romano Roth bei der Diskussion, ob DevOps tot ist.\nTranskript # Narrator 00:02 Sie hören den Humans of DevOps Podcast, einen Podcast, der darauf ausgerichtet ist, die Menschen im DevOps-Umfeld durch Fähigkeiten, Wissen, Ideen und Lernen weiterzubringen – das SKIL-Framework.\nRomano Roth 00:16 Wir sind in Wirklichkeit noch nicht wirklich in Richtung DevOps vorgedrungen. Was viele Unternehmen jedoch tun, ist, dass sie sagen, sie hätten dieses DevOps-Silo eingeführt oder einen DevOps-Engineer – aber das ist nicht wirklich DevOps.\nEveline Oehrlich 00:33 Willkommen beim Humans of DevOps Podcast. Ich bin Eveline, Chief Research Officer beim DevOps Institute. Unser Podcast heute trägt den Titel – ach, ich sage ihn nicht. Warten wir ab. DevOps ist tot. Fragezeichen, Ausrufezeichen. Sie werden wissen, warum, wenn wir fertig sind. Heute haben wir Romano Roth bei uns, der Chief of DevOps bei einem Software-Service-Provider ist. Hallo Romano. Hi Eveline. Wie geht es dir? Sehr gut. Alles gut. Schon bereit, die Ärmel hochzukrempeln und uns mehr über eine Vielzahl von Dingen zu erzählen. Aber bevor wir dazu kommen, möchte ich ihn kurz vorstellen, und Romano, wenn du etwas hinzufügen möchtest, tu das bitte. Romano ist ein Leader, Senior Consultant, Architekt und Software-Entwicklungsexperte. Er hat über 20 Jahre Berufserfahrung in vielen verschiedenen Domänen, einschliesslich Finanzen, Versicherung, Cybersecurity, Medizin und Luftfahrt. Was habe ich ausgelassen? Gibt es noch etwas, das du hinzufügen möchtest, oder ein Motto?\nRomano Roth 01:49 Nein, ich glaube, das war es mehr oder weniger. Das Einzige, was ich hinzufügen könnte, ist: Ich organisiere auch das DevOps Meetup Zürich, das ein monatliches Meetup ist – die Teilnahme ist kostenlos. Und ich bin auch Präsident der DevOpsDays Zürich, was eine zweitägige Konferenz ist, die wir organisieren – und es gibt sie überall auf der Welt in allen grossen Städten. Diese Konferenzen also.\nEveline Oehrlich 02:16 Hervorragend, eine grossartige Ergänzung. Ich war tatsächlich auf der in Zürich, und natürlich auf vielen der anderen. Das war eine grossartige Erfahrung. Also, willkommen erneut zu unserem heutigen Podcast. Meine erste Frage: Chief of DevOps – ich liebe diesen Titel. Chief of DevOps ist ein fantastischer Titel. Erzähl uns: Was macht ein Chief of DevOps?\nRomano Roth 02:44 Ja, es ist ein toller Titel. Der Chief of DevOps ist ein Thought Leader. Als Thought Leader sprichst du, hältst Konferenzvorträge, machst Videos und schreibst Blogposts. Aber wenn es um Chief of DevOps in einem Unternehmen geht, bist du der inhaltliche Verantwortliche für DevOps in diesem Unternehmen. Du definierst die Strategie und auch das Angebot, das dieses Unternehmen hat, sowie die Skills und Fähigkeiten, die nötig sind, um am Markt zu bestehen und all diese Angebote umzusetzen. Und natürlich definierst du auch das Ausbildungsprogramm und bildest die Leute in Sachen DevOps weiter. Aber das Wichtigste ist, dass du in Projekten arbeiten musst. Nur wenn du in echten Projekten arbeitest und dir die Hände schmutzig machst, kannst du wirklich ein Thought Leader und Chief of DevOps sein.\nEveline Oehrlich 03:51 Da stimme ich dir zu. Das ist natürlich fantastisch. Ich habe ein Video von dir gehört und gesehen, auf das ich mich auch im Titel unseres Podcasts beziehe: «DevOps ist tot». Und in diesem Video – «DevOps ist tot», fast als Überraschung – hast du über das Business und die «Wall of Confusion» der Entwickler gesprochen. Was mich nun interessiert: Du arbeitest natürlich im DACH-Raum, aber du reist, wie du gesagt hast, durch ganz Europa und global. Was ich – ach, was ich dich fragen will: Haben wir nicht schon dieses Gespräch über DevOps gegen Developer geführt? Du weisst schon, Dev gegen Ops gegen Business in dieser «Wall of Confusion» – und sind wir wirklich schon zu einer modernen Art und Weise vorgedrungen, kundenspezifische Produkte und Services für Kundinnen und Kunden zu entwickeln und zu liefern? Oder fragen wir uns immer noch: Was ist DevOps? DevOps ist tot? Gib uns deine Perspektive zu all dem.\nRomano Roth 04:58 Ja, ich würde auch sagen: Es gibt Leute, die sagen, alles über DevOps sei bereits gesagt, alles sei klar, alles sei da, man müsse es nur tun. Aber wenn ich in Unternehmen gehe, sehe ich heutzutage immer noch dasselbe Bild: Das Business hat zusammen mit den Kunden grossartige Ideen. Und sie schreiben sie immer noch in Word-Dokumente und Jira-Tickets, und dann werden sie über die Wall of Confusion zum Entwicklungsteam geworfen. Und das Entwicklungsteam entwickelt diese grossartigen Ideen. Sie machen es einfach, und dann werfen sie es über die Wall of Confusion zu einem QA-Team, das immer noch da ist. Dann testen sie etwas und werfen es über die Wall of Confusion zum Operations-Team. Und das Operations-Team hat immer noch Schwierigkeiten, diese Software zu betreiben. Diese Walls of Confusion sind also immer noch da. Und was wir klar sehen können: Sie sind immer noch da, weil wir immer noch eine Silo-Organisation haben. Viele Unternehmen haben sich noch nicht entlang des Wertstroms organisiert, sodass sie wirklich Produktteams hätten. Stattdessen arbeiten die Unternehmen immer noch in Projekten – ein Projekt hat immer einen Anfang und ein Ende und ein Budget. Und es läuft alles auf jährliche Budgetziele und KPIs hinaus, die wir noch immer haben. Wir sind in Wirklichkeit noch nicht wirklich in Richtung DevOps vorgedrungen. Was viele Unternehmen tun, ist, dass sie sagen: «Ja, wir machen DevOps» oder «Wir haben dieses DevOps-Silo eingeführt» oder «Wir haben den DevOps-Engineer» – aber das ist nicht wirklich DevOps.\nEveline Oehrlich 06:59 Was ich dich also sagen höre: Selbst wenn wir DevOps sagen, wird es eine Herausforderung sein, DevOps – oder welches Ops, welches DevX-Ops auch immer – wirklich zu leben, wenn wir nicht auf der höheren Ebene der Organisation beginnen, wo dieses gemeinsame Denken in Bezug auf Produkt oder, wie du sagst, Wertstrom existiert. Wir kommen noch dazu. Ohne diese Perspektive geht es nicht. Ist es das, was du sagst?\nRomano Roth 07:31 Ja, absolut. Denn wenn man sich DevOps anschaut, die Definition von DevOps – und natürlich gibt es Tausende von Definitionen –, aber wie ich immer sage: DevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken. Bei den technischen Praktiken sind wir mehr oder weniger okay – die kennt man. Aber dann die Kultur oder das Mindset zu ändern, ist eine schwierige Sache. Und das kann immer nur vom Top-Management kommen. Und das ist etwas, was allen Unternehmen heutzutage fehlt: dieser Kulturwandel und Mindset-Wandel, der meiner Meinung nach top-down kommen muss.\nEveline Oehrlich 08:18 Ja, also aus pessimistischer Perspektive, die ich sonst nicht einnehme, aber ich wollte es einfach erwähnen: Einige dieser DevOps-Teams kämpfen gegen Windmühlen, denn wenn die Top-down-Unterstützung für die Veränderung der Kultur fehlt – und als Produktteam – ist es eine Herausforderung. Wir wissen jedoch, dass es, wie du gesagt hast, auf der Technologieseite und bei den Prozessen innerhalb von DevOps viele Fortschritte gegeben hat. Und diese Organisationen tragen die Ergebnisse und Resultate ihrer grossartigen Arbeit nach oben. Hoffentlich gelangt immer mehr davon zu den Führungskräften, sodass sie sehen, dass es ein umfassender Kulturwandel ist. Nun möchte ich kurz beim Thema bleiben: ein DevOps versus mehrere DevOps. Wenn ich ein DevOps-Team habe – kleine Firma, blah, blah – mag das möglich sein, aber die meisten unserer Hörerinnen und Hörer sind in Enterprise-Organisationen. Was ist also ein zukunftsfähiges Modell, wenn es mehrere DevOps-Teams in einer Organisation gibt?\nRomano Roth 09:28 Das ist genau eines der Themen, über die ich heutzutage viel spreche. Wie du sagst: Wenn man eine kleine Firma ist oder nur ein Produkt baut, dann ist DevOps mehr oder weniger einfach. Aber das hochzuskalieren ist schwierig. Was üblicherweise passiert, ist, dass Unternehmen ein bisschen DevOps machen. Sie bauen das DevOps-Silo zwischen Dev und Ops auf, was wieder nur ein Silo ist – bis du nicht wirklich die Effizienz bekommst, die du sehen wolltest. Wenn du dann anschaust, wie DevOps wirklich sein sollte, dann rücken Dev und Ops zusammen, alle Leute kommen über den Wertstrom hinweg zusammen und bauen ein crossfunktionales Team – dann machst du wirklich DevOps. Wenn du nun darüber nachdenkst und mehrere dieser Wertströme oder Produktteams hast, dann siehst du klar, dass daraus viele Ineffizienzen entstehen, weil viele dieser Teams das Rad neu erfinden. Sie machen ihr eigenes Ding – was natürlich gut ist –, aber sie wiederverwenden Dinge nicht wirklich. Dieser Aspekt ist ziemlich kritisch. Denn du hast in diesen Teams auch eine ziemlich hohe kognitive Belastung – sie müssen sich wirklich um den Aufbau, den Betrieb und die Wartung des Produkts kümmern. Das bedeutet auch, dass sie ziemlich viele Tools kennen müssen. Und das ist schwierig. Und der neue Star am Horizont ist Platform Engineering, das wir aufkommen sehen. Da gibt es ein Plattformteam, das die Plattform und auch die APIs und alles Weitere baut, sodass die Produktteams das Produkt bauen, warten und betreiben können – und DevOps machen können.\nEveline Oehrlich 11:37 Wir haben dieses Plattform-Engineering-Team also gesehen. Welche Skills brauche ich, wenn ich Platform Engineer werden will? Was würdest du sagen?\nRomano Roth 11:55 Du musst Software-Engineer sein. Eine Plattform ist nichts anderes als ein Produkt. Wenn es also um die Skills geht, ist es meiner Meinung nach wirklich diese Software-Engineering-Fähigkeit. Denn auch der Bau dieser Plattform erfordert, dass du ein Produkt baust – die Plattform –, das ein User Interface, ein Self-Service-Portal und einen Marketplace hat, sodass du die anderen Teams befähigen kannst. Du musst also wissen, wie man ein User Interface programmiert, du musst wissen, wie man APIs programmiert, du musst wissen, wie man Datenbanken programmiert. Aber du musst auch das DevOps-Mindset und die DevOps-Skills haben. Und du musst viel darüber wissen, wie Software gebaut wird – also welche Art von Tools sich gut eignen, damit du diese Plattform aufbauen kannst, sodass die Teams am effizientesten mit diesen Technologien arbeiten können. Das heisst heutzutage: Du musst viel über Cloud-Technologien und Cloud-Native-Technologien wissen.\nNarrator 13:15 Scale up IT Learning ist das perfekte Online-Ziel, um jederzeit und überall etwas über DevOps und digitale Transformation zu lernen. Unsere digitale Lernplattform bietet alle Ressourcen, die Sie brauchen, um sich weiterzubilden und sich mit diesen wichtigen Themen vertraut zu machen, einschliesslich von Experten geführter Kursvideos, Zugang zu Zertifizierungs-Vorbereitungskursen und einer Community unterstützender Gleichgesinnter. Unser abonnementbasiertes Modell macht es einfach, die für den Erfolg am modernen Arbeitsplatz benötigten Fähigkeiten zu erwerben. Besuchen Sie devopsinstitute.com und entdecken Sie unsere verschiedenen Lernpläne.\nEveline Oehrlich 13:49 Okay, super. Ich würde mich sicherlich nicht als DevOps-Engineer und auch nicht als Platform Engineer qualifizieren, aber wahrscheinlich würde ich den SRE-Pfad gehen – Site Reliability Engineering –, weil ich einen Infrastruktur- und Operations-Hintergrund habe. Aber ich habe noch eine Frage. Es gab immer dieses … wenn wir Forschung über DevOps machen und in irgendwelchen Magazinen lesen oder zu Events gehen, oder mit irgendeinem Anbieter spreche – ich spreche mit ziemlich vielen Anbietern, da ich auch eine Position als Industrie-Analystin habe. Es gibt diese verschiedenen Begriffe: DevSecOps, BizOps, DevXOps, DevOps – immer mehr kommen aus dem Schrank. Und dann gibt es natürlich Value Stream Management, also VSM. Und alle diese sind verwandt – SRE und so weiter. Es scheint mir manchmal, wenn wir das Wort DevOps verwenden, dass Personen denken, das sei nur eine Bewegung irgendwo auf einer niedrigeren Ebene im Development- und Operations-Team, dabei ist es grösser. Dient also der Begriff DevOps unserem Zweck nicht wirklich? Sollten wir es DevOps nennen oder etwas anderes? Was meinst du dazu?\nRomano Roth 15:15 Ja, also ehrlich gesagt: Wenn wir uns den Begriff DevOps anschauen, dann ist dieser Begriff DevOps nicht sehr gut. Der Begriff DevOps sagt Development und Operation. Und damals war das einigermassen okay – ich glaube, es war um 2008, als dieser Begriff aufkam. Inzwischen, wie du gesagt hast, kommen immer mehr dieser Begriffe auf, etwa DevSecOps – Development, Security und Operation – oder BizDevOps – Business, Development und Operation. Aber wie ich sagte: Bei DevOps geht es darum, alle Leute zusammenzubringen. Eigentlich bräuchte man einen Begriff wie DevBizUXQAOps – und ich bin sicher, jemanden habe ich vergessen. Du kannst es auch EthicsOps oder DeathstarOps nennen. Für mich geht es bei DevOps wirklich darum, alle Leute, die ganze Technologie und alle Prozesse zusammenzubringen, um kontinuierlich Wert zu liefern. Es geht wirklich darum, wie wir kontinuierlich ein Produkt oder einen Service an unsere Kundinnen und Kunden liefern können. Das ist das Wichtige. Natürlich kann man jetzt darüber streiten, was ein besserer Begriff wäre. Meiner Meinung nach ist das zweitrangig. Solange wir ein gutes Verständnis davon haben, was DevOps ist und worum es geht, ist dieser Begriff okay. Ich glaube auch nicht, dass wir wirklich einen sehr guten Begriff finden können, um das zu beschreiben.\nEveline Oehrlich 17:00 Was du sagst, ist also: Hör auf darüber zu reden, was es ist – mach einfach weiter, folge den Wegen, versuch die Praktiken zu übernehmen und die Kultur zu verändern, das Ganze von einem Pilot auf etwas Grösseres auszuweiten, mit gutem Executive-Buy-in und so weiter. Wir haben unterschiedliche Reifegrade – ich weiss nicht einmal, ob das der richtige Begriff ist. Ich frage mich selbst, wenn ich «Reife» sage, denn wir wissen, wir sind nie damit fertig, oder? Wir bewegen uns in die nächste Technologie, wir adoptieren Meta, AR, VR, RPA, Different Serverless, blah, blah – all dieses wundervolle Zeug. Unser Umfeld wird immer komplexer, unsere Anforderungen an Services und Produkte sind an die Customer Experience gebunden, etc. Wir werden also nie fertig sein. Aber es ist eine zweiteilige Frage. Erstens: Wenn ich irgendwo auf einer ziemlich guten DevOps-Reise bin, ein High-Performer, und ich bin irgendwo ein Chief of DevOps – in dem Fall bist du der Chief of DevOps –, was würdest du diesen Leuten empfehlen, um es weiter zu skalieren, vielleicht über das High-Performing-Team hinaus? Was sind einige Dinge, die sie tun sollten, um ihre Reise und Kultur in Richtung des grösseren Footprints von DevOps auszuweiten? Und – sorry, zur Klarstellung – ich meine es nicht aus einer Technologie- oder Prozessperspektive, sondern wirklich aus einer Menschen- und Kulturperspektive.\nRomano Roth 18:57 Du musst dich entlang des Wertstroms organisieren, das ist meiner Meinung nach wirklich die Magie. Du musst die Wertströme in deinem Unternehmen identifizieren, wie du Wert generierst, welche Schritte nötig sind und welche Leute darin sind, und dann diese Leute in diesen Wertströmen organisieren. Du kannst sie auch Produktteams nennen. Natürlich kann ein Wertstrom auch mehrere Produkte umfassen, aber es ist sehr wichtig, sich um diesen Wertstrom herum zu organisieren. Und zweitens ist es auch wichtig, die Leute zu befähigen – diesen Wertstrom zu befähigen, ihm Budget zu geben, sodass der Wertstrom selbst entscheiden kann, was nötig ist, um ein grossartiges Produkt oder mehrere grossartige Produkte für die Kunden zu machen. Und nun siehst du auch: Wir verlagern uns weg von Projekten, weg von «Wir brauchen diese 10 Features», hin zu einem Punkt, an dem die Kundin im Mittelpunkt steht und wir glückliche Kundinnen und Kunden, aber natürlich auch glückliche Mitarbeitende haben wollen. Wir konzentrieren uns also wirklich auf die Kundin und bauen absolut grossartige Produkte mit eingebauter Qualität. Das wäre meine Empfehlung: Sich entlang des Wertstroms organisieren, die Kundin in den Mittelpunkt stellen, KPIs an die Kundin und auch an die Mitarbeitendenzufriedenheit anpassen und die Leute in diesem Wertstrom wirklich befähigen, ihnen Budget und Entscheidungsbefugnis geben.\nEveline Oehrlich 20:54 Hervorragend. Ich wollte kurz auf ein Projekt hinweisen, an dem ich mit Helen Beal beteiligt bin – ich glaube, du kennst Helen, oder? Vielleicht kennst du sie nicht, dann musst du sie kennenlernen. Sie ist neben ihrer Rolle als Kollegin von mir am DevOps Institute auch Vorsitzende des Value Stream Consortium, was meiner Meinung nach das erste Mal überhaupt ist, seit ich in diesem Bereich tätig bin, dass eine Vielzahl von Anbietern zusammenkommt, gemeinsam forscht und gemeinsames Denken und Thought Leadership zu Value Stream Management anwendet. Eines der Projekte, die wir machen, ist – inzwischen das dritte Jahr – die Forschung zum «State of Value Stream Management». Helen hat erst kürzlich eine fantastische Sache gemacht, eine sogenannte PeerScape mit IDC. Wenn jemand zuhört, der «PeerScape IDC Value Stream Management» eingibt, sollte er das Video und das Gespräch zum Value Stream Management finden – eine fantastische Möglichkeit, zu lernen, wie man diese Reise startet. Und einer der Kunden dort war tatsächlich Netflix, ein Produktmanager von Netflix, der darüber gesprochen hat, wie sie Value Stream Management in ihrem Unternehmen umsetzen. Hervorragend. Also gut, ich schaue auf die Uhr – warum vergehen unterhaltsame Gespräche immer so schnell? Hol also deine Kristallkugel raus. Neben dem Gespräch über Value Stream Management hoffen wir, dass es immer mehr Interesse und Adoption dieses Produktdenkens und Value-Stream-Management-Denkens gibt. Aber wenn wir den Weg weitergehen – wenn wir es können –, wenn wir vielleicht zwei Jahre in die Zukunft schauen: Was denkst du? Was ist dann die Zukunft von DevOps? Zwei Jahre – das ist 2025. Wenn du und ich irgendwo in Zürich sitzen, eine Tasse Kaffee oder Cappuccino oder ein erwachsenes Getränk – egal – trinken: Was würden wir dann in DevOps sehen?\nRomano Roth 23:00 Was wir aktuell klar sehen können, ist Platform Engineering. Bei all dem Tooling kommt viel Standardisierung – man sieht es nicht ganz klar, es ist mehr unter der Haube –, aber wir gehen in einen Bereich, in dem die Softwareentwicklung standardisiert wird. Meiner Meinung nach wird sie industrialisiert. Wir gehen weg davon, immer wieder das Rad neu zu erfinden, hin zu einer Richtung, in der man verschiedene Dinge zusammen verwendet, und sie passen zusammen, weil sie standardisiert sind. Meiner Meinung nach werden wir den Aufbau digitaler Fabriken sehen. Man kann bereits sehen, dass Unternehmen zusammen mit Platform Engineering ihre eigenen digitalen Fabriken aufbauen, in denen die Teams entlang des Wertstroms organisiert sind und digitale oder cyber-physische Produkte produzieren. Und das Plattform-Engineering-Team stellt das Förderband für diese digitalen Fabriken in den Unternehmen bereit. Meine Vorhersage ist also: Wir werden viele digitale Fabriken entstehen sehen.\nEveline Oehrlich 24:22 Ich würde mit dir wetten – aber ich stimme dir zu. Also kaufe ich den Drink, weil ich einen Kaffee oder eine Tasse Tee bestellt habe. Nein, ich stimme dir zu. Das ist ein grossartiges Gespräch – digitale Fabriken. Das ist etwas, das ich gerne weiter erkunden würde. Aber nicht heute. Wirklich, wirklich grossartiger Einblick. Ich liebe diese Kristallkugel-Vision, die du für die Zukunft hast. Für mich – nein, das war grossartig. Jetzt habe ich noch eine Frage. Es ist eine Abschlussfrage. Sie hat nichts mit digitalen Fabriken, DevOps oder einem dieser Begriffe zu tun. Was machst du zum Spass?\nRomano Roth 24:57 Oh, ich liebe es, um die Welt zu reisen. Ich liebe es, neue Länder zu sehen, und in diesen Ländern mache ich viel Fotografie. Ich habe auch meinen Instagram-Kanal und einen zweiten YouTube-Kanal, auf dem ich derzeit auch einige Videos poste. Ich mache aktuell viele 360-Grad-Videos, die ich liebe. Und natürlich liebe ich es, Computerspiele zu spielen, und ich lese auch viel.\nEveline Oehrlich 25:27 Fantastisch. Wenn du es jemals in meine Region schaffst – ich bin nur etwa anderthalb Stunden nördlich von dir –, schau vorbei, gib mir Bescheid. Wir gehen reisen und du kannst 360-Grad-Videos machen. Ich werde mir die Videos ansehen, die du gemacht hast. Vielen Dank. Wir haben mit Romano Roth gesprochen, Chief of DevOps bei Zühlke, einer Software-Consulting-Organisation. Er macht viel Arbeit und Thought Leadership, also schaut ihn euch an. Romano, vielen Dank, dass du heute beim Humans of DevOps Podcast dabei warst. Danke, dass ich dabei sein durfte. Der Humans of DevOps Podcast wird vom DevOps Institute produziert. Unser Audio-Produktionsteam umfasst Julia Pape, Daniel Newman Schultz und Brendan Lee. Shout-out an meine wunderbaren Kolleginnen und Kollegen. Ich bin Eveline, Executive Producer des Humans of DevOps Podcast. Wenn ihr bei einem Podcast dabei sein möchtet, kontaktiert uns unter dieser sehr langen E-Mail: humansofdevopspodcast@devopsinstitute.com. Ich bin Eveline – wir sprechen uns bald.\nNarrator 26:42 Danke, dass Sie diese Episode des Humans of DevOps Podcast gehört haben. Vergessen Sie nicht, unserer globalen Community beizutreten, um Zugang zu noch mehr grossartigen Ressourcen wie dieser zu erhalten. Bis zum nächsten Mal: Denken Sie daran, Sie sind Teil von etwas, das grösser ist als Sie selbst. Sie gehören dazu.\nOriginalbeitrag: DevOps Institute: EP101: DevOps Is NOT Dead\n","date":"10. May 2023","externalUrl":null,"permalink":"/de/blogs/devops-ist-nicht-tot/","section":"Blogs","summary":" Begleiten Sie Eveline Oehrlich und Romano Roth bei der Diskussion, ob DevOps tot ist.\nTranskript # Narrator 00:02 Sie hören den Humans of DevOps Podcast, einen Podcast, der darauf ausgerichtet ist, die Menschen im DevOps-Umfeld durch Fähigkeiten, Wissen, Ideen und Lernen weiterzubringen – das SKIL-Framework.\n","title":"DevOps ist NICHT tot","type":"blogs"},{"content":"","date":"19 April 2023","externalUrl":null,"permalink":"/en/tags/dast/","section":"Tags","summary":"","title":"DAST","type":"tags"},{"content":"","date":"19 April 2023","externalUrl":null,"permalink":"/en/tags/dynamic-application-security-testing/","section":"Tags","summary":"","title":"Dynamic Application Security Testing","type":"tags"},{"content":"After seven sessions of static analysis — SCA, license compliance, SAST, container scanning, secret detection — Patrick Steger and I move into the dynamic side of the pipeline. In Part 8 we add Dynamic Application Security Testing to our GitHub Actions pipeline. DAST runs the application and then attacks it. GitHub does not ship this out of the box, so we wire in a community action built on OWASP ZAP — and we are honest about where that approach falls short for enterprise use.\nWhat DAST Means for Us # In Dynamic Application Security Testing we run our own application and then attack it. All of it automated. We need a tool that scans and attacks an application running either inside the pipeline or somewhere on the internet or on-premises. GitHub does not provide a first-party DAST capability, so we go to the marketplace and find a suitable action. The one we land on is the action-full-scan provided by the ZAP team — based on the well-known OWASP ZAP open source tool.\nWe use it out of the box, no custom ZAP configuration. For an enterprise application this is rarely good enough — proper ZAP configuration is its own project. Interestingly, in our case the standard configuration produced more and better findings than what we got on the other platform we covered.\nUp Front: The Drawbacks # Before showing the workflow, Patrick names the limitations honestly. First and worst: ZAP findings are not visible in the GitHub vulnerability management UI. The reason is missing SARIF support — SARIF is the format GitHub expects in order to render findings in its security dashboard. Second, we did not customise the ZAP configuration, so findings are somewhat random. Third, we run the test against a Docker container started inside the pipeline rather than against a real cloud deployment. ZAP can absolutely scan a real deployed URL — we just skipped the deploy-to-Azure step to keep the demo focused.\nThe Workflow # The DAST workflow can be triggered two ways: manually via workflow_dispatch, or as part of the overall pipeline via workflow_call. Either way it requires one parameter — the image tag — plus the two familiar environment variables for the container registry and image name.\nThe job runs on ubuntu-latest and does the following: check out the repo, log into the registry, pull the image, docker run the container, wait for it to start, and probe it to make sure it actually responds in a meaningful way. With the application running, we kick off the ZAP scan using action-full-scan. We provide the target URL, and we pass a couple of CLI options — among them an extra ajax spider to find more endpoints, and a reduced log level so the console stays readable.\nWe also disable an option that would otherwise open a GitHub issue for every scan. That might be fine for a single-person side project; in an enterprise context it is unusable. After the scan we upload the HTML report as a workflow artifact and stop the container. We would have preferred to upload SARIF, but at the time of recording that was not supported by the action and would have meant building it ourselves.\nCalling It from the Main Pipeline # The DAST workflow is wired into the orchestrator as a job that depends on build and docker. It calls the workflow we just defined, passes the secrets, and consumes the image-tag output from the docker job so it tests exactly the artifact that was built upstream.\nThe Report # When the pipeline runs, the new DAST job appears in the run view. The log shows the registry login, the docker run, the wait-and-probe step, then the full ZAP scan with the exact command line and the most important findings on WARN level. At the end the HTML report is attached as an artifact.\nOpening the report shows a real finding immediately — a cross-site scripting issue on a URL parameter. We know from the source that the vulnerability is genuine, so the scanner did its job. The catch, again, is that the only delivery is an HTML file. There is no triage flow, no dismiss-as-false-positive, no integration with the rest of GitHub security.\nThe Issue Option Is Not the Answer # There is a flag on the action to file the findings as a GitHub issue. We try it, and a ZAP Full Scan Report issue gets created listing every problem. It looks helpful for thirty seconds. Then you realise that every run files a new issue, with no memory of what you already fixed or marked as not relevant. In an enterprise setting that becomes noise immediately and gets ignored within days. What we actually want is an entry in the Security tab — like Code Scanning — where findings are first-class objects you can manage. SARIF support is what would unlock that.\nRecap # DAST in GitHub today: run the container with your application (in the pipeline for the demo, in the cloud for real systems), run a second container with OWASP ZAP that attacks it, collect the findings, upload an HTML report. It works, it finds real vulnerabilities, and it has two real drawbacks — DAST is hard to configure well, and the GitHub-side integration is limited to an HTML artifact or a noisy auto-issue. In the next video we will look at Vulnerability Management.\nKey Takeaways # GitHub has no first-party DAST. You go to the marketplace. The community OWASP ZAP action-full-scan is the practical choice today, used out of the box for the demo and tuned heavily for any real product.\nDAST needs a running target. We run the container in the pipeline to keep the demo simple. In a real enterprise pipeline the container is deployed to a cloud environment first and ZAP scans the live URL.\nNo SARIF means no native dashboard. Without SARIF output the findings do not show up in GitHub vulnerability management. You get an HTML artifact, which is fine for inspection but not for triage at scale.\nThe auto-issue option is a trap. Filing a GitHub issue per scan means every run re-creates everything you already triaged. It is an option for tiny projects only — for enterprise pipelines, do not enable it.\nWait-and-probe before you scan. Start the container, wait for it, and make sure it actually answers. Otherwise ZAP scans nothing and you ship a green pipeline that proved nothing.\nDefault ZAP configuration is a starting point, not the goal. It found a real XSS in our demo, which is encouraging — but high-quality DAST in production needs deliberate ZAP tuning. Plan that as its own work item.\n","date":"19 April 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-dast/","section":"Blogs","summary":"After seven sessions of static analysis — SCA, license compliance, SAST, container scanning, secret detection — Patrick Steger and I move into the dynamic side of the pipeline. In Part 8 we add Dynamic Application Security Testing to our GitHub Actions pipeline. DAST runs the application and then attacks it. GitHub does not ship this out of the box, so we wire in a community action built on OWASP ZAP — and we are honest about where that approach falls short for enterprise use.\n","title":"GitHub DevSecOps Part 8: Dynamic Application Security Testing (DAST)","type":"blogs"},{"content":"","date":"19 April 2023","externalUrl":null,"permalink":"/en/tags/owasp-zap/","section":"Tags","summary":"","title":"OWASP ZAP","type":"tags"},{"content":"","date":"19 April 2023","externalUrl":null,"permalink":"/en/tags/penetration-testing/","section":"Tags","summary":"","title":"Penetration Testing","type":"tags"},{"content":"","date":"21. March 2023","externalUrl":null,"permalink":"/de/tags/branchen-einblicke/","section":"Tags","summary":"","title":"Branchen-Einblicke","type":"tags"},{"content":" In Episode 88 von DevTalk spreche ich mit Kerry W. Lothrop über den Stand von DevOps.\nOriginalbeitrag: DevTalk 88: Romano Roth\n","date":"21. March 2023","externalUrl":null,"permalink":"/de/blogs/devtalk-podcast-episode-88-stand-von-devops-mit-romano-roth/","section":"Blogs","summary":" In Episode 88 von DevTalk spreche ich mit Kerry W. Lothrop über den Stand von DevOps.\nOriginalbeitrag: DevTalk 88: Romano Roth\n","title":"DevTalk Podcast Episode 88: Der Stand von DevOps. Mit Romano Roth","type":"blogs"},{"content":" On episode 88 of DevTalk I and Kerry W. Lothrop speak about the state of DevOps.\nOriginal Post: DevTalk 88: Romano Roth\n","date":"21 March 2023","externalUrl":null,"permalink":"/en/blogs/devtalk-podcast-episode-88-the-state-of-devops-with-romano-roth/","section":"Blogs","summary":" On episode 88 of DevTalk I and Kerry W. Lothrop speak about the state of DevOps.\nOriginal Post: DevTalk 88: Romano Roth\n","title":"DevTalk Podcast Episode 88: The state of DevOps. With Romano Roth","type":"blogs"},{"content":"","date":"21 March 2023","externalUrl":null,"permalink":"/en/tags/industry-insights/","section":"Tags","summary":"","title":"Industry Insights","type":"tags"},{"content":"In today\u0026rsquo;s world, everybody wants to do DevOps. But why? What problems are we trying to solve?\nTaking a Step Back # Together, we will take a step back and look at the bigger picture. Instead of jumping straight into tools and practices, we examine the systems and value streams that underpin modern software delivery.\nSystems Thinking # DevOps is not just about tools or automation. It is about understanding the system you operate in. How does work flow through your organization? Where are the bottlenecks? What feedback loops exist, and which ones are missing?\nArchitecting for Continuous Delivery # With a systems perspective, we can architect our products and processes for continuous delivery. This means designing not just CI/CD pipelines, but the entire product architecture to support frequent, reliable releases.\n","date":"6 March 2023","externalUrl":null,"permalink":"/en/speaking/devops-thinking-in-systems-and-value-streams/","section":"Speaking","summary":"In today’s world, everybody wants to do DevOps. But why? What problems are we trying to solve?\nTaking a Step Back # Together, we will take a step back and look at the bigger picture. Instead of jumping straight into tools and practices, we examine the systems and value streams that underpin modern software delivery.\n","title":"DevOps: Thinking in Systems \u0026 Value Streams","type":"speaking"},{"content":"","date":"14 February 2023","externalUrl":null,"permalink":"/en/tags/github-advanced-security/","section":"Tags","summary":"","title":"GitHub Advanced Security","type":"tags"},{"content":"API keys, tokens, and passwords still leak into repositories all the time — sometimes by accident, sometimes by a developer who genuinely did not know better. In Part 7 of our GitHub DevSecOps series, Patrick Steger and I switch on GitHub\u0026rsquo;s built-in Secret Scanning, add a custom pattern of our own, try out push protection, and look honestly at what the feature finds and where it falls short.\nBuilt In, Not Bolted On # Unlike everything we have wired up so far, Secret Scanning is not a separate tool you bring to GitHub — it is functionality you turn on inside GitHub itself. Configuration lives in the repository settings, not in a workflow YAML.\nThere is a catch around licensing: Secret Scanning is enabled automatically and free for public repositories — and mandatory there. For private repositories, you need GitHub Enterprise with the Advanced Security add-on. Worth knowing before you plan it across an organisation.\nWhat It Scans and What \u0026ldquo;Found\u0026rdquo; Means # Once enabled, GitHub scans every source and configuration file in the repository — and the git history — for known secret patterns: API keys, cloud tokens, anything that matches one of the patterns GitHub maintains. When it finds something, the only meaningful response is to revoke and rotate. A leaked secret cannot be un-leaked by deleting the file.\nPatrick makes the same point I always come back to: in DevOps we say everything is source code and belongs in the repo, but that is exactly where secrets must not go. They belong in a place built for them — the Secrets area in the repository settings, or an external store like Azure Key Vault, which GitHub supports out of the box.\nTurning It On # Enabling Secret Scanning takes a couple of clicks. In Settings → Code security and analysis, scroll to GitHub Advanced Security and switch on Secret scanning. While we are there, we also enable Push protection, which is supposed to block pushes that contain newly added secrets before they ever reach the remote.\nGitHub will scan the repository history first, which can take a while, and report findings in two places: the Security tab under Secret scanning, and email notifications to whoever you configure as a recipient.\nDefining a Custom Pattern # GitHub ships with a long list of supported secret formats from many partners, but you can also add your own. We click New pattern, name it, and define the format — anything that starts with pwd_ for our test. The UI lets you test the regex against sample input first, and you can save it as a dry run so the results land in your inbox without going live.\nAfter we publish the pattern, we add a couple of pwd_ strings to the controller and commit. Heading back to Security → Secret scanning, we see both test secrets flagged. Custom patterns work.\n\u0026ldquo;Where Are the Other Secrets?\u0026rdquo; # When I open the controller file we have been hacking on through this series, there are still several hard-coded credentials in there — but only the pwd_ ones we just added are showing up. Why?\nBecause the AKIA… AWS-style identifier we have been using is not in GitHub\u0026rsquo;s predefined pattern list. Azure storage account access keys are. So the answer to \u0026ldquo;what does GitHub find?\u0026rdquo; is simple: whatever the predefined list and your custom patterns cover. Everything else is invisible to Secret Scanning.\nTrying Out Push Protection # To test Push Protection, we add an Azure storage account access key and another pwd_ value, then commit and push. The expectation is that GitHub blocks the push before it reaches the remote.\nIt does not. The commit lands in the repository. We dig around and find the answer on GitHub\u0026rsquo;s docs: at recording time, push protection was still in beta, and despite the toggle being available in the UI, it was not actually enforcing anything yet. The good news is that Secret Scanning still picks up both secrets after the fact, so the Security → Secret scanning tab shows them with the message that the credentials are compromised and must be rotated. The Azure key, of course, then needed to be revoked.\nKey Takeaways # Secret Scanning is a setting, not a tool you install. Toggle it on in Settings → Code security and analysis. No workflow file to edit, no marketplace action to choose.\nFree on public, paid on private. Public repositories get Secret Scanning automatically. Private repositories need GitHub Enterprise with Advanced Security. Factor that into your platform plan.\nCustom patterns are powerful and easy. If GitHub does not ship a pattern for the credentials your stack uses, define your own, dry-run it through email, then publish. The UI even lets you test the regex inline.\nCoverage is only as broad as the pattern list. GitHub finds what it knows. Anything outside the predefined list and your custom patterns is invisible. Audit the supported list against the credentials your code actually uses.\nSecrets belong in the secrets area or a Key Vault. GitHub provides a protected secrets section in repository settings and integrates with Azure Key Vault out of the box. That is where credentials go — not into config files or constants.\nPush protection is great in theory; verify it actually works for you. At our recording, it was still beta and silently let pushes through. Always confirm critical security controls are enforcing, not just enabled.\n","date":"14 February 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-secret-detection/","section":"Blogs","summary":"API keys, tokens, and passwords still leak into repositories all the time — sometimes by accident, sometimes by a developer who genuinely did not know better. In Part 7 of our GitHub DevSecOps series, Patrick Steger and I switch on GitHub’s built-in Secret Scanning, add a custom pattern of our own, try out push protection, and look honestly at what the feature finds and where it falls short.\n","title":"GitHub DevSecOps Part 7: Finding Secrets in Your Code with Secret Scanning","type":"blogs"},{"content":"","date":"14 February 2023","externalUrl":null,"permalink":"/en/tags/push-protection/","section":"Tags","summary":"","title":"Push Protection","type":"tags"},{"content":"","date":"14 February 2023","externalUrl":null,"permalink":"/en/tags/secret-scanning/","section":"Tags","summary":"","title":"Secret Scanning","type":"tags"},{"content":"","date":"9 February 2023","externalUrl":null,"permalink":"/en/tags/container-scanning/","section":"Tags","summary":"","title":"Container Scanning","type":"tags"},{"content":"","date":"9 February 2023","externalUrl":null,"permalink":"/en/tags/containers/","section":"Tags","summary":"","title":"Containers","type":"tags"},{"content":"","date":"9 February 2023","externalUrl":null,"permalink":"/en/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"We have built up the GitHub Actions pipeline through five sessions: the project basics, software composition analysis, license compliance, and static application security testing. The next layer is container scanning — looking for vulnerabilities inside the Docker image we ship, not just in the source we wrote. In Part 6 of our series, Patrick Steger and I split the work into two GitHub Actions sub-workflows: one builds the image and pushes it to the registry, the other pulls it back and runs Trivy on it.\nWhat Container Image Scanning Covers # Container image scanning looks for vulnerabilities in everything that ends up inside the Docker image — both operating system components and the application libraries you bring in. That overlap with SCA is by design, and Patrick calls it out upfront: most findings from container scanning will already have been flagged by software composition analysis on the source dependencies. You can configure that overlap away if it bothers you, but we leave it on the default in this video and accept the duplication for completeness.\nTwo Sub-Workflows: Build and Scan # The pattern we use in this series is to keep the main pipeline lean and push real work into separate workflow files. For container scanning, that means two new sub-jobs:\nA build Docker image job that creates the image and stores it in the GitHub Container Registry. It outputs the image tag. A container image scan job that takes that tag as input, pulls the image, scans it with Trivy, and pushes the findings into the GitHub Security tab. In the main pipeline, the Docker job depends on the build job (we need the compiled application jar inside the image). The scan job declares the Docker job as a prerequisite and reads the image tag from its outputs. By naming both jobs starting with \u0026ldquo;D\u0026rdquo;, they sort nicely at the bottom of the GitHub Actions UI.\nThe Build Docker Image Job # The build job lives in docker.yml. It can be triggered manually or called from the main workflow. We declare an outputs: block at the workflow and job level that surfaces the image tag for downstream consumers. We also declare the container registry and the image name as inputs.\nThe steps are straightforward: check out the source so we have the Dockerfile, download the prebuilt application binary from the earlier build step, log in to the container registry using the credentials GitHub provides, extract Docker metadata (tags, labels), and then build and publish the image with the docker/build-push-action. The tag we publish under is the same one we expose as the job\u0026rsquo;s output.\nThe Container Scan Job # The scan job lives in its own file too. It can be started manually if you supply the image tag, or called from the main pipeline — which is what we do here, passing the tag from the build job. The steps log in to the container registry, docker pull the image, and run Trivy against it. The most important option is the output format: we set it to SARIF so GitHub can ingest it natively. The final step uploads the SARIF file with the standard github/codeql-action/upload-sarif action, which makes the findings show up in the Security tab.\nReviewing Findings in GitHub # After the run we head to the Security tab → Code scanning and filter by tool — Trivy. A lot of the findings sit inside app.jar. Those are our application\u0026rsquo;s own dependencies, the same set SCA already flagged in an earlier session. There are also genuinely new findings from the OS layer — Patrick points to one in an SSL library as an example. Container scanning added roughly a hundred new entries on top of what we already had.\nWhat to Do With All Those Findings # Patrick\u0026rsquo;s advice is unambiguous: the default action is to fix them, and \u0026ldquo;fix\u0026rdquo; almost always means update the libraries. Updating a vulnerable dependency removes the finding from Trivy and from the SCA scanner in one move. If you do not want the duplicates between SCA and the container scan, you can exclude app.jar from Trivy — but that is cosmetics, not security.\nWhen updating is not an option, the work begins. You need to assess whether the vulnerability actually affects your application, judge the residual risk, and then decide on a workaround, an accepted-risk decision, or — if the risk is high enough — taking the application offline. Patrick says it twice for emphasis: default action is remediate. We will cover how to manage and triage vulnerabilities inside GitHub in a later session.\nKey Takeaways # Scan the image, not just the source. SAST and SCA inspect what you wrote and what you depend on. Container scanning checks the OS layer and everything that landed inside the image. Without it, you ship vulnerabilities you never tested for.\nSplit build and scan into two workflows. One job builds and publishes the image and exposes the tag. The other consumes the tag and scans. Clean inputs and outputs make the dependency obvious and the files reusable.\nSARIF is the integration that matters. Configure Trivy to emit SARIF and upload it with upload-sarif. That single choice is what puts the findings into the Security tab where developers actually see them.\nExpect overlap with SCA. Most container findings will already be in your SCA report. That is normal. Pick one as the source of truth or filter app.jar out of Trivy — but do not panic at the duplication.\nDefault action: update the library. A version bump usually clears findings in both Trivy and SCA. Workarounds and risk acceptance are fallbacks, not first moves.\nTriaging takes process, not tooling. When you cannot update, you need impact analysis, risk assessment, and an explicit decision. Tooling surfaces the issue; people decide what to do with it. Manage that workflow deliberately, not by ad-hoc Slack threads.\n","date":"9 February 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-container-scanning/","section":"Blogs","summary":"We have built up the GitHub Actions pipeline through five sessions: the project basics, software composition analysis, license compliance, and static application security testing. The next layer is container scanning — looking for vulnerabilities inside the Docker image we ship, not just in the source we wrote. In Part 6 of our series, Patrick Steger and I split the work into two GitHub Actions sub-workflows: one builds the image and pushes it to the registry, the other pulls it back and runs Trivy on it.\n","title":"GitHub DevSecOps Part 6: How to Use Container Scanning","type":"blogs"},{"content":"","date":"9 February 2023","externalUrl":null,"permalink":"/en/tags/trivy/","section":"Tags","summary":"","title":"Trivy","type":"tags"},{"content":"","date":"1 February 2023","externalUrl":null,"permalink":"/en/tags/codeql/","section":"Tags","summary":"","title":"CodeQL","type":"tags"},{"content":"SCA covered our dependencies. License compliance covered what we are allowed to ship. SAST is where we point the scanners at the code we wrote ourselves. In Part 5 of our GitHub DevSecOps series, Patrick Steger and I add Static Application Security Testing to the pipeline — and find out the hard way that on GitHub it takes three Actions, not one.\nWhy Three Tools # SAST is about finding security flaws in your own source code, not in your dependencies. On GitHub we ended up wiring in three scanners:\nCodeQL — GitHub\u0026rsquo;s own static analysis engine, provided as a standard Action. SpotBugs — a long-established Java scanner, strong on traditional code-quality and security rules. Semgrep — a newer pattern-based scanner; the Action is provided directly by the Semgrep team. Three scanners on a sample project sounds excessive. For a real company codebase it is a reasonable starting point. Each has different strengths and blind spots, and even with all three running we still missed findings that other platforms caught easily. There is no single GitHub Action today that covers SAST end-to-end at a sensible price, so layering tools is the pragmatic path.\nA second wrinkle: many SAST scanners on the Marketplace require extra accounts and do not write findings into the GitHub Security tab by default. Getting SpotBugs results into the Security tab needed a custom Action — Juan Manuel from Microsoft helped us convert SpotBugs output into SARIF, the standardized format the Security tab understands.\nWiring SAST into the Pipeline # We use the same pattern as before: a sast.yml workflow called from the main pipeline. It declares three jobs — Sast-CodeQL, Sast-SpotBugs, and Sast-Semgrep — and it can be triggered manually via workflow_dispatch or invoked from the main pipeline.\nCodeQL. Standard runs-on: ubuntu, the permissions the Action needs (which we figured out by reading the Marketplace docs and a bit of trial and error), fail-fast: false so the whole job runs through, and a matrix that pins the language to Java for speed. The steps check out the code, initialize CodeQL, set up JDK 11, build the project, and run the analyzer. We rebuild here, but a real pipeline could reuse the artifact from the build job.\nSpotBugs. Same skeleton — name, runner, permissions, steps — plus a needs: Sast-CodeQL dependency so it can use the cache populated by the CodeQL job. After running SpotBugs, we upload the artifacts and then run the special SARIF upload step so findings appear in the Security tab.\nSemgrep. Runs inside Semgrep\u0026rsquo;s own Docker container, takes a needs dependency for the cache, checks out the code, and runs the scanner with an explicit ruleset. For Java that ruleset is roughly 110 rules — enough to find real issues, but a fraction of what dedicated commercial tooling ships with.\nWhat the Scanners Found # Once the pipeline ran, the new jobs showed up in Actions, and the SARIF artifacts (Semgrep.sarif, SpotBugs.sarif) were attached to the run. Filtering the Security tab by tool:\nCodeQL: two findings. Use of broken or risky cryptography — older MD5 hashing. And cross-site scripting — we return the caller\u0026rsquo;s message back to the caller, a textbook reflected XSS. Semgrep: three findings. The MD5 issue twice (it matches two rules), plus a Docker recommendation to run the container as a dedicated user instead of root. SpotBugs: zero findings on this project. What the Scanners Missed # The controller we deliberately broke also contains hardcoded passwords and secrets — those we expect secret scanning to catch in a later session. More worrying: an obvious use of the standard Random to generate a key, and a static-material-derived keybytes constant. Both are easy-to-spot weaknesses, both went unflagged. With combined commercial tooling on another platform, we found these without effort. Here we did not.\nThe honest summary: GitHub SAST works, the SARIF integration into the Security tab is genuinely useful, but expect to invest in extra rules or custom scanners if you need parity with what other platforms surface out of the box.\nKey Takeaways # One Action is not enough. No single GitHub SAST Action covers everything affordably. We layered CodeQL, SpotBugs, and Semgrep — and even then we missed findings other platforms catch.\nSARIF is the price of admission. If a scanner does not emit SARIF, its findings will not show up in the GitHub Security tab. For SpotBugs we needed a custom Action to convert output. Check this before you adopt a tool.\nPermissions are trial-and-error. Each Action declares the GitHub permissions it needs. Documentation is uneven; expect a few iterations before the workflow runs cleanly.\nCache between scanner jobs. Use needs: and the actions/cache action to share the compiled Java and dependencies between CodeQL, SpotBugs, and Semgrep. Otherwise you pay the build cost three times.\nPin the language matrix. CodeQL can scan many languages. Restricting the matrix to the languages you actually ship — Java in our case — keeps pipeline time down. Add languages explicitly when you need them.\nExpect gaps. MD5 and reflected XSS were caught. A Random-generated key and static key material were not. Treat the default GitHub SAST setup as a baseline, not as completeness — and budget for custom rules or commercial scanners where the risk justifies it.\n","date":"1 February 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-sast/","section":"Blogs","summary":"SCA covered our dependencies. License compliance covered what we are allowed to ship. SAST is where we point the scanners at the code we wrote ourselves. In Part 5 of our GitHub DevSecOps series, Patrick Steger and I add Static Application Security Testing to the pipeline — and find out the hard way that on GitHub it takes three Actions, not one.\n","title":"GitHub DevSecOps Part 5: Static Application Security Testing (SAST)","type":"blogs"},{"content":"","date":"1 February 2023","externalUrl":null,"permalink":"/en/tags/sast/","section":"Tags","summary":"","title":"SAST","type":"tags"},{"content":"","date":"1 February 2023","externalUrl":null,"permalink":"/en/tags/semgrep/","section":"Tags","summary":"","title":"Semgrep","type":"tags"},{"content":"","date":"1 February 2023","externalUrl":null,"permalink":"/en/tags/spotbugs/","section":"Tags","summary":"","title":"SpotBugs","type":"tags"},{"content":"","date":"1 February 2023","externalUrl":null,"permalink":"/en/tags/static-application-security-testing/","section":"Tags","summary":"","title":"Static Application Security Testing","type":"tags"},{"content":"GitHub does not ship a license scanner out of the box, and when we went looking in the marketplace, none of the existing actions did what we needed. So we built our own with a colleague from Microsoft and published it. In Part 4 of our GitHub DevSecOps series, Patrick Steger and I plug that License Finder action into our Spring Boot pipeline, configure which licenses are acceptable, and show how to surface the results inside GitHub.\nWhy License Compliance, Even on a \u0026ldquo;Simple\u0026rdquo; Project # Patrick gives the same answer he gave for SCA. Our Java program uses Spring Boot, and Spring Boot pulls in dozens of libraries. Each comes with a license, and licenses come with rules — what you can do, what you cannot do, what you have to disclose. To stay compliant you have to know what you are using and decide which licenses you accept.\nHow We Got to a License Finder Action # GitHub does not provide a built-in license scanner. The path is the same as for SCA: pick something from the marketplace. Nothing there fit. Together with our colleague Juan Manuel from Microsoft, we wrote a GitHub Action that wraps the Pivotal License Finder open source project. It is published in the marketplace under the name License Finder, and that is what we use here. The action is in alpha, and there is no easy in-UI view of all licenses used — that lives in the log output.\nHow the Action Works # Once it is in your workflow the flow is straightforward. The action scans every dependency in your project, looks for the license file, compares each license to a configured list of permitted ones, reports non-compliant licenses as test results in the GitHub UI, and fails the build when a license outside the allowed list shows up. That last bit is what makes it a real gate rather than a passive report.\nA Sub-Workflow, Not a Step in the Main One # Rather than bolt license compliance onto the main pipeline, we add it as a separate sub-workflow. We define a new workflow file called License Compliance and trigger it from the main pipeline (and optionally manually). The job checks out the code and runs the License Finder action. One small fix is needed: you have to remove the Maven file before the action runs, otherwise License Finder does not start cleanly.\nConfiguring Permitted Licenses # The action takes two key parameters. permitted-licenses is the list of licenses you accept — for the demo we started with MIT and Apache-2.0 so we would deliberately get findings. approved-dependencies is the list of libraries that ship without a license file at all but that you have decided are fine. For simplicity we added every Spring Boot dependency without a license file to that list. In a real project that decision deserves more care.\nSurfacing the Results in GitHub # License Finder produces a unit test report file. We feed that to the publish-unit-test-result action — the same one we used in earlier sessions — but with one tweak: we rename the report to License Compliance Check so that it shows up in the GitHub UI under that name rather than as a generic test result. We also upload the full report as a downloadable artifact so anyone can grab the raw output as a zip.\nWhat the First Run Showed # The pipeline ran, the License Compliance Check appeared in the workflow, and the check told us it had found 55 libraries — five of them with licenses outside our allowed list. Drilling into the raw output we saw one BSD-licensed library, one with CDDL + GPLv2, and three using Eclipse Public License 1.0. None of those are problematic for our use case, so we added them to the allowed list. After a re-run the check went green and all 55 libraries passed.\nWho Decides What Is Acceptable? # I asked Patrick the obvious question: who actually decides which licenses get added to the allow list? His answer: depends on the company. In some organisations a central architecture or security department owns the policy. In others it sits with the project — typically the tech lead, who also keeps a security risk list. The tool does not answer this for you. It just enforces whatever policy you configure, so make sure someone owns that policy.\nWhat This Pipeline Buys You # With the License Finder action plus a small sub-workflow you get a scanner that runs on every pipeline, fails the build on unapproved licenses, surfaces results as a check inside GitHub, and lets anyone download the raw report. Compared to GitLab\u0026rsquo;s built-in template this takes more setup, but the end result is the same: a license question answered automatically on every commit.\nKey Takeaways # GitHub has no built-in license scanner. You go to the marketplace. When nothing fits, you write your own action — that is exactly how the License Finder action we use was created.\nRun it as a sub-workflow. Keeping license compliance in its own workflow file makes it easy to reuse, trigger manually, and reason about independently from the main build.\nPermitted-licenses and approved-dependencies do different jobs. One is the policy on licenses you accept; the other handles libraries that ship without a license file at all. Treat both with intent.\nRename the test report. Publishing the License Finder output through the unit test action makes it visible in the UI, but only if you give it a meaningful name — otherwise it disappears as another \u0026ldquo;test result\u0026rdquo;.\nThe policy needs an owner. Tooling enforces the allow list; it does not decide what belongs in it. Pick the role — central security, central architecture, tech lead — and make the responsibility explicit.\nMind the alpha-state caveats. Our action is in alpha, and there is no nice \u0026ldquo;all licenses used\u0026rdquo; view inside GitHub — you have to read the log. Plan around it; do not be surprised by it.\n","date":"25 January 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-license-compliance/","section":"Blogs","summary":"GitHub does not ship a license scanner out of the box, and when we went looking in the marketplace, none of the existing actions did what we needed. So we built our own with a colleague from Microsoft and published it. In Part 4 of our GitHub DevSecOps series, Patrick Steger and I plug that License Finder action into our Spring Boot pipeline, configure which licenses are acceptable, and show how to surface the results inside GitHub.\n","title":"GitHub DevSecOps Part 4: How to Ensure License Compliance","type":"blogs"},{"content":"","date":"25 January 2023","externalUrl":null,"permalink":"/en/tags/license-compliance/","section":"Tags","summary":"","title":"License Compliance","type":"tags"},{"content":"","date":"25 January 2023","externalUrl":null,"permalink":"/en/tags/license-finder/","section":"Tags","summary":"","title":"License Finder","type":"tags"},{"content":"","date":"19 January 2023","externalUrl":null,"permalink":"/en/tags/dependabot/","section":"Tags","summary":"","title":"Dependabot","type":"tags"},{"content":"","date":"19 January 2023","externalUrl":null,"permalink":"/en/tags/dependency-scanning/","section":"Tags","summary":"","title":"Dependency Scanning","type":"tags"},{"content":"GitHub does not ship a default SCA tool the way GitLab does. You have to combine two things: a platform feature called Dependabot and an SCA action from the Marketplace. In Part 3 of the GitHub DevSecOps series, Patrick Steger and I wire both into our pipeline — and find out the hard way that the Marketplace path is not as smooth as the slides suggest.\nWhat SCA Is and Why You Need Both Approaches # Software Composition Analysis — also called dependency scanning — finds known vulnerabilities in the libraries your application uses. If a library has a CVE and you depend on it, your application carries that CVE. New CVEs against existing libraries get discovered all the time, so a one-shot scan is not enough. You need scans on every commit and scans on a schedule against unchanged code.\nOn GitHub that means two complementary tools. A pipeline-side SCA action gives you scan-on-commit under your direct control. A platform feature called Dependabot gives you continuous scanning, alerts, and auto-generated fix pull requests independent of your commits. The combination usually finds things either tool misses on its own.\nEnabling Dependabot # Dependabot is a GitHub feature, not a workflow. You enable it under Settings → Code security and analysis. First switch on the dependency graph — that is what builds the inventory of your dependencies. Then enable Dependabot alerts (so GitHub tells you when a new CVE matches one of your dependencies) and Dependabot security updates (so it opens pull requests with the upgrade already prepared).\nThere is a third option, Dependabot version updates, which opens PRs for any new minor version regardless of CVE. We left it off — every minor upgrade as a PR turns into noise quickly.\nOnce enabled, Dependabot scans the repo in the background. Insights → Dependency graph shows you the inventory: our pom.xml lit up with maven-surefire, Spring Boot, and — pleasingly — even the GitHub Actions our workflows depend on. The Security tab is where Dependabot alerts appear if they exist.\nAdding an SCA Action to the Pipeline # There is no first-party GitHub SCA action, so we go to the Marketplace and pick CRDA — CodeReady Dependency Analysis from Red Hat, which uses Snyk under the hood. We also need to enable GitHub Advanced Security under Settings → Code security and analysis (this is paid for private repos) so the scan results show up in the Security tab.\nWe add an sca step to the main pipeline that calls a separate sca.yml workflow and inherits secrets. The SCA workflow needs the build to finish first because it scans the resolved dependencies, so we declare a needs: build dependency.\nThe sca.yml workflow itself sets fail-fast: false because we want the full set of findings, not just the first one. It runs on a matrix of operating systems, checks out the repo, installs Java, installs the CRDA tool, runs redhat-actions/crda@v1.2, and uploads the standard SARIF findings file so GitHub can render it.\nCRDA needs two secrets: a SNYK_KEY (you create a free Snyk account at app.snyk.io and copy the API key from your account settings) and a GitHub token for the OpenShift Tools installer (the default GITHUB_TOKEN works). Both go under Settings → Secrets → Actions.\nWhat Actually Happened # The first run worked. The pipeline built, the SCA job ran, CRDA scanned, vulnerabilities showed up under Security → Code scanning sorted by tool, severity, branch, and rule. Real findings against the deliberately outdated Spring Boot version we had pinned.\nThen we tried to re-run the pipeline an hour later and things fell apart. CRDA returned connection timeouts. The Snyk key worked for two or three scans and then refused to authenticate. Patrick was blunt about it: as it stands, this is not enterprise ready. Worth knowing if you are evaluating CRDA for production use.\nOne small thing also surprised us: the severity labels in the GitHub UI are \u0026ldquo;error / warning / note\u0026rdquo; instead of the \u0026ldquo;critical / high / medium / low\u0026rdquo; we are used to from the security world. Not wrong, just different — adjust your triage scripts accordingly.\nDependabot vs the Pipeline Scan # Curiously, after waiting some time, Dependabot still reported no alerts on the same repository where CRDA found real vulnerabilities. We never fully figured out why. The lesson is that neither tool is a complete answer on its own — Dependabot for the always-on platform view, a pipeline SCA tool for scan-on-commit, and a real evaluation of which third-party tool you actually trust for the latter.\nKey Takeaways # GitHub has no default SCA tool. You build the SCA capability yourself by combining Dependabot (platform) with a Marketplace action.\nEnable Dependabot first. Dependency graph, alerts, and security updates take three toggles in settings. Skip version updates unless you want a PR for every minor bump.\nThe Marketplace SCA path is rough. CRDA + Snyk works in demos but proved unreliable under load. Connection timeouts and short-lived API keys made it unusable for enterprise.\nPipeline SCA needs needs: build. The scan runs against resolved dependencies, so the build job has to complete first. Use a separate workflow file called from main, with secrets inherited.\nSeverity labels are different. GitHub shows \u0026ldquo;error / warning / note\u0026rdquo; in code scanning, not the \u0026ldquo;critical / high / medium / low\u0026rdquo; you are used to. Adjust your triage accordingly.\nEvaluate the SCA tool seriously before committing. The one shown in the video is not the answer. Pick a tool with a track record, account-grade API limits, and a reliable scanner — and verify it under real load before you wire it into every pipeline.\n","date":"19 January 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-sca/","section":"Blogs","summary":"GitHub does not ship a default SCA tool the way GitLab does. You have to combine two things: a platform feature called Dependabot and an SCA action from the Marketplace. In Part 3 of the GitHub DevSecOps series, Patrick Steger and I wire both into our pipeline — and find out the hard way that the Marketplace path is not as smooth as the slides suggest.\n","title":"GitHub DevSecOps Part 3: Software Composition Analysis with Dependabot and CRDA","type":"blogs"},{"content":"","date":"19 January 2023","externalUrl":null,"permalink":"/en/tags/software-composition-analysis/","section":"Tags","summary":"","title":"Software Composition Analysis","type":"tags"},{"content":"","date":"17 January 2023","externalUrl":null,"permalink":"/en/tags/collaboration/","section":"Tags","summary":"","title":"Collaboration","type":"tags"},{"content":"Wie sieht die Zukunft des digitalen Büros aus? In dieser Session erkunde ich gemeinsam mit Christian von der VR-Plattform Arthur die Möglichkeiten virtueller Arbeitsräume. Wir bewegen uns durch verschiedene VR-Umgebungen, von Besprechungsräumen über Workshop-Spaces bis hin zu inspirierenden Landschaften auf dem Mond, und diskutieren, was für Unternehmen heute schon nutzbar ist und wo die Grenzen liegen. Das Gespräch fand vollständig in Virtual Reality statt, mit VR-Headsets auf dem Kopf.\nWas kann man im virtuellen Büro tun? # Die Einsatzmöglichkeiten virtueller Arbeitsräume sind breiter, als die meisten erwarten würden. Christian zeigte uns verschiedene Anwendungsfälle, die bereits im produktiven Einsatz sind:\nWorkshops und Design Thinking: Kreative Sessions mit Post-its, Whiteboards und interaktiven Elementen funktionieren erstaunlich gut in VR. Man kann Notizen schreiben, an Boards heften, verschieben und gemeinsam bearbeiten. Die Tatsache, dass man sich in einem komplett anderen Raum fühlt, regt kreatives Denken an.\nMeetings und verteilte Teams: Für Teams, die über Europa verteilt sind, bietet VR eine Alternative zu Videokonferenzen, bei der man sich tatsächlich \u0026ldquo;sieht\u0026rdquo; und ein räumliches Gefühl hat. Das Gefühl der Präsenz geht weit über das hinaus, was eine Teams-Sitzung bieten kann.\nScrum und PI-Planning: Wir besichtigten einen speziell gestalteten Raum für Scrum-Zeremonien, mit Bereichen für Vision Boards, Sprint Planning, Daily Scrum und Retrospektiven. Verschiedene Gruppen können auf verschiedenen Ebenen arbeiten, ohne sich gegenseitig zu stören.\nKonferenzen: Kleinere Veranstaltungen mit 20 bis 40 Personen sind gut machbar. Bei grösseren Konferenzen wird die Datenbelastung durch die Avatare zur Herausforderung, aber es gibt Lösungen, die Web-Konferenzen mit VR-Sessions kombinieren.\nDie Hardware-Frage # Ein grosses Diskussionsthema war die Hardware. Die Meta Quest ist weit verbreitet, aber die Bindung an Facebook-Accounts ist für Unternehmen problematisch. Christian bevorzugt mittlerweile die Pico-Headsets, weil sie nicht an einen einzelnen Account gebunden sind und sich besser für den Unternehmenseinsatz eignen.\nDas Sichtfeld der aktuellen Brillen bleibt eine Einschränkung. Wenn man in einer Gruppe von mehreren Personen steht, bekommt man wenig mit, was links und rechts passiert. Neuere Brillen mit breiterem Sichtfeld werden hier Verbesserungen bringen.\n\u0026ldquo;Was mich am meisten fasziniert, ist, wie real die Erinnerungen sind. Das Gehirn kann wirklich ausgetrickst werden. Beim \u0026lsquo;Walk the Plank\u0026rsquo; stehen manche nicht mal auf das Brett, obwohl sie wissen, dass sie sicher in einem Gebäude stehen.\u0026rdquo;\nEin spannender Aspekt: Die Lippensynchronisation funktioniert bereits, und in wenigen Monaten werden auch Mimik und Augenbewegungen übertragen. Das wird die Qualität der Kommunikation in VR noch einmal deutlich verbessern.\nVon der Inspiration zur Produktivität # Besonders beeindruckend waren die inspirierenden Umgebungen. Wir besuchten eine Terrasse mit Hintergrundgeräuschen (leichter Wind), was sofort ein stärkeres räumliches Gefühl erzeugte. Für Innovationsworkshops nutzt Christians Team sogar einen Raum auf dem Mond, um den Teilnehmern zu signalisieren: \u0026ldquo;Hier gibt es keine Grenzen, hier dürfen wir alles.\u0026rdquo;\nDie Frage, ob solche kreativen Welten beim Arbeiten ablenken, wurde klar beantwortet: Am Anfang ja, aber nach einem kurzen Onboarding vergisst man die Umgebung und konzentriert sich auf die Arbeit. Für Einzelberatungen oder kleinere Gruppen eignen sich die kreativen Räume besonders gut.\nDie realen Workshop-Ergebnisse bestätigten das. Bei den Sprints mit Teams waren die Pin-Boards voll mit Ergebnissen. Die Zusammenarbeit funktionierte, auch wenn die Sessions auf 90 Minuten begrenzt sein sollten, da man danach wirklich erschöpft ist. Zwei Stunden in VR sind das absolute Maximum.\nHerausforderungen und Enterprise-Readiness # Trotz der beeindruckenden Möglichkeiten sind die Plattformen noch nicht vollständig Enterprise-ready. Bei einer Evaluation verschiedener VR-Plattformen für einen Kunden war das Ergebnis ernüchternd: Ausser Arthur hatten die meisten Plattformen noch erhebliche Defizite im Unternehmenseinsatz.\nMeta hat mit dem Developer Mode Problem (Firmware Version 47 deaktivierte den Developer Mode für Wochen) Vertrauen verspielt. Für Unternehmen ist das inakzeptabel, besonders wenn eine Stakeholder-Präsentation ansteht und plötzlich keine eigene Software mehr geladen werden kann.\nDie Zukunft wird spannend: Microsoft Mesh könnte die VR-Zusammenarbeit direkt in die Office-Welt integrieren. Und die Frage, ob Rendering in der Cloud statt auf dem Headset stattfinden wird, wird je nach Use Case unterschiedlich beantwortet. Für hochpräzise Sicherheitstrainings braucht man Cloud-Rendering, für Leadership-Trainings reicht das, was die heutigen Brillen leisten.\nNeue Geschäftsfelder: Retail und Kunst # Über die Büroarbeit hinaus zeigte Christian Anwendungsfälle im Retail-Bereich. Für Automobil-Hersteller können virtuelle Showrooms die Customer Journey revolutionieren: Strategien testen, Mitarbeiter schulen und sogar Verkaufsgespräche virtuell führen.\nBesonders spannend ist der Bereich Kunst und Galerien: Man kann ein Kunstwerk sowohl als reales Objekt auf Leinwand kaufen als auch als digitales Asset (oder beides) und es sowohl im virtuellen Wohnzimmer als auch zu Hause aufhängen. Für den Gaming-Bereich wird ebenfalls gebaut, zum Beispiel ein Multiplayer-Game für die Postfinance, das jüngere Zielgruppen spielerisch an Finanzthemen heranführen soll.\nKernaussagen # Virtuelle Büros funktionieren bereits für Workshops, Meetings, Scrum-Zeremonien und kleinere Konferenzen. Die Technologie ist nicht perfekt, aber produktiv einsetzbar. Die Hardware-Wahl ist entscheidend: Meta Quest hat Consumer-Fokus, Pico ist für Unternehmen oft besser geeignet. Das beschränkte Sichtfeld bleibt eine Limitation. 90 Minuten pro VR-Session sind das empfohlene Maximum. Danach sinkt Konzentration und Komfort deutlich. Enterprise-Readiness variiert stark zwischen den Plattformen. Arthur ist aktuell eine der ausgereiftesten Lösungen für den Business-Einsatz. Die Erinnerungen in VR fühlen sich real an: Das Gehirn unterscheidet kaum zwischen virtuellen und realen Erlebnissen, was VR als Medium für Zusammenarbeit und Training so wirkungsvoll macht. Die Zukunft bringt bessere Mimik, breitere Sichtfelder und Cloud-Rendering, was die Qualität der VR-Zusammenarbeit weiter verbessern wird. ","date":"17. January 2023","externalUrl":null,"permalink":"/de/blogs/metaverse-digitales-buero-im-virtuellen-raum/","section":"Blogs","summary":"Wie sieht die Zukunft des digitalen Büros aus? In dieser Session erkunde ich gemeinsam mit Christian von der VR-Plattform Arthur die Möglichkeiten virtueller Arbeitsräume. Wir bewegen uns durch verschiedene VR-Umgebungen, von Besprechungsräumen über Workshop-Spaces bis hin zu inspirierenden Landschaften auf dem Mond, und diskutieren, was für Unternehmen heute schon nutzbar ist und wo die Grenzen liegen. Das Gespräch fand vollständig in Virtual Reality statt, mit VR-Headsets auf dem Kopf.\n","title":"Das digitale Büro im Metaverse: Teamarbeit im virtuellen Raum","type":"blogs"},{"content":"","date":"17 January 2023","externalUrl":null,"permalink":"/en/tags/metaverse/","section":"Tags","summary":"","title":"Metaverse","type":"tags"},{"content":"What does the future of the digital office look like? In this session, I explore the possibilities of virtual workspaces together with Christian from the VR platform Arthur. We move through various VR environments, from meeting rooms and workshop spaces to inspiring landscapes on the moon, and discuss what is already usable for businesses today and where the limitations are. The entire conversation took place in Virtual Reality, with VR headsets on our heads. Note: the original session was conducted in German.\nWhat Can You Do in a Virtual Office? # The use cases for virtual workspaces are broader than most people would expect. Christian showed us several applications that are already in productive use:\nWorkshops and Design Thinking: Creative sessions with post-its, whiteboards, and interactive elements work surprisingly well in VR. You can write notes, pin them to boards, move them around, and collaborate on them. The fact that you feel like you are in a completely different space stimulates creative thinking.\nMeetings and distributed teams: For teams distributed across Europe, VR offers an alternative to video conferencing where you actually \u0026ldquo;see\u0026rdquo; each other and have a spatial sense of presence. The feeling of being there goes far beyond what a Teams meeting can provide.\nScrum and PI-Planning: We visited a specially designed room for Scrum ceremonies, with areas for Vision Boards, Sprint Planning, Daily Scrum, and Retrospectives. Different groups can work on different levels without disturbing each other.\nConferences: Smaller events with 20 to 40 people work well. For larger conferences, the data load from avatars becomes challenging, but solutions exist that combine web conferences with VR sessions.\nThe Hardware Question # A major discussion topic was the hardware. The Meta Quest is widely used, but the binding to Facebook accounts is problematic for enterprises. Christian now prefers the Pico headsets because they are not tied to a single account and are better suited for enterprise use.\nThe field of view of current headsets remains a limitation. When standing in a group of several people, you get little awareness of what is happening to your left and right. Newer headsets with wider fields of view will bring improvements here.\n\u0026ldquo;What fascinates me most is how real the memories feel. The brain can truly be tricked. During \u0026lsquo;Walk the Plank,\u0026rsquo; some people will not even step onto the plank, even though they know they are safely standing in a building.\u0026rdquo;\nAn exciting development: lip synchronization already works, and within a few months, facial expressions and eye movements will also be transmitted. This will significantly improve the quality of communication in VR.\nFrom Inspiration to Productivity # The inspiring environments were particularly impressive. We visited a terrace with background sounds (gentle wind), which immediately created a stronger spatial feeling. For innovation workshops, Christian\u0026rsquo;s team even uses a room on the moon to signal to participants: \u0026ldquo;There are no limits here, everything is allowed.\u0026rdquo;\nThe question of whether such creative worlds distract from work was clearly answered: at the beginning yes, but after a short onboarding, you forget the environment and focus on the work. Creative spaces are particularly well suited for individual consultations or smaller groups.\nThe real workshop results confirmed this. During sprints with teams, the pin boards were full of results. Collaboration worked, though sessions should be limited to 90 minutes, as you become genuinely exhausted after that. Two hours in VR is the absolute maximum.\nChallenges and Enterprise Readiness # Despite the impressive capabilities, the platforms are not yet fully enterprise-ready. During an evaluation of various VR platforms for a client, the result was sobering: apart from Arthur, most platforms still had significant gaps for enterprise use.\nMeta lost trust with the Developer Mode problem (Firmware version 47 disabled Developer Mode for weeks). For enterprises, this is unacceptable, especially when a stakeholder presentation is coming up and suddenly your own software can no longer be loaded.\nThe future will be exciting: Microsoft Mesh could integrate VR collaboration directly into the Office ecosystem. And the question of whether rendering will happen in the cloud rather than on the headset will be answered differently depending on the use case. For high-precision safety training, you need cloud rendering. For leadership training, what today\u0026rsquo;s headsets can do is already sufficient.\nNew Business Areas: Retail and Art # Beyond office work, Christian showed use cases in the retail space. For automotive manufacturers, virtual showrooms can revolutionize the customer journey: testing strategies, training employees, and even conducting sales conversations virtually.\nParticularly exciting is the area of art and galleries: you can buy an artwork both as a real object on canvas and as a digital asset (or both) and display it in your virtual living room as well as at home. Gaming is another growth area. For example, a multiplayer game is being built for Postfinance to introduce younger target audiences to financial topics in a playful way.\nKey Takeaways # Virtual offices already work for workshops, meetings, Scrum ceremonies, and smaller conferences. The technology is not perfect, but it is usable for productive work. Hardware choice matters: Meta Quest has a consumer focus, while Pico is often better suited for enterprises. The limited field of view remains a constraint. 90 minutes per VR session is the recommended maximum. After that, concentration and comfort drop significantly. Enterprise readiness varies greatly across platforms. Arthur is currently one of the most mature solutions for business use. Memories in VR feel real: The brain barely distinguishes between virtual and real experiences, which makes VR so powerful as a medium for collaboration and training. The future brings better facial expressions, wider fields of view, and cloud rendering, which will further improve VR collaboration quality. ","date":"17 January 2023","externalUrl":null,"permalink":"/en/blogs/metaverse-digital-office-space/","section":"Blogs","summary":"What does the future of the digital office look like? In this session, I explore the possibilities of virtual workspaces together with Christian from the VR platform Arthur. We move through various VR environments, from meeting rooms and workshop spaces to inspiring landscapes on the moon, and discuss what is already usable for businesses today and where the limitations are. The entire conversation took place in Virtual Reality, with VR headsets on our heads. Note: the original session was conducted in German.\n","title":"The Digital Office in the Metaverse: Teamwork in Virtual Space","type":"blogs"},{"content":"","date":"17 January 2023","externalUrl":null,"permalink":"/en/tags/virtual-reality/","section":"Tags","summary":"","title":"Virtual Reality","type":"tags"},{"content":"","date":"17. January 2023","externalUrl":null,"permalink":"/de/tags/zusammenarbeit/","section":"Tags","summary":"","title":"Zusammenarbeit","type":"tags"},{"content":"Before we plug security tools into anything, we need a repository, a pipeline, and a working build. In Part 2 of our GitHub DevSecOps series, Patrick Steger and I create a private GitHub repo for a small Java Spring Boot service, enable GitHub Actions, and wire up a two-workflow pipeline that compiles the code and runs the unit tests. This is the skeleton everything else in the series hangs on.\nThe Application We\u0026rsquo;re Building Around # We use the same simple Java Spring Boot application throughout the series — a web service that returns \u0026ldquo;Spring is here!\u0026rdquo; plus a unit test that calls the service and verifies the response. Small enough to read in one screen, real enough to demonstrate every DevSecOps tool we will add over the next ten sessions.\nPrerequisites and Licensing # GitHub can be used as SaaS in the cloud or installed on premise via GitHub Enterprise. The thing to know up front: if you want a private repository and the Advanced Security features, you need an Enterprise license. We are going to use both, so that is what we run on. If you only need public repositories, the free tier covers a lot.\nCreating the Repository # Sign in, click New, and you get the option to import an existing repo or start fresh. We start fresh. Owner is our enterprise account. Repository name is DevSecOpsDemo. Visibility is private. We skip the README, .gitignore, and license templates for the demo, but in a real project you absolutely want them.\nOnce the repo exists, take a quick tour of the tabs:\nCode — the repository itself Issues — basic issue tracking; works for backlog management too Pull requests — covered in a later session Actions — where our pipelines live Projects — lightweight project management Wiki — code documentation Security — the tab we will use heavily for SAST, SCA, secret scanning Insights — contributor stats and the dependency graph Settings — repo configuration Enabling Actions Safely # If the Actions tab is missing, head to Settings → Actions → General and enable Actions there. Worth pausing here, because this is the first real security decision you make on a GitHub project.\nActions are small custom applications. They are usually code you did not write, running inside your pipeline, with potential access to secrets. You get four levels:\nAllow every action from the marketplace Allow only enterprise actions Allow enterprise actions plus a specific allowlist Disable actions From a pure security standpoint, the safest model is \u0026ldquo;enterprise actions only\u0026rdquo; — review the community actions you want, copy them into your enterprise space, security-review them, and use those copies. For this demo we accept everything to keep moving, but in an enterprise environment you should not.\nImporting the Code # Back to the Code tab → Import code. We point GitHub at our existing project, wait a moment, and the source tree shows up: the Spring Boot application under src/main/java, the controller that returns \u0026ldquo;Spring is here!\u0026rdquo;, and the tests under src/test.\nTwo Workflows: Main Pipeline and Build Pipeline # GitHub calls pipelines workflows, and they live in .github/workflows/. We split our pipeline into two files on purpose: a main pipeline that orchestrates everything, and a build pipeline it calls. Splitting workflows keeps each file small and lets you reuse the build pipeline from other workflows later.\nCreate .github/workflows/main-pipeline.yml. Tip: GitHub\u0026rsquo;s file editor lets you type slashes in the filename to create folders inline. The main pipeline gets a clear, numbered name (00 - Main CI/CD Pipeline), triggers on push to main (with sensible path-ignore filters) and on workflow_dispatch so we can run it manually, and defines a build job that calls our build.yml and forwards the secrets it needs.\nNumbered names — 00 - Main, 10 - Build — sound trivial but they make the Actions UI readable when you have a dozen workflows running side by side. Recommended.\nNext file: .github/workflows/build.yml. Name it 10 - Build Pipeline. Triggers are workflow_dispatch (run manually) and workflow_call (callable from another workflow — this is what main-pipeline uses).\nThe build job declares the permissions it needs, runs on ubuntu-latest, and chains a series of steps that each call an action. The actions: check out the source with actions/checkout@v3, set up Java, compile with Maven, prepare an output directory, run the tests, prepare the test result directory, upload the application binary as an artifact, upload the test results as a downloadable zip, and publish the test results into the GitHub UI.\nCommit both files to main and head over to Actions.\nWatching the Pipeline Run # The Actions tab shows the main pipeline kicking off and the build pipeline running underneath it — the numbered names line them up neatly. Click in and you get a summary page: total duration, status, jobs executed, three tests found, the application binary and test results listed as artifacts (downloadable as zip), and the test results rendered inline. Click the build job and the full log is right there.\nWhere Actions Come From # We used actions/checkout@v3 without much explanation. That comes from the GitHub Marketplace, the place to discover Actions. The Checkout action is provided by a verified creator — GitHub vouched for them. Verified creators are your safer choice. Even safer: copy a verified action\u0026rsquo;s source into your enterprise repo, security-review it, and consume it from there. That is the model you want when production code depends on it.\nKey Takeaways # Pick the licensing tier that matches what you want to build. Private repos plus Advanced Security need GitHub Enterprise. Decide upfront — it shapes everything else.\nEnable Actions deliberately, not by default. The \u0026ldquo;allow everything from the marketplace\u0026rdquo; option is convenient and risky. In an enterprise context, \u0026ldquo;enterprise-only\u0026rdquo; plus a curated allowlist is the right baseline.\nWorkflows live in .github/workflows/. That folder is the entire pipeline configuration surface. Knowing it exists is half the battle.\nSplit workflows for orchestration and reuse. A main pipeline that calls a build pipeline (via workflow_call) keeps each file small and lets you compose larger pipelines later without rewriting the build.\nUse a naming scheme like 00 - Main, 10 - Build. It looks pedantic until you have ten workflows. Then it is the only thing that keeps the Actions UI readable.\nUse verified Actions, or import them into your enterprise. Marketplace Actions run inside your pipeline with access to your secrets. Treat them as third-party code. Verified creators are the floor; enterprise-imported and reviewed copies are the ceiling.\n","date":"11 January 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-creating-a-project/","section":"Blogs","summary":"Before we plug security tools into anything, we need a repository, a pipeline, and a working build. In Part 2 of our GitHub DevSecOps series, Patrick Steger and I create a private GitHub repo for a small Java Spring Boot service, enable GitHub Actions, and wire up a two-workflow pipeline that compiles the code and runs the unit tests. This is the skeleton everything else in the series hangs on.\n","title":"GitHub DevSecOps Part 2: Creating a Simple Project and Your First Workflow","type":"blogs"},{"content":"Bevor wir Security-Tools an irgendetwas anschliessen, brauchen wir ein Repository, eine Pipeline und einen lauffähigen Build. In Teil 2 unserer GitHub DevSecOps Serie legen Patrick Steger und ich ein privates GitHub-Repo für einen kleinen Java-Spring-Boot-Service an, aktivieren GitHub Actions und verdrahten eine Pipeline aus zwei Workflows, die den Code kompiliert und die Unit Tests ausführt. Das ist das Skelett, an dem in der Serie alles Weitere hängt.\nDie Anwendung, um die wir bauen # Wir verwenden in der ganzen Serie dieselbe einfache Java-Spring-Boot-Anwendung — ein Web-Service, der \u0026ldquo;Spring is here!\u0026rdquo; zurückliefert, plus ein Unit Test, der den Service aufruft und das Ergebnis prüft. Klein genug, um auf einen Bildschirm zu passen, real genug, um in den nächsten zehn Sessions jedes DevSecOps-Tool sauber demonstrieren zu können.\nVoraussetzungen und Lizenzierung # GitHub gibt es als SaaS in der Cloud oder On-Premise via GitHub Enterprise. Wichtig vorab: Wenn du ein privates Repository und die Advanced Security Features willst, brauchst du eine Enterprise-Lizenz. Wir setzen beides ein — also läuft das hier auf Enterprise. Wer nur öffentliche Repositories braucht, kommt mit dem Free Tier sehr weit.\nDas Repository anlegen # Einloggen, New klicken, und du kannst ein bestehendes Repo importieren oder neu starten. Wir starten neu. Owner ist unser Enterprise-Account. Repository-Name ist DevSecOpsDemo. Sichtbarkeit privat. README, .gitignore und License-Templates lassen wir für das Demo weg — in einem echten Projekt willst du sie auf jeden Fall ausgefüllt haben.\nSobald das Repo existiert, lohnt sich ein kurzer Rundgang durch die Tabs:\nCode — das Repository selbst Issues — einfaches Issue-Tracking; auch fürs Backlog-Management nutzbar Pull requests — Thema einer späteren Session Actions — hier leben unsere Pipelines Projects — leichtgewichtiges Projektmanagement Wiki — Code-Dokumentation Security — der Tab, den wir intensiv für SAST, SCA und Secret Scanning brauchen Insights — Contributor-Statistiken und der Dependency Graph Settings — Repo-Konfiguration Actions sicher aktivieren # Falls der Actions-Tab fehlt, geh auf Settings → Actions → General und aktiviere Actions dort. An dieser Stelle lohnt sich ein kurzer Stopp, denn das ist die erste echte Security-Entscheidung in einem GitHub-Projekt.\nActions sind kleine eigenständige Anwendungen. In der Regel Code, den du nicht selbst geschrieben hast, läuft in deiner Pipeline, mit potenziellem Zugriff auf Secrets. Du hast vier Stufen:\nJede Action aus dem Marketplace zulassen Nur Enterprise-Actions zulassen Enterprise-Actions plus eine konkrete Allowlist Actions deaktivieren Aus reiner Security-Sicht ist die sicherste Variante \u0026ldquo;nur Enterprise-Actions\u0026rdquo; — du reviewst die Community-Actions, die du wirklich willst, kopierst sie in deinen Enterprise-Bereich, machst ein Security-Review und nutzt diese Kopien. Im Demo erlauben wir alles, um zügig vorwärts zu kommen — in einem Enterprise-Umfeld solltest du das nicht.\nDen Code importieren # Zurück auf den Code-Tab → Import code. Wir zeigen GitHub auf unser bestehendes Projekt, warten kurz, und der Source-Tree taucht auf: die Spring-Boot-Anwendung unter src/main/java, der Controller, der \u0026ldquo;Spring is here!\u0026rdquo; zurückgibt, und die Tests unter src/test.\nZwei Workflows: Main Pipeline und Build Pipeline # GitHub nennt Pipelines Workflows, und sie liegen in .github/workflows/. Wir splitten unsere Pipeline bewusst in zwei Dateien: eine Main Pipeline, die orchestriert, und eine Build Pipeline, die sie aufruft. Workflows zu splitten hält jede Datei klein und erlaubt es dir, die Build Pipeline später aus anderen Workflows wiederzuverwenden.\nLege .github/workflows/main-pipeline.yml an. Tipp: Im File-Editor von GitHub kannst du Slashes im Dateinamen tippen, um Ordner inline zu erzeugen. Die Main Pipeline bekommt einen klaren, nummerierten Namen (00 - Main CI/CD Pipeline), triggert auf push auf main (mit sinnvollen Path-Ignore-Filtern) und auf workflow_dispatch, sodass wir sie manuell starten können, und definiert einen build Job, der unsere build.yml aufruft und die nötigen Secrets weiterreicht.\nNummerierte Namen — 00 - Main, 10 - Build — klingen banal, machen die Actions-UI aber lesbar, sobald du ein Dutzend Workflows nebeneinander hast. Empfehlung.\nNächste Datei: .github/workflows/build.yml. Name: 10 - Build Pipeline. Trigger sind workflow_dispatch (manuell ausführen) und workflow_call (von einem anderen Workflow aufrufbar — genau das nutzt die Main Pipeline).\nDer Build Job deklariert die nötigen Permissions, läuft auf ubuntu-latest und kettet eine Reihe von Schritten aneinander, die jeweils eine Action aufrufen. Die Actions: Source-Code mit actions/checkout@v3 auschecken, Java aufsetzen, mit Maven kompilieren, Output-Verzeichnis vorbereiten, Tests ausführen, Test-Result-Verzeichnis vorbereiten, das Application-Binary als Artifact hochladen, die Test-Ergebnisse als ZIP zum Download bereitstellen und die Test-Ergebnisse im GitHub-UI veröffentlichen.\nBeide Dateien auf main committen und ab in den Actions-Tab.\nDer Pipeline beim Laufen zuschauen # Im Actions-Tab startet die Main Pipeline, und die Build Pipeline läuft direkt darunter — die nummerierten Namen reihen sich sauber auf. Klickst du rein, bekommst du eine Übersichtsseite: Gesamtdauer, Status, ausgeführte Jobs, drei gefundene Tests, das Application-Binary und die Test-Ergebnisse als Artifacts (als ZIP herunterladbar) und die Test-Ergebnisse direkt im UI gerendert. Klickst du auf den Build Job, hast du das volle Log direkt vor dir.\nWoher die Actions kommen # Wir haben actions/checkout@v3 ohne grosse Erklärung benutzt. Sie kommt aus dem GitHub Marketplace, dem Ort, an dem du Actions findest. Die Checkout-Action stammt von einem verified creator — GitHub bürgt für ihn. Verified Creators sind die sicherere Wahl. Noch sicherer: Source der Verified Action ins Enterprise-Repo kopieren, Security-Review machen und sie von dort konsumieren. Das ist das Modell, das du willst, wenn produktiver Code davon abhängt.\nKey Takeaways # Wähle das Lizenzmodell, das zu dem passt, was du bauen willst. Private Repos plus Advanced Security brauchen GitHub Enterprise. Diese Entscheidung früh treffen — sie prägt alles Weitere.\nActions bewusst aktivieren, nicht per Default. \u0026ldquo;Alles aus dem Marketplace erlauben\u0026rdquo; ist bequem und riskant. In Enterprise-Kontexten ist \u0026ldquo;nur Enterprise\u0026rdquo; plus kuratierte Allowlist die richtige Baseline.\nWorkflows liegen in .github/workflows/. Dieser Ordner ist die gesamte Konfigurationsfläche der Pipeline. Allein zu wissen, dass es ihn gibt, ist die halbe Miete.\nWorkflows für Orchestrierung und Wiederverwendung splitten. Eine Main Pipeline, die eine Build Pipeline (via workflow_call) aufruft, hält jede Datei klein und erlaubt es, später grössere Pipelines zu komponieren, ohne den Build neu zu schreiben.\nNutze ein Naming-Schema wie 00 - Main, 10 - Build. Wirkt pedantisch — bis du zehn Workflows hast. Dann ist es das Einzige, was die Actions-UI lesbar hält.\nVerwende verified Actions oder importiere sie ins Enterprise. Marketplace-Actions laufen in deiner Pipeline mit Zugriff auf deine Secrets. Behandle sie wie Code von Dritten. Verified Creators sind das Minimum; ins Enterprise importierte und reviewte Kopien sind das Optimum.\n","date":"11. January 2023","externalUrl":null,"permalink":"/de/blogs/github-devsecops-projekt-erstellen/","section":"Blogs","summary":"Bevor wir Security-Tools an irgendetwas anschliessen, brauchen wir ein Repository, eine Pipeline und einen lauffähigen Build. In Teil 2 unserer GitHub DevSecOps Serie legen Patrick Steger und ich ein privates GitHub-Repo für einen kleinen Java-Spring-Boot-Service an, aktivieren GitHub Actions und verdrahten eine Pipeline aus zwei Workflows, die den Code kompiliert und die Unit Tests ausführt. Das ist das Skelett, an dem in der Serie alles Weitere hängt.\n","title":"GitHub DevSecOps Teil 2: Ein einfaches Projekt und den ersten Workflow erstellen","type":"blogs"},{"content":"","date":"11 January 2023","externalUrl":null,"permalink":"/en/tags/pipeline/","section":"Tags","summary":"","title":"Pipeline","type":"tags"},{"content":"","date":"11 January 2023","externalUrl":null,"permalink":"/en/tags/spring-boot/","section":"Tags","summary":"","title":"Spring Boot","type":"tags"},{"content":"","date":"11 January 2023","externalUrl":null,"permalink":"/en/tags/workflows/","section":"Tags","summary":"","title":"Workflows","type":"tags"},{"content":"The internet is full of posts claiming that DevOps is dead. \u0026ldquo;DevOps is bullshit.\u0026rdquo; \u0026ldquo;Platform Engineering will replace DevOps.\u0026rdquo; \u0026ldquo;SRE is the future.\u0026rdquo; In this video, I explain why all of these claims are wrong, where they come from, and how DevOps, Platform Engineering, and Site Reliability Engineering actually relate to each other.\nToday\u0026rsquo;s Broken Value Streams # To understand why \u0026ldquo;DevOps is dead\u0026rdquo; posts exist, we first need to understand today\u0026rsquo;s challenges. In most enterprises, the picture is the same: Business writes great plans, throws them over the wall of confusion to Development. Development implements something and throws it to QA. QA tests something that does not match the spec and throws it to Operations. Operations says it will never work in production. And the customer says: \u0026ldquo;This is not what we wanted.\u0026rdquo;\nThe value stream is broken by walls of confusion that come from the silo organization. The silos themselves are not the real problem. The real problem is the lack of alignment between them, because these organizational units have different goals and can even cancel each other out.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices which provides communication, integration, automation, and close collaboration among all the people that need to plan, code, build, test, deploy, release, operate, and monitor a product.\u0026rdquo;\nThe DevOps Naming Debate # The term \u0026ldquo;DevOps\u0026rdquo; is Development plus Operations. Many people think it is only about bringing Dev and Ops together. It is not. Some smart people proposed \u0026ldquo;DevSecOps\u0026rdquo; because security is important. Others proposed \u0026ldquo;BizDevOps\u0026rdquo; because business is important. But none of these terms capture the full picture. We would need \u0026ldquo;DevSecBizArchCompQAOps\u0026rdquo; to be complete. So we just call it DevOps, because DevOps is about bringing all the people, processes, and technology together to continuously deliver value.\nCommon Anti-Patterns # The \u0026ldquo;DevOps is dead\u0026rdquo; posts come from misled or insufficient implementations. Here are the most common anti-patterns:\nThe DevOps Silo: Management says \u0026ldquo;we need some of this DevOps thing,\u0026rdquo; keeps the Dev and Ops silos, and creates a new DevOps silo between them. This just adds more walls of confusion and more handoffs. Do not do this.\nThe Remote DevOps Silo: Management says \u0026ldquo;we need DevOps, but let us outsource it to a cheaper location.\u0026rdquo; This is even worse than the previous anti-pattern. Also do not do this.\nThe goal is clear: Dev and Ops (and all other roles) should come closer and closer until they become one team with the same goals, fully aligned to product delivery.\nThe Scaling Challenge # One team doing DevOps on one product works beautifully. But what happens when you have multiple teams on multiple products? Each team uses its own tools and platforms. You get massive redundancy, inconsistency, and friction. Development teams may lack operational experience, leading to cognitive overload from the complexity of managing all the tooling themselves.\nSome companies respond by creating a shared operations team in the middle. This reduces cognitive load and brings consistency, but it reintroduces the silo problem.\nPlatform Engineering: The Better Approach # The better solution is Platform Engineering. You keep all the product teams working on their products with DevOps practices. But instead of a shared ops silo, you introduce a platform team that builds and maintains a platform where all products can be built and maintained.\nEach product team retains its own product operations as a sub-team or dedicated people who operate the product. The platform team provides the foundation: runtime, developer experience, CI/CD pipelines, identity management, and observability. Product teams still follow \u0026ldquo;you build it, you run it.\u0026rdquo;\nThe key insight: customers do not pay for your platform. They pay for your products. But the platform generates value for your teams, enabling them to build better products. Platform Engineering enables DevOps in your company.\n\u0026ldquo;Platform Engineering uses DevOps practices so that they can deliver a platform where product teams can build their products and do DevOps.\u0026rdquo;\nSite Reliability Engineering: DevOps for High Availability # There is also confusion about whether SRE (Site Reliability Engineering) will replace DevOps. SRE was introduced by Google in 2004. It is about building highly available, highly reliable, highly scalable systems.\nThe distinction is practical. When your system needs two nines of availability (14.4 minutes downtime per day), you do DevOps. When you need five nines (864 milliseconds downtime per day), you need SRE. Site Reliability Engineers are T-shaped people who know a lot about both operations and development. They use DevOps practices to build and maintain systems that need extreme reliability.\nEngineering a five-nines system is vastly more complex and time-consuming than a two-nines system. SRE is not a replacement for DevOps. It is a specialization that uses DevOps practices for high-availability scenarios.\nThe Thought Model: How It All Fits Together # I use the following model to visualize the relationships:\nLean (1940s): The Toyota Production System, the foundation of everything. Agile (2000): The Agile Manifesto, built on Lean principles. DevOps: Built on Agile and Lean. Bringing all people, processes, and technology together to continuously deliver value. Platform Engineering: Uses DevOps practices to deliver a platform that enables product teams to do DevOps. SRE: Uses DevOps practices to build highly scalable, highly reliable, highly available products. DevOps is not dead. It is the foundation that Platform Engineering and SRE build upon.\nKey Takeaways # \u0026ldquo;DevOps is dead\u0026rdquo; comes from bad implementations. When companies create DevOps silos or outsource DevOps to cheap locations, it fails. That is not a problem with DevOps. It is a problem with the implementation.\nDevOps is about all the people. Not just Dev and Ops. Security, business, architecture, compliance, QA, and everyone else working on the value stream.\nPlatform Engineering enables DevOps at scale. It provides the standardized foundation so product teams can focus on delivering value instead of reinventing tooling.\nSRE is a DevOps specialization. It uses the same practices for systems that require extreme availability and reliability.\nThe foundation is clear. Lean enables Agile. Agile enables DevOps. DevOps enables Platform Engineering and SRE. None of them replace each other.\n","date":"10 January 2023","externalUrl":null,"permalink":"/en/blogs/devops-is-dead-platform-engineering-sre/","section":"Blogs","summary":"The internet is full of posts claiming that DevOps is dead. “DevOps is bullshit.” “Platform Engineering will replace DevOps.” “SRE is the future.” In this video, I explain why all of these claims are wrong, where they come from, and how DevOps, Platform Engineering, and Site Reliability Engineering actually relate to each other.\n","title":"DevOps Is Dead? Why Platform Engineering and SRE Need DevOps More Than Ever","type":"blogs"},{"content":"Das Internet ist voll von Beiträgen, die behaupten, DevOps sei tot. \u0026ldquo;DevOps ist Schwachsinn.\u0026rdquo; \u0026ldquo;Platform Engineering wird DevOps ersetzen.\u0026rdquo; \u0026ldquo;SRE ist die Zukunft.\u0026rdquo; In diesem Video erkläre ich, warum all diese Behauptungen falsch sind, woher sie kommen und wie DevOps, Platform Engineering und Site Reliability Engineering tatsächlich zusammenhängen.\nHeutige unterbrochene Wertströme # Um zu verstehen, warum \u0026ldquo;DevOps ist tot\u0026rdquo;-Beiträge existieren, müssen wir zuerst die heutigen Herausforderungen verstehen. In den meisten Unternehmen sieht das Bild gleich aus: Das Business schreibt tolle Pläne, wirft sie über die Wall of Confusion zur Entwicklung. Die Entwicklung implementiert etwas und wirft es zur QA. Die QA testet etwas, das nicht der Spezifikation entspricht, und wirft es zum Betrieb. Der Betrieb sagt, es wird nie in Produktion funktionieren. Und der Kunde sagt: \u0026ldquo;Das ist nicht, was wir wollten.\u0026rdquo;\nDer Wertstrom ist durch Walls of Confusion unterbrochen, die aus der Siloorganisation stammen. Die Silos selbst sind nicht das eigentliche Problem. Das eigentliche Problem ist die fehlende Abstimmung zwischen ihnen, weil diese Organisationseinheiten unterschiedliche Ziele haben und sich sogar gegenseitig aufheben können.\n\u0026ldquo;DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, die Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Menschen ermöglichen, die ein Produkt planen, entwickeln, bauen, testen, deployen, releasen, betreiben und überwachen müssen.\u0026rdquo;\nDie DevOps-Namensdebatte # Der Begriff \u0026ldquo;DevOps\u0026rdquo; steht für Development plus Operations. Viele Menschen denken, es gehe nur darum, Dev und Ops zusammenzubringen. Das stimmt nicht. Einige schlaue Leute schlugen \u0026ldquo;DevSecOps\u0026rdquo; vor, weil Security wichtig ist. Andere schlugen \u0026ldquo;BizDevOps\u0026rdquo; vor, weil Business wichtig ist. Aber keiner dieser Begriffe erfasst das vollständige Bild. Wir bräuchten \u0026ldquo;DevSecBizArchCompQAOps\u0026rdquo;, um vollständig zu sein. Also nennen wir es einfach DevOps, weil DevOps darum geht, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.\nHäufige Anti-Patterns # Die \u0026ldquo;DevOps ist tot\u0026rdquo;-Beiträge stammen von fehlgeleiteten oder unzureichenden Implementierungen. Hier sind die häufigsten Anti-Patterns:\nDas DevOps-Silo: Das Management sagt \u0026ldquo;Wir brauchen etwas von diesem DevOps\u0026rdquo;, behält die Dev- und Ops-Silos und erstellt dazwischen ein neues DevOps-Silo. Das fügt nur mehr Walls of Confusion und mehr Übergaben hinzu. Machen Sie das nicht.\nDas Remote-DevOps-Silo: Das Management sagt \u0026ldquo;Wir brauchen DevOps, aber lassen Sie uns das an einen günstigeren Standort auslagern.\u0026rdquo; Das ist noch schlimmer als das vorherige Anti-Pattern. Machen Sie das auch nicht.\nDas Ziel ist klar: Dev und Ops (und alle anderen Rollen) sollten sich immer weiter annähern, bis sie ein Team mit denselben Zielen werden, vollständig auf die Produktlieferung ausgerichtet.\nDie Skalierungsherausforderung # Ein Team, das DevOps für ein Produkt macht, funktioniert wunderbar. Aber was passiert, wenn Sie mehrere Teams an mehreren Produkten haben? Jedes Team nutzt seine eigenen Tools und Plattformen. Sie bekommen massive Redundanz, Inkonsistenz und Reibung. Entwicklungsteams haben möglicherweise wenig Erfahrung im Betrieb, was zu kognitiver Überlastung durch die Komplexität der Verwaltung aller Tools führt.\nEinige Unternehmen reagieren, indem sie ein gemeinsames Betriebsteam in der Mitte erstellen. Das reduziert die kognitive Last und bringt Konsistenz, führt aber das Siloproblem wieder ein.\nPlatform Engineering: Der bessere Ansatz # Die bessere Lösung ist Platform Engineering. Sie behalten alle Produktteams, die mit DevOps-Praktiken an ihren Produkten arbeiten. Aber anstelle eines gemeinsamen Ops-Silos führen Sie ein Platform-Team ein, das eine Plattform baut und pflegt, auf der alle Produkte gebaut und gewartet werden können.\nJedes Produktteam behält seinen eigenen Produktbetrieb als Sub-Team oder dedizierte Personen, die das Produkt betreiben. Das Platform-Team stellt das Fundament bereit: Runtime, Developer Experience, CI/CD-Pipelines, Identity Management und Observability. Produktteams folgen weiterhin dem Prinzip \u0026ldquo;you build it, you run it.\u0026rdquo;\nDie zentrale Erkenntnis: Kunden zahlen nicht für Ihre Plattform. Sie zahlen für Ihre Produkte. Aber die Plattform generiert Wert für Ihre Teams und ermöglicht es ihnen, bessere Produkte zu bauen. Platform Engineering ermöglicht DevOps in Ihrem Unternehmen.\n\u0026ldquo;Platform Engineering nutzt DevOps-Praktiken, um eine Plattform zu liefern, auf der Produktteams ihre Produkte bauen und DevOps praktizieren können.\u0026rdquo;\nSite Reliability Engineering: DevOps für Hochverfügbarkeit # Es gibt auch Verwirrung darüber, ob SRE (Site Reliability Engineering) DevOps ersetzen wird. SRE wurde 2004 von Google eingeführt. Es geht um den Bau von hochverfügbaren, hochzuverlässigen, hochskalierbaren Systemen.\nDie Unterscheidung ist praktisch. Wenn Ihr System zwei Neunen Verfügbarkeit braucht (14,4 Minuten Ausfallzeit pro Tag), machen Sie DevOps. Wenn Sie fünf Neunen brauchen (864 Millisekunden Ausfallzeit pro Tag), brauchen Sie SRE. Site Reliability Engineers sind T-förmige Menschen, die viel über Betrieb und Entwicklung wissen. Sie nutzen DevOps-Praktiken, um Systeme zu bauen und zu warten, die extreme Zuverlässigkeit benötigen.\nEin Fünf-Neunen-System zu entwickeln ist um ein Vielfaches komplexer und zeitaufwändiger als ein Zwei-Neunen-System. SRE ist kein Ersatz für DevOps. Es ist eine Spezialisierung, die DevOps-Praktiken für Hochverfügbarkeitsszenarien nutzt.\nDas Denkmodell: Wie alles zusammenpasst # Ich verwende folgendes Modell, um die Beziehungen zu visualisieren:\nLean (1940er): Das Toyota Production System, das Fundament von allem. Agile (2000): Das Agile Manifest, aufgebaut auf Lean-Prinzipien. DevOps: Aufgebaut auf Agile und Lean. Alle Menschen, Prozesse und Technologien zusammenbringen, um kontinuierlich Wert zu liefern. Platform Engineering: Nutzt DevOps-Praktiken, um eine Plattform zu liefern, die Produktteams ermöglicht, DevOps zu praktizieren. SRE: Nutzt DevOps-Praktiken, um hochskalierbare, hochzuverlässige, hochverfügbare Produkte zu bauen. DevOps ist nicht tot. Es ist das Fundament, auf dem Platform Engineering und SRE aufbauen.\nKernaussagen # \u0026ldquo;DevOps ist tot\u0026rdquo; kommt von schlechten Implementierungen. Wenn Unternehmen DevOps-Silos erstellen oder DevOps an günstige Standorte auslagern, scheitert es. Das ist kein Problem von DevOps. Es ist ein Problem der Implementierung.\nDevOps betrifft alle Menschen. Nicht nur Dev und Ops. Security, Business, Architektur, Compliance, QA und alle anderen, die am Wertstrom arbeiten.\nPlatform Engineering ermöglicht DevOps im grossen Massstab. Es bietet das standardisierte Fundament, damit Produktteams sich auf die Wertlieferung konzentrieren können, anstatt Tooling neu zu erfinden.\nSRE ist eine DevOps-Spezialisierung. Es nutzt dieselben Praktiken für Systeme, die extreme Verfügbarkeit und Zuverlässigkeit erfordern.\nDas Fundament ist klar. Lean ermöglicht Agile. Agile ermöglicht DevOps. DevOps ermöglicht Platform Engineering und SRE. Keines ersetzt das andere.\n","date":"10. January 2023","externalUrl":null,"permalink":"/de/blogs/devops-ist-tot-platform-engineering-sre/","section":"Blogs","summary":"Das Internet ist voll von Beiträgen, die behaupten, DevOps sei tot. “DevOps ist Schwachsinn.” “Platform Engineering wird DevOps ersetzen.” “SRE ist die Zukunft.” In diesem Video erkläre ich, warum all diese Behauptungen falsch sind, woher sie kommen und wie DevOps, Platform Engineering und Site Reliability Engineering tatsächlich zusammenhängen.\n","title":"DevOps ist tot? Warum Platform Engineering und SRE DevOps mehr denn je brauchen","type":"blogs"},{"content":"","date":"10 January 2023","externalUrl":null,"permalink":"/en/tags/lean/","section":"Tags","summary":"","title":"Lean","type":"tags"},{"content":"","date":"10 January 2023","externalUrl":null,"permalink":"/en/tags/site-reliability-engineering/","section":"Tags","summary":"","title":"Site Reliability Engineering","type":"tags"},{"content":"","date":"10 January 2023","externalUrl":null,"permalink":"/en/tags/sre/","section":"Tags","summary":"","title":"SRE","type":"tags"},{"content":"","date":"6 January 2023","externalUrl":null,"permalink":"/en/tags/company-culture/","section":"Tags","summary":"","title":"Company Culture","type":"tags"},{"content":"","date":"6 January 2023","externalUrl":null,"permalink":"/en/tags/cultural-change/","section":"Tags","summary":"","title":"Cultural Change","type":"tags"},{"content":"Romano Roth is Chief of DevOps at Zühlke. In this interview, he explains why DevOps is not bullshit, how transformation succeeds in companies, and what IT students really need to learn.\nAn interview by Daniel Ziegener, published on January 7, 2023, at 11:14 AM on https://www.golem.de/news/devops-wenn-wir-ueber-devops-reden-muessen-wir-ueber-menschen-reden-2301-170592.html\nFor some, DevOps is a collection of methods for product development; for others, it\u0026rsquo;s simply bullshit. In the Golem.de newsletter \u0026ldquo;Chefs von Devs\u0026rdquo;, Romano Roth, Chief of DevOps at Zühlke, explained why DevOps is not bullshit, and why some people still think it is. Because developers \u0026ldquo;who say DevOps is bullshit are often trapped in a role somewhere between Dev and Ops,\u0026rdquo; he says.\nGolem.de: Mr. Roth, what is DevOps to you, and why isn\u0026rsquo;t it bullshit?\nRomano Roth: DevOps is not bullshit because it helps with an important problem: We keep throwing things over the Walls of Confusion. The business has many good ideas. They write these ideas as requirements in Word documents or Jira tickets and then throw them over the Wall of Confusion to the developers. The developers look at them and say: If that\u0026rsquo;s what you want, we\u0026rsquo;ll develop it for you.\nAfter development, it goes into the build pipeline, where the testing team notices that the result doesn\u0026rsquo;t match the requirements. They test something anyway, somehow it turns green and moves on. Operations wonders how this is supposed to be operated at all, but they figure it out somehow. Then it goes back and the business says: That\u0026rsquo;s not what we ordered!\nOn one hand, we have the problem of organizational silos; on the other hand, we have the problem that we\u0026rsquo;re still working in projects but developing products. In a project, we focus on output: number of features, stories, code, and so on. With a product, we focus on outcome. We want to solve the customer\u0026rsquo;s problem, change their behavior. It might be that we can achieve this with a single feature.\nA product also has no start or end date but is continuously developed. Therefore, we need to organize ourselves along this continuous value stream, instead of specifying for months, then implementing for months, and testing for months. This needs to happen incrementally and continuously. And that\u0026rsquo;s where DevOps helps.\nGolem.de: How can a concrete term like DevOps represent the entire value stream?\nRoth: When we talk about DevOps, we also need to talk about people. DevOps is a poorly chosen term because it technically means \u0026ldquo;Development and Operations.\u0026rdquo; Now some people try to fix this by including Security. Then we have DevSecOps. Others say: \u0026ldquo;But the business is even more important\u0026rdquo; - and we get BizDevOps. But even this term falls short. Because it\u0026rsquo;s about all the people who work on the value stream.\nWe would actually need a term like DevSecBizArcComQaOps. And I\u0026rsquo;m sure I\u0026rsquo;ve forgotten someone there too. We could also call it Dev*Ops or DevXOps. But let\u0026rsquo;s just call it DevOps. Because DevOps is about bringing all people, technologies, and processes together to continuously create value. That\u0026rsquo;s the core of DevOps.\nGolem.de: So is the \u0026ldquo;bullshit debate\u0026rdquo; mainly about misunderstandings and terminology?\nRoth: I believe: yes. The people who say DevOps is bullshit are often trapped in a role somewhere between Dev and Ops. They only see a small part of the entire value stream, and can\u0026rsquo;t optimize it either. This leads to friction and frustration. In the articles that call DevOps bullshit, it\u0026rsquo;s usually about a developer being overloaded or overwhelmed because they\u0026rsquo;re supposed to wear so many hats but can\u0026rsquo;t change the system.\nWhen management thinks they can eliminate Ops and have the Devs take over, it leads to exactly these problems. But it\u0026rsquo;s not the purpose of DevOps to eliminate a person or their skillset, but to bring people together so they can continuously create value.\nWell-intentioned, poorly implemented # Golem.de: So DevOps is well-intentioned but poorly implemented.\nRoth: Oh yes. When we want to organize along the value stream, it means we need to change the organization. When changing an organization, there\u0026rsquo;s always a loss of power.\nDecisions are now made by a team, and you as a manager suddenly have less decision-making authority. This often leads to problems because leadership must also change along with the organization. The classic manager must now transform into a leader or coach. Unfortunately, most companies don\u0026rsquo;t take this step. I\u0026rsquo;ve seen this actively torpedoed because careers are at stake.\nI\u0026rsquo;ve talked to people in companies where we conducted a transformation who told me: \u0026ldquo;I don\u0026rsquo;t know what to do anymore; I\u0026rsquo;ve worked toward this position for ten years, and now this entire career path no longer exists.\u0026rdquo; They were department heads, but when you dissolve silos and empower teams, this position is no longer needed. I can understand this frustration. However, this is how it must be done if things are really going to change: Either you change the process organization, or, even better, the structural organization. But most companies shy away from the latter.\nGolem.de: Zühlke is no longer a young company. How was the structural change implemented at Zühlke?\nRoth: We had exactly the same problems, and it took a while for this to be understood. With us too, some people had to give up power. Previously, we always had to pitch to the executive board when we wanted to implement a new idea that required time and money. Sometimes the executive board understood the idea, sometimes we got budget, sometimes not.\nWe introduced an adapted form of the helix organization and organized ourselves along the value stream. On the horizontal, we have market units that focus on our core markets. On the vertical, we have our practices that provide the competencies. Each market unit and practice has its own budget and uses it as they see fit. This has led to more autonomy and entrepreneurial thinking. We now have fewer managers, and some of them had to accept new roles.\nGolem.de: What are good ways to introduce DevOps from your perspective, perhaps also in a company that doesn\u0026rsquo;t have this engineering mindset?\nRoth: It\u0026rsquo;s like everything: Start small. Try to select a team with suitable people who have a certain lighthouse character and are well networked in the company. Show the company that it works. And from there, you change the next product and the next, and so on. Do this on a rolling basis; don\u0026rsquo;t try to introduce it everywhere at once.\nSuch change processes can also paralyze companies. If you introduce change too big, your company will only be busy with this change. If you introduce it continuously, you have the chance that the company can better digest the change and learn continuously. But it also takes longer.\nToo little patience in transformation # The annoying thing for the CEO is that such an approach takes several years. They often want quick results. Especially with publicly traded companies, they want to make the big throw and then complete the transformation. The thing is: Such a transformation never ends. It\u0026rsquo;s a continuous process.\nGolem.de: Now we\u0026rsquo;ve talked about how companies transform their processes. But how did you come to the conclusion that DevOps is the best way to organize such a value stream?\nRoth: Basically through laziness (laughs). When I started at Zühlke as a programmer after university in 2002, it annoyed me that I always had to run the same tests on my applications. You make a change and have to run the same tests manually again. Because that was too stupid for me, I started automating, after all, I\u0026rsquo;m a programmer!\nThe tests grew larger over time, more sophisticated, but also more maintenance-intensive. But they were always run locally. Then came Team Foundation Server. A continuous integration system. That was my first gentle touch point with \u0026ldquo;DevOps.\u0026rdquo;\nGolem.de: So you laid the foundation for your current position 20 years ago.\nRoth: Basically, yes. It\u0026rsquo;s a journey where you make mistakes, learn, and continuously build the mindset. But I think the biggest impact came from the books The Phoenix Project, DevOps Handbook, and Accelerate. Before these books, I had various solution approaches for challenges. After reading these books, I really understood why these solution approaches work.\nGood education and startup promotion in Switzerland # Golem.de: Zühlke is headquartered in Switzerland. How is the technology industry there?\nRoth: You see many startups that come but also go. There are pure software startups like Doodle. Much more interesting are startups like Cellsius, developing the battery-powered aircraft E-Sling. Or Cutiss, producing artificial skin by the meter that can be used for burn victims.\nWhen I look at the startup scene in Switzerland, I see a trend toward cyber-physical systems, a combination of hardware and software. Currently, you see many fintech startups having problems and disappearing again.\nGolem.de: Why are these products more common in Switzerland than pure software applications?\nRoth: I see an interesting point here: DevOps comes from Agile, Agile comes from Lean, and Lean comes from the Toyota Production System, from factories. Currently, I see this approach also increasingly arriving in hardware-related development in Switzerland.\nGolem.de: Does such a workflow, such a philosophy, directly influence the type of products created with it?\nRoth: I believe the influence is very large. You have an iterative approach with which you can take small experiments, get feedback, and then build your product so that it solves the customer\u0026rsquo;s problem. The startups in Switzerland have figured this out.\nGolem.de: Does Switzerland owe its startup scene to good education?\nRoth: Good education is very important, and ETH really has sensationally good education. But I wouldn\u0026rsquo;t attribute it solely to that; company founding is also supported. Startup promotion is the key, but if our students weren\u0026rsquo;t so well educated, they wouldn\u0026rsquo;t even get that far.\nEnd-to-end development \u0026ldquo;criminally neglected\u0026rdquo; # What I also criticize repeatedly in Switzerland is that while you learn the technology, how to program or set up a Kubernetes cluster, end-to-end product development is still criminally neglected in my opinion. Yet you save a lot of money and time when you develop the right thing correctly, so that it\u0026rsquo;s also testable and operable.\nGolem.de: Should students learn more about processes in a company?\nRoth: In my opinion, yes. Students should think not in projects but in products that have concrete benefits, are testable, and are operable.\nGolem.de: How often do you see code yourself?\nRoth: There are things you can solve brilliantly with code, but at some point, you reach the point where you realize there are challenges you can\u0026rsquo;t solve with code. You also recognize that solving these challenges solves many problems for programmers, yes, that it even leads to code not having to be written, or the right code being written correctly. Nevertheless, I try to always stay fit at coding.\nI participate in the Open Hacks at Zühlke; there we mostly do pair programming. Of course, I\u0026rsquo;m no longer as fit as my colleagues, but I try to stay on it. In product development, I\u0026rsquo;m usually away from code, but through my broad technical know-how, I can drive many things in the right direction.\nGolem.de: And what is the right direction?\nRoth: With the speed of new technological possibilities, companies need to reorganize so they don\u0026rsquo;t miss digitalization. This means they need to organize along the value stream.\nProduct teams continuously deliver value for customers via digital conveyor belts (CI/CD pipelines). These digital conveyor belts are, in turn, the product of the Platform Engineering team, which ensures that product teams can deliver value as efficiently and independently as possible. This is the industrialization of software development, the digital factory of the future.\nOriginal Article: Golem.de: DevOps: \u0026ldquo;Wenn wir über DevOps reden, müssen wir über Menschen reden\u0026rdquo;\n","date":"6 January 2023","externalUrl":null,"permalink":"/en/blogs/golem-de-interview-when-we-talk-about-devops-we-need-to-talk-about-people/","section":"Blogs","summary":"Romano Roth is Chief of DevOps at Zühlke. In this interview, he explains why DevOps is not bullshit, how transformation succeeds in companies, and what IT students really need to learn.\n","title":"Golem.de Interview: \"When we talk about DevOps, we need to talk about people\"","type":"blogs"},{"content":"Romano Roth ist Chief of DevOps bei Zühlke. Im Interview erklärt er, warum DevOps kein Bullshit ist, wie die Transformation im Unternehmen gelingt und was IT-Studenten wirklich lernen sollten.\nEin Interview von Daniel Ziegener veröffentlicht am 7. Januar 2023, 11:14 Uhr auf https://www.golem.de/news/devops-wenn-wir-ueber-devops-reden-muessen-wir-ueber-menschen-reden-2301-170592.html\nFür die einen ist DevOps eine Methodensammlung zur Produktentwicklung, für andere schlichtweg Bullshit. Im Golem.de-Newsletter Chefs von Devs erklärte Romano Roth, der Chief of DevOps bei Zühlke, warum DevOps kein Bullshit ist, und es manche dennoch dafür halten. Denn Entwickler, \u0026ldquo;die sagen, dass DevOps Bullshit ist, sind häufig in einer Rolle irgendwo zwischen Dev und Ops gefangen\u0026rdquo;, sagt er.\nGolem.de: Herr Roth, was ist DevOps für Sie, und warum ist es kein Bullshit?\nRomano Roth: DevOps ist kein Bullshit, denn es hilft bei einem wichtigen Problem: Wir schmeißen immer wieder Dinge über die Walls of Confusion. Das Business hat viele gute Ideen. Diese Ideen schreiben sie als Anforderungen in Word-Dokumenten oder Jira-Tickers nieder und schmeißen sie dann über die Wall of Confusion zu den Entwicklern. Die schauen sich das an und sagen sich: Wenn ihr das so haben wollt, entwickeln wir das für euch.\nNach der Entwicklung geht es in die Build-Pipeline, wo das Testing-Team merkt, dass das Ergebnis nicht mit den Anforderungen übereinstimmt. Sie testen trotzdem irgendwas, irgendwie ist es dann grün und geht weiter. Der Betrieb fragt sich, wie das überhaupt betrieben werden soll, aber sie kriegen es irgendwie hin. Dann geht es zurück und das Business sagt: Das haben wir gar nicht bestellt! Auf der einen Seite haben wir das Problem der Organisationssilos, auf der anderen Seite das Problem, dass wir immer noch in Projekten arbeiten, aber Produkte entwickeln. Bei einem Projekt fokussieren wir uns auf den Output: Anzahl der Features, Stories, Code und so weiter. Bei einem Produkt fokussieren wir uns auf das Outcome. Wir wollen das Problem des Kunden lösen, sein Verhalten ändern. Es kann sein, dass wir das mit einem einzigen Feature hinbekommen.\nEin Produkt hat auch kein Start- oder Enddatum, sondern wird kontinuierlich entwickelt. Daher müssen wir uns entlang dieses kontinuierlichen Wertstroms organisieren, statt monatelang zu spezifizieren, dann monatelang zu implementieren und monatelang zu testen. Das muss inkrementell und kontinuierlich passieren. Und da hilft DevOps.\nGolem.de: Wie kann ein konkreter Begriff wie DevOps denn den gesamten Wertstrom abbilden?\nRoth: Wenn wir über DevOps reden, müssen wir auch über Menschen reden. DevOps ist ein schlecht gewählter Begriff, denn es heißt genau genommen \u0026ldquo;Development and Operation\u0026rdquo;. Nun versuchen manche Leute das zu beheben, indem sie Security mit reinnehmen. Dann haben wir Devsecops. Wieder andere sagen: \u0026ldquo;Aber das Business ist noch wichtiger\u0026rdquo;, und wir bekommen BizDevOps . Aber auch dieser Begriff ist zu kurz gegriffen. Denn es geht um alle Personen, die am Wertstrom arbeiten.\nEigentlich bräuchten wir einen Begriff wie Devsecbizarccomqaops. Und ich bin sicher, ich habe da auch noch jemanden vergessen. Wir könnten es auch Dev*Ops oder DevXops nennen. Aber nennen wir es doch einfach DevOps. Denn bei DevOps geht es darum, alle Personen, Technologien und Prozesse zusammenzubringen, um kontinuierlich Wert zu schaffen. Das ist der Kern von Devops.\nGolem.de: Geht es bei der \u0026ldquo;Bullshit-Debatte\u0026rdquo; also vor allem um Missverständnisse und Begrifflichkeiten?\nRoth: Ich bin der Meinung: ja. Die Personen, die sagen, dass DevOps Bullshit sei, sind häufig in einer Rolle irgendwo zwischen Dev und Ops gefangen. Sie sehen nur einen kleinen Teil des gesamten Wertstroms, und können ihn auch nicht optimieren. Das führt zu Friktionen und Frust. In den Artikeln, die DevOps Bullshit nennen, geht es meistens darum, dass ein Entwickler überlastet oder überfordert ist, weil er so viele Hüte aufhaben soll, aber das System nicht ändern kann.\nWenn das Management denkt, sie können Ops eliminieren und die Devs übernehmen das, führt das genau zu solchen Problemen. Aber es ist gar nicht Sinn und Zweck von DevOps, eine Person oder ihr Skillset zu eliminieren, sondern Leute zusammenzubringen, damit sie kontinuierlich Wert schaffen können.\nGut gemeint, schlecht umgesetzt # Golem.de: DevOps ist also gut gemeint, aber schlecht umgesetzt.\nRoth: Oh ja. Wenn wir uns entlang des Wertstroms organisieren wollen, heißt das, dass wir die Organisation verändern müssen. Bei der Veränderung einer Organisation kommt es immer zu einem Machtverlust.\nEntscheidungen werden neu von einem Team getroffen und du als Manager hast plötzlich weniger Entscheidungsspielraum. Das führt ganz oft zu Problemen, weil sich mit der Organisation auch die Führung ändern muss. Der klassische Manager muss sich nun zum Leader oder Coach wandeln. Diesen Schritt gehen die meisten Unternehmen aber leider nicht. Ich habe schon erlebt, dass das ganz konkret torpediert wird, da Karrieren auf dem Spiel stehen.\nIch habe schon mit Leuten in Unternehmen geredet, in denen wir eine Transformation durchgeführt haben, die mir sagten: \u0026ldquo;Ich weiß nicht mehr, was ich machen soll, ich habe jetzt zehn Jahre auf diese Position hingearbeitet und jetzt gibt es diesen ganzen Karrierepfad nicht mehr.\u0026rdquo; Die waren Abteilungsleiter, aber wenn man Silos auflöst und Teams befähigt, braucht es diesen Posten nicht mehr. Diesen Frust kann ich verstehen. Allerdings muss das so gemacht werden, wenn sich wirklich etwas ändern soll: Entweder man verändert die Ablauforganisation, oder, noch besser, die Aufbauorganisation. Aber vor Letzterem scheuen sich die meisten Unternehmen.\nGolem.de: Zühlke ist jetzt kein junges Unternehmen mehr. Wie wurde der Strukturwandel bei Zühlke umgesetzt?\nRoth: Wir hatten genau die gleichen Probleme und es dauerte eine Weile, bis das verstanden wurde. Auch bei uns war es so, dass manche Personen Macht abgeben mussten. Früher mussten wir immer bei der Geschäftsführung pitchen, wenn wir eine neue Idee, für die wir Zeit und Geld brauchten, umsetzen wollten. Manchmal hat die Geschäftsführung die Idee verstanden, manchmal haben wir Budget bekommen, manchmal auch nicht.\nWir haben eine angepasste Form der Helix-Organisation eingeführt und uns damit entlang des Wertstroms organisiert. Auf der Horizontalen haben wir die Markt-Units, die sich auf unsere Kernmärkte konzentrieren. Auf der Vertikalen haben wir unsere Practices, die die Kompetenzen bereitstellen. Jede Markt-Unit und Practice hat ihr eigenes Budget und setzt es ein, wie sie es für richtig hält. Das hat zu mehr Autonomie und unternehmerischem Denken geführt. Wir haben jetzt weniger Manager und einige von ihnen mussten sich auch mit neuen Rollen zufriedengeben.\nGolem.de: Was sind aus Ihrer Sicht gute Wege, um DevOps einzuführen, vielleicht auch in einem Unternehmen, das nicht dieses Ingenieursverständnis hat?\nRoth: Es ist wie mit allem: Starte klein. Versuch ein Team mit geeigneten Personen auszuwählen, die einen gewissen Leuchtturmcharakter haben und gut im Unternehmen vernetzt sind. Zeig dem Unternehmen so, dass es funktioniert. Und von da aus änderst du das nächste Produkt und das nächste und so weiter. Mach das rollierend, versuche es nicht überall gleichzeitig einzuführen.\nSolche Change-Prozesse können Unternehmen auch lähmen. Wenn du Change zu groß einführst, wird dein Unternehmen nur mit diesem Change beschäftigt sein. Wenn du ihn kontinuierlich einführst, hast du die Chance, dass das Unternehmen den Change besser verdauen und kontinuierlich lernen kann. Aber es dauert auch länger.\nZu wenig Geduld bei der Transformation # Das Blöde für den CEO ist, dass so ein Ansatz mehrere Jahre dauert. Ganz oft wollen sie schnelle Ergebnisse. Vor allem bei börsennotierten Unternehmen ist es so, dass man den großen Wurf machen und die Transformation dann abschließen will. Das Ding ist nur: So eine Transformation endet nie. Das ist ein kontinuierlicher Prozess.\nGolem.de: Jetzt haben wir darüber gesprochen, wie die Unternehmen ihre Prozesse transformieren. Aber wie sind Sie denn zu der Einschätzung gekommen, dass DevOps der beste Weg ist, so einen Wertstrom zu organisieren?\nRoth: Im Prinzip durch Faulheit (lacht). Als ich nach der Universität, im Jahre 2002, bei Zühlke als Programmierer angefangen habe, hat mich genervt, dass ich immer wieder die gleichen Tests bei meinen Applikationen durchführen musste. Du machst eine Änderung und musst schon wieder die gleichen Tests manuell durchführen. Weil mir das zu blöd war, habe ich angefangen zu automatisieren, immerhin bin ich ja Programmierer!\nDie Tests wurden mit der Zeit immer größer, ausgefeilter, aber auch wartungsintensiver. Aber sie wurden immer lokal durchgeführt. Dann kam der Team-Foundation-Server. Ein Continuous Integration System, das war mein erster zarter Berührungspunkt mit \u0026ldquo;DevOps\u0026rdquo;.\nGolem.de: Also haben Sie den Grundstein für Ihre jetzige Position schon vor 20 Jahren gelegt.\nRoth: Im Prinzip schon. Es ist eine Journey, in der man Fehler macht, lernt und so kontinuierlich das Mindset aufbaut. Aber ich glaube, den größten Impact hatten die Bücher The Phoenix Project, DevOps Handbook, Accelerate. Vor diesen Büchern hatte ich verschiedene Lösungsansätze für Herausforderungen. Nach dem Lesen dieser Bücher hatte ich wirklich verstanden, warum diese Lösungsansätze funktionieren.\nGute Ausbildung und Start-up-Förderung in der Schweiz # Golem.de: Zühlke hat seinen Sitz in der Schweiz. Wie steht es um die Technologiebranche dort?\nRoth: Man sieht viele Start-ups, die kommen, aber auch gehen. Da sind pure Software-Start-ups wie Doodle dabei. Viel interessanter sind Start-ups wie Cellsius, die das batteriebetriebene Flugzeug E-Sling entwickeln. Oder Curtiss, die am Laufmeter künstliche Haut herstellen, die bei Verbrennungsopfern eingesetzt werden kann.\nWenn ich die Start-up-Szene in der Schweiz anschaue, erkenne ich einen Trend in Richtung von cyberphysikalischen Systemen, also einer Kombination von Hardware und Software. Aktuell sieht man viele Finanz-Start-ups, die Probleme haben und wieder verschwinden.\nGolem.de: Warum sind diese Produkte in der Schweiz verbreiteter als reine Softwareanwendungen?\nRoth: Ich sehe da einen interessanten Punkt: DevOps kommt von Agile, Agile kommt von Lean und Lean kommt vom Toyota Production System, also aus Fabriken. Zurzeit sehe ich, dass dieser Ansatz auch immer stärker bei der hardwarenahen Entwicklung in der Schweiz ankommt.\nGolem.de: Beeinflusst so ein Workflow, so eine Philosophie, also direkt die Art von Produkten, die damit entstehen?\nRoth: Ich glaube, der Einfluss ist sehr groß. Du hast einen iterativen Ansatz, mit dem du kleine Experimente wagen, Feedback einholen und dann dein Produkt so bauen kannst, dass es das Problem des Kunden löst. Die Start-ups in der Schweiz haben das geschnallt.\nGolem.de: Hat die Schweiz ihre Start-up-Szene der guten Ausbildung zu verdanken?\nRoth: Eine gute Ausbildung ist sehr wichtig und die ETH hat wirklich eine sensationell gute Ausbildung. Ich würde es aber nicht nur darauf zurückführen, die Firmengründung wird nämlich auch gefördert. Start-up-Förderung ist der Key, aber wenn unsere Studenten nicht so gut ausgebildet wären, würden sie gar nicht erst so weit kommen.\nEnt-to-End-Entwicklung \u0026ldquo;sträflich vernachlässigt\u0026rdquo; # Was ich auch in der Schweiz immer wieder bemängele, ist, dass man zwar die Technik lernt, also zu programmieren oder ein Kubernetes-Cluster aufzusetzen. Aber End-to-End-Entwickeln von Produkten wird meiner Meinung nach noch sträflich vernachlässigt. Dabei spart man viel Geld und Zeit, wenn man das Richtige richtig entwickelt, so dass es auch testbar und betreibbar ist.\nGolem.de: Sollten die Studenten also schon mehr über die Prozesse in einem Unternehmen lernen?\nRoth: Meiner Meinung nach ja. Studenten sollten nicht in Projekten, sondern in Produkten denken, die einen konkreten Nutzen haben, testbar und betreibbar sind.\nGolem.de: Wie oft sehen Sie selbst noch Code?\nRoth: Es gibt Dinge, die du großartig mit Code lösen kannst, aber irgendwann kommst du an den Punkt, wo du merkst, dass es Herausforderungen gibt, die du nicht mit Code lösen kannst. Du erkennst dann auch, dass das Lösen dieser Herausforderungen viele Probleme der Programmierer löst, ja, dass es sogar dazu führt, dass Code nicht geschrieben werden muss oder eben der richtige Code richtig geschrieben werden kann. Nichtsdestotrotz versuche ich, immer fit zu bleiben beim Coden.\nIch mache bei den Open Hacks bei Zühlke mit, dort machen wir meistens Pair Programming. Ich bin natürlich nicht mehr so fit wie meine Kollegen, aber ich versuche dranzubleiben. In der Produktentwicklung bin ich meistens weg vom Code, aber durch mein breites technisches Know-how kann ich sehr viele Dinge in die richtige Richtung treiben.\nGolem.de: Und was ist die richtige Richtung?\nRoth: Mit der Geschwindigkeit neuer technologischer Möglichkeiten müssen Unternehmen sich umorganisieren, damit sie die Digitalisierung nicht verpassen. Das heißt, sie müssen sich entlang des Wertstroms organisieren.\nProduktteams liefern mittels digitaler Förderbänder (CI/CD Pipelines) kontinuierlich Wert für die Kunden. Diese digitalen Förderbänder sind wiederum das Produkt des Plattform Engineering Teams, das sicherstellt, dass die Produktteams so effizient und unabhängig wie möglich Wert liefern können. Das ist die Industrialisierung der Softwareentwicklung, die digitale Fabrik der Zukunft.\nOriginal Artikel: Golem.de: DevOps: \u0026ldquo;Wenn wir über DevOps reden, müssen wir über Menschen reden\u0026rdquo;\n","date":"6. January 2023","externalUrl":null,"permalink":"/de/blogs/interview-mit-golem-de-wenn-wir-ueber-devops-reden-muessen-wir-ueber-menschen-reden/","section":"Blogs","summary":"Romano Roth ist Chief of DevOps bei Zühlke. Im Interview erklärt er, warum DevOps kein Bullshit ist, wie die Transformation im Unternehmen gelingt und was IT-Studenten wirklich lernen sollten.\nEin Interview von Daniel Ziegener veröffentlicht am 7. Januar 2023, 11:14 Uhr auf https://www.golem.de/news/devops-wenn-wir-ueber-devops-reden-muessen-wir-ueber-menschen-reden-2301-170592.html\n","title":"Interview mit Golem.de: Wenn wir über DevOps reden, müssen wir über Menschen reden","type":"blogs"},{"content":"","date":"6 January 2023","externalUrl":null,"permalink":"/en/tags/people-first/","section":"Tags","summary":"","title":"People First","type":"tags"},{"content":"","date":"6 January 2023","externalUrl":null,"permalink":"/en/tags/team-collaboration/","section":"Tags","summary":"","title":"Team Collaboration","type":"tags"},{"content":"Bei dieser Veranstaltung durfte ich gemeinsam mit Carsten Brandt von SAP über DevOps in der Theorie und Praxis sprechen. Während ich die theoretischen Grundlagen von DevOps vorstellte und zeigte, wie Unternehmen von Projekten zu Produkten gelangen, brachte Carsten die Praxisperspektive aus über 21 Jahren SAP ein. Seine ehrliche Botschaft: Die Theorie steht seit Jahren, aber die Umsetzung ist alles andere als einfach, besonders in komplexen Enterprise-Landschaften.\nVon Projekten zu Produkten # Ein zentrales Problem, das ich bei vielen Unternehmen sehe, sind die sogenannten \u0026ldquo;Walls of Confusion\u0026rdquo;. Das Business schreibt Anforderungen in Word-Dokumente oder Jira-Tickets und wirft sie über die Mauer zum Entwicklungsteam. Das Entwicklungsteam implementiert, was es versteht, und reicht es weiter an das Testing. Das Testing stellt fest, dass Spezifikation und Code nicht zusammenpassen, testet trotzdem etwas, und der Betrieb fragt sich am Ende, wie er das Ganze überhaupt betreiben soll.\nDie Wurzel dieses Problems liegt oft im Projektdenken. Projekte haben einen definierten Startpunkt, ein definiertes Ende, ein Budget und ein Pflichtenheft. Der Fokus liegt auf dem Output: Maximierung der Anzahl Features, User Stories und Code. Aber unsere Kunden wollen eigentlich Produkte. Sie wollen, dass wir ihre Probleme lösen. Der Fokus muss auf dem Outcome liegen, nicht auf dem Output.\n\u0026ldquo;DevOps ist eine Denkweise, eine Kultur und ein Set von technischen Praktiken, welches uns erlaubt, uns rund um den Wertstrom zu organisieren und kontinuierlich Wert zu liefern.\u0026rdquo;\nDevOps hilft bei diesem Wandel, indem es alle Menschen, Prozesse und Technologien zusammenbringt. Der Begriff \u0026ldquo;DevOps\u0026rdquo; ist dabei nicht ideal, weil er nur Development und Operation nennt. Eigentlich bräuchten wir einen Begriff wie \u0026ldquo;DevSecBizArchCompQAOps\u0026rdquo;, aber im Kern geht es darum: alle Beteiligten zusammenbringen, um kontinuierlich Wert zu liefern.\nDie Wissenschaft hinter DevOps # Die wissenschaftlichen Daten sind eindeutig. Unternehmen, die DevOps praktizieren, haben 208-mal häufigere Deployments in die Produktion, sind 106-mal schneller im Liefern von Features, sind 2.604-mal schneller bei der Wiederherstellung nach Ausfällen und haben eine 7-mal niedrigere Change-Failure-Rate pro Deployment. Zwischen 2019 und 2021 hat sich diese Beschleunigung sogar noch massiv verstärkt.\nIch zeigte auch das Beispiel von Tesla und Elon Musk: Am 7. Oktober 2021 rollte er den Autopiloten Version 10.2 an tausend Autobesitzer mit einem perfekten Safety Score aus. Das zeigt Canary Releases, Monitoring und modulare Software in fahrenden Autos. Am 24. Oktober machte er einen Rollback der Software in fahrenden Autos. Viele Unternehmen schaffen das nicht einmal mit ihrer regulären Software, aber Tesla macht es mit Fahrzeugen auf der Strasse.\nContinuous Delivery verstehen # Ein wichtiger Teil meiner Präsentation war die Erklärung der Continuous Delivery Pipeline. Continuous Integration bedeutet: Der Entwickler committed Code ins Source Code Repository, der Code wird reintegriert, gebaut, analysiert und getestet. Feedback kommt innerhalb von Minuten, nicht Stunden. Bei Continuous Delivery wird das Artefakt automatisch in ein Staging-Environment installiert. Bei Continuous Deployment geht es vollautomatisch in die Produktion, mit automatischen Tests und Rollback bei Fehlern.\nEbenso wichtig ist das Thema Qualität. Im traditionellen Testen nach dem V-Modell können drei bis sechs Monate vergehen, bevor ein Feature getestet wird. Beim agilen Testen mit Behaviour Driven Development schreiben wir die Akzeptanzkriterien in der \u0026ldquo;Gegeben-Wenn-Dann\u0026rdquo;-Form und leiten daraus Tests ab. So haben wir immer zuerst den Test, bevor wir den Code schreiben. Das ist das \u0026ldquo;Shift Left\u0026rdquo;, das wir erreichen wollen.\nDie Praxis-Perspektive: Warum Umsetzung so schwierig ist # Carsten Brandt brachte die ernüchternde Praxissicht ein. Seine ehrliche Ansage: \u0026ldquo;Die Theorie steht seit Jahren. Das ist alles schlüssig. Es gibt Beispiele, die das vormachen. Also müssen wir nur noch ausführen. Aber genau dieses \u0026lsquo;just execute\u0026rsquo; ist das Schwierige.\u0026rdquo;\nEr verwies auf eine Gartner-Studie, die zeigt, dass 75% aller DevOps-Initiativen nicht die erwarteten Ergebnisse bringen. Ein Hauptgrund: falsches oder gar kein Erwartungsmanagement. Teams sagen \u0026ldquo;wir wollen schneller liefern\u0026rdquo;, aber Schnelligkeit allein ist kein Wert. Carsten illustrierte das mit dem Monty-Python-Sketch des 100-Meter-Laufs für Menschen ohne Orientierungssinn: Alle rennen in unterschiedliche Richtungen. Schnelligkeit nützt nichts ohne das richtige Ziel.\n\u0026ldquo;Das Ziel ist eigentlich glücklichere Endkunden. Und in der Softwareentwicklung erreicht man das mit besserer Software. Schnelleres Ausliefern ist nur Mittel zum Zweck.\u0026rdquo;\nSystemdenken und die Einzigartigkeit jeder Organisation # Carstens wichtigste Botschaft: Man kann nicht einfach kopieren, was Netflix, Google oder Spotify machen. Jede Organisation ist ein einzigartiges System. Die Teile eines Systems beeinflussen sich gegenseitig, und das System hat Eigenschaften, die die einzelnen Teile nicht haben. Man kann ein Teil aus System A nicht einfach in System B verpflanzen und erwarten, dass es gleich funktioniert.\nEr brachte das schöne Beispiel des menschlichen Körpers: Das Herz hat kein Leben, die Lunge hat kein Leben, aber zusammen bilden sie ein System, das lebt. Genau so verhält es sich mit Organisationen. Was man tun kann, ist von anderen lernen und adaptieren, aber nicht eins zu eins kopieren.\nAuch das Lehman-Gesetz der Software-Evolution kam zur Sprache: Softwaresysteme müssen kontinuierlich angepasst werden, sonst werden sie immer weniger zufriedenstellend. Gleichzeitig wächst die Komplexität exponentiell mit der Lebensdauer. Dieses Dilemma erfordert einen klaren Fokus auf die Mutter aller Software-Engineering-Fragen: Was bringt dem Kunden Wert?\nKernaussagen # Von Projekten zu Produkten: Der Wechsel vom Output-Fokus zum Outcome-Fokus ist entscheidend für erfolgreiche Softwareentwicklung. Wertstrom verstehen: Value Stream Mapping macht den gesamten Wertstrom sichtbar und deckt Engpässe auf, die man dann gezielt beseitigen kann. Qualität vor Geschwindigkeit: Ohne Vertrauen in die Qualität kann man nicht schneller liefern. Testautomatisierung und Shift Left sind der Ausgangspunkt. Jede Organisation ist einzigartig: Es gibt keinen Blueprint, der von einer Firma zur nächsten kopiert werden kann. Lernen und adaptieren ist der Weg. Erwartungsmanagement ist entscheidend: Die meisten gescheiterten Transformationen scheitern an falschen oder fehlenden Erwartungen, nicht an der Technologie. Kundenwert als Nordstern: Die zentrale Frage muss immer sein, ob die Software ein echtes Problem des Kunden löst. ","date":"5. January 2023","externalUrl":null,"permalink":"/de/blogs/devops-mit-sap-theorie-und-praxis/","section":"Blogs","summary":"Bei dieser Veranstaltung durfte ich gemeinsam mit Carsten Brandt von SAP über DevOps in der Theorie und Praxis sprechen. Während ich die theoretischen Grundlagen von DevOps vorstellte und zeigte, wie Unternehmen von Projekten zu Produkten gelangen, brachte Carsten die Praxisperspektive aus über 21 Jahren SAP ein. Seine ehrliche Botschaft: Die Theorie steht seit Jahren, aber die Umsetzung ist alles andere als einfach, besonders in komplexen Enterprise-Landschaften.\n","title":"DevOps mit SAP: Theorie und Praxis","type":"blogs"},{"content":"At this event, I spoke alongside Carsten Brandt from SAP about DevOps in theory and practice. While I presented the theoretical foundations of DevOps and showed how companies can move from projects to products, Carsten brought the practical perspective from over 21 years at SAP. His honest message: the theory has been well established for years, but execution is anything but easy, especially in complex enterprise landscapes.\nFrom Projects to Products # A core problem I see at many companies is the so-called \u0026ldquo;Walls of Confusion.\u0026rdquo; Business teams write requirements in Word documents or Jira tickets and throw them over the wall to the development team. The development team implements what they understand and passes it to testing. Testing finds that the specification and code do not match, tests something anyway, and operations wonder how they are supposed to run any of it.\nThe root of this problem often lies in project thinking. Projects have a defined start, a defined end, a budget, and a requirements document. The focus is on output: maximizing the number of features, user stories, and code. But our customers actually want products. They want us to solve their problems. The focus must shift to outcomes, not output.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices that allows us to organize around the value stream and continuously deliver value.\u0026rdquo;\nDevOps helps with this shift by bringing all people, processes, and technologies together. The term \u0026ldquo;DevOps\u0026rdquo; is not ideal because it only names Development and Operations. We would actually need a term like \u0026ldquo;DevSecBizArchCompQAOps,\u0026rdquo; but at its core, it is about bringing everyone together to continuously deliver value.\nThe Science Behind DevOps # The scientific data is clear. Companies practicing DevOps have 208 times more frequent deployments to production, are 106 times faster at delivering features, are 2,604 times faster at restoring services after failures, and have a 7 times lower change failure rate per deployment. Between 2019 and 2021, this acceleration intensified even further.\nI also showed the Tesla example: On October 7, 2021, Elon Musk rolled out Autopilot version 10.2 to a thousand car owners with a perfect safety score. This demonstrates canary releases, monitoring, and modular software in driving cars. On October 24, he performed a software rollback on cars driving on the road. Many companies cannot even do this with their regular software, but Tesla does it with vehicles on the street.\nUnderstanding Continuous Delivery # An important part of my presentation was explaining the Continuous Delivery pipeline. Continuous Integration means: a developer commits code to the source code repository, the code gets reintegrated, built, analyzed, and tested. Feedback arrives within minutes, not hours. With Continuous Delivery, the artifact is automatically installed in a staging environment. With Continuous Deployment, it goes fully automatically into production, with automated tests and rollback on failure.\nEqually important is quality. In traditional V-model testing, three to six months can pass before a feature gets tested. In agile testing with Behaviour Driven Development, we write acceptance criteria in \u0026ldquo;Given-When-Then\u0026rdquo; format and derive tests from them. This way, we always have the test before we write the code. This is the \u0026ldquo;Shift Left\u0026rdquo; we want to achieve.\nThe Practice Perspective: Why Execution Is So Difficult # Carsten Brandt brought the sobering practical view. His honest message: \u0026ldquo;The theory has been there for years. It\u0026rsquo;s all logical. There are examples that show the way. So we just need to execute. But exactly this \u0026lsquo;just execute\u0026rsquo; is the hard part.\u0026rdquo;\nHe cited a Gartner study showing that 75% of all DevOps initiatives do not deliver the expected results. A main reason: poor or nonexistent expectation management. Teams say \u0026ldquo;we want to deliver faster,\u0026rdquo; but speed alone has no value. Carsten illustrated this with the Monty Python sketch of the 100-meter dash for people with no sense of direction: everyone runs in different directions. Speed is useless without the right goal.\n\u0026ldquo;The real goal is happier end customers. And in software development, you achieve that with better software. Faster delivery is merely a means to that end.\u0026rdquo;\nSystems Thinking and the Uniqueness of Every Organization # Carsten\u0026rsquo;s most important message: you cannot simply copy what Netflix, Google, or Spotify do. Every organization is a unique system. The parts of a system influence each other, and the system has properties that its individual parts do not possess. You cannot transplant a part from System A into System B and expect it to work the same way.\nHe used the beautiful analogy of the human body: the heart has no life on its own, the lungs have no life on their own, but together they form a system that lives. Organizations work exactly the same way. What you can do is learn from others and adapt, but not copy one-to-one.\nLehman\u0026rsquo;s Law of Software Evolution also came up: software systems must be continuously adapted, or they become progressively less satisfactory. At the same time, complexity grows exponentially with the system\u0026rsquo;s lifetime. This dilemma requires a clear focus on the mother of all software engineering questions: What brings value to the customer?\nKey Takeaways # From projects to products: The shift from output focus to outcome focus is essential for successful software development. Understand the value stream: Value Stream Mapping makes the entire value stream visible and uncovers bottlenecks that can then be addressed systematically. Quality before speed: Without trust in quality, you cannot deliver faster. Test automation and Shift Left are the starting point. Every organization is unique: There is no blueprint that can be copied from one company to the next. Learning and adapting is the way forward. Expectation management is critical: Most failed transformations fail because of wrong or missing expectations, not because of technology. Customer value as the North Star: The central question must always be whether the software solves a real customer problem. ","date":"5 January 2023","externalUrl":null,"permalink":"/en/blogs/devops-with-sap-theory-and-practice/","section":"Blogs","summary":"At this event, I spoke alongside Carsten Brandt from SAP about DevOps in theory and practice. While I presented the theoretical foundations of DevOps and showed how companies can move from projects to products, Carsten brought the practical perspective from over 21 years at SAP. His honest message: the theory has been well established for years, but execution is anything but easy, especially in complex enterprise landscapes.\n","title":"DevOps with SAP: Theory and Practice","type":"blogs"},{"content":"","date":"5 January 2023","externalUrl":null,"permalink":"/en/tags/sap/","section":"Tags","summary":"","title":"SAP","type":"tags"},{"content":"By Pia Wiedermayer and Romano Roth\nIn many organizations and projects, software development involves numerous employees and machines performing tasks separately. This approach results in problems. Here\u0026rsquo;s how going back to the original way of developing software and building an organic digital factory can help.\nIn today\u0026rsquo;s software development oodles of resources are consumed, and manual steps are carried out. The process phases run consecutively, completely separate from each other. After completing a phase (whether successful or not), the work results are tossed over the so-called ‘wall of confusion’. True to the motto of ‘devil-may-care’. This procedure results in the following main problems, which can be encountered in the same ways in a wide variety of organisations:\nMany manual steps, which make the overall process slow and susceptible to errors. Quality assurance and testing as separate phases at the end of the overall process. Security requirements and other non-functional requirements, such as load and performance or maintainability, are only discussed and checked just before final delivery. Lack of collaboration due to separate working areas and phases To make matters worse, there are transformation projects that do not take the organisation as a whole into consideration, but merely transfer new names to existing structures. We often come across departments that are now called Dev-[your department could appear here]-Ops, but operate in exactly the same way behind the new Agile façade and function just like they always have. The only difference is that everything has to be carried out in a faster and more agile way. This puts the employees and the entire organisation under tremendous pressure. There is a serious risk of wasting valuable resources and overwhelming employees. In times in which sustainability and the ‘war for talent’ are becoming increasingly important, organisations can no longer risk losing their best minds and carelessly damaging the environment.\nWe see great potential in a return to the original type of software development, which naturally includes interdisciplinary teams and close collaboration. Enriched with modern approaches such as DevOps, integrative quality assurance and Agile working methods, classic software development can solve the above-mentioned problems in an efficient and sustainable way. But what exactly do these terms mean?\nDevOps # DevOps is a mindset, a culture and a series of technical practices. It provides communication, integration, automation and close collaboration between all persons who are required for the planning, development, testing, provision, approval and maintenance of a product.\nBoth a cultural change and a change of mindset are of central importance when doing this. It’s no longer a case of ‘them’, but ‘us’. DevOps is based on teamwork. Mutual trust, empowerment, responsibility, continuous improvement, data-driven decision-making and customer empathy are central DevOps values.\nThe goal of DevOps is to speed up the market launch, make experimentation possible, release software at shorter intervals, reduce the lead time for bug fixing and improve the average restoration time. When doing this, it is not only about collaboration between Dev (development) and Ops (operations); it is about collaboration between all persons who are involved in the production of the product.\nAs shown in the illustration, these are development, security, business, architecture, compliance, quality assurance and operation. However, we are certain that we have forgotten a few groups of people.\nYou have probably already heard of the following new terms:\nDevSecOps: Dev = development, Sec = security, Ops = operations BizDevOps: Biz = business, Dev = development, Ops = operations These new terms are an attempt to complete the term DevOps with other groups of persons. Unfortunately, these new terms are also incomplete. This because a term such as DevSecBizArchCompQAOps or Dev*Ops or DevXOps would be needed to do justice to what we want to achieve with DevOps. For this reason, we will simply stick with DevOps, even though it is not the most ideal term. DevOps is all about bringing all persons, processes and technologies together for the purpose of continuous value creation.\nQuality Assurance # Quality assurance is often used as a synonym for testing. Since this is not only incorrect but introduces a considerable amount of confusion into the everyday working environment, we will explain the main characteristics and differences between the two terms in the following.\nQuality assurance is clearly process-oriented, whereas testing mainly focusses on the product. Testing is a part of quality assurance. Quality assurance, on the other hand, is a part of a larger quality control system, and is primarily about avoiding errors.\nThis ensures that the processes for managing and creating the results are functional. Well-tried (Agile) methods, such as reviews or retrospectives, are used to check whether this is the case. With quality assurance, it is also about technical processes that ensure that quality is achieved in an effective and efficient way (built-in quality). There is major synergy potential with DevOps at this point.\nTesting is an essential part of quality assurance. The main focus when doing this is on detection, i.e. finding bugs. Testing includes tasks for planning and control, analysis and design, implementation and execution, evaluation of termination criteria and reporting, as well as test completion activities. Testing also includes functional and technical reviews, and code inspections.\nTesting in Agile development requires a high degree of automation. However, the following applies here: quality over quantity! The fact that tests can be automated doesn’t say anything about whether they are meaningful. Each test, be it manual or automated, involves effort. The focus must therefore clearly be on having tests that add value.\nUnfortunately, the myth that test automation must replace manual testing is persistent. However, our experience has clearly shown that test automation is not a substitute for exploratory (manual) testing or specialists with comprehensive expertise. However, this role is clearly in a state of flux. Test automation tools and other development procedures help the entire team to work faster and more efficiently. This allows the individual team members to apply themselves to tasks for which the human brain is required.\nAgile and interdisciplinary collaboration # Agile work models change the nature of our collaboration. It is very dependent upon the organisation, its culture and its people as to whether this is positive or negative. Diversity is required in the team in order to efficiently experience and implement Agile practices. An entire football team consisting of strikers or defenders would only be moderately successful. It is the combination of different specialities that makes the difference and is the key to success.\nWith regard to product development, this means: away from the silos towards interdisciplinary teams that combine all of the disciplines and roles that are relevant for the product under a common team umbrella. Each discipline is equivalent, each team member is important and each role creates added value.\nAs simple as it sounds, it can be challenging to implement this in practice. An excellent starting point for interdisciplinary teams is the definition of common quality principles. Here, it is vital for the principles of the entire team to be jointly defined, understood and actively experienced and called for by every member of the team. These shared quality principles must not be equated with the ‘definition of done’ or ‘definition of ready’, which we know about from Scrum. The principles are more about the ‘definitions’, and form the shared values of the team.\nThe following well-tried approaches can provide a good jump-start and support in everyday interdisciplinary collaboration:\nThe 3 Amigos Whole-team testing The 3 Amigos # Good requirements require different perspectives. Business, development and testing/QA therefore work closely together during the entire product development cycle. All three disciplines must be involved at all times, from the requirements analysis to the cooperative definition of specific requirements (e.g. user stories) to development and final acceptance. This creates a common understanding, and minimises the likelihood of misunderstandings and errors.\nAttention must be paid to potential stumbling blocks:\nrestriction of the 3 Amigo discussions to just three people. If other people are involved who are relevant for a particular work step, they must be included in the discussion. expansion of the 3 Amigo discussion to the entire team. The goal of this practice is to involve every perspective that is needed in a group that is as small as possible. 3 Amigo discussions become regular meetings, and are dealt with as an additional team ceremony rather than being a practical road map for the perspectives that should be involved in a discussion about a particular work increment. Whole-team testing # The essence of whole-team testing is shared team responsibility for quality assurance and testing. This means that testing is no longer exclusively the task and the focus of professional testers, but of each individual person within the team. The testing role changes to a role that is oriented towards support and coaching. The team therefore has what’s known as a quality coach, who brings professional testing and QA expertise into the team. Of course, this person can provide active support with the testing, but this is no longer the main focus.\nAnother important aspect of whole-team testing is the agreement on common principles. These can be derived from the Testing Manifesto, for example, or be individually defined. Shared team understanding and commitment to the principles are decisive for success.\nIrrespective of the chosen approach, the tools that are used or the degree of automation: success comes with modifying the mindset of each team member and actively adapting personal ways of working. A mini waterfall in an Agile sprint is worse than any cumbersome project in accordance with the V-model. This generates excessive stress, frustration and, in the worst case, leads to burnout, reduced product quality and higher costs (for bug fixing, etc.). A lose-lose situation is inevitable.\nWhat does the future look like?\nIn future, companies must supply the right products or features at the right time and in high quality. In other words, they must identify the ideas with the highest economic value for their customers from all of the good ideas, and supply them with the correct quality, as fast and as cost-effectively as possible. This means that companies must professionalise their digital product development and standardise it to a certain degree. The future therefore lies in the industrialisation of digital product development, and the set-up of an organic digital factory within the company.\nEveryone in a value stream works together on a product in the digital factory. This one team takes over the complete end-to-end (E2E) responsibility for the product when doing this, and therefore has full responsibility for the vision, mission, backlog, budget, quality and operation. An organic digital factory such as this is not static. The product’s development platform, i.e. the conveyor belt, is developed and operated by a central engineering team. This team coaches and supports the product teams so that they can take over the responsibility for the conveyor belt themselves, and no dependency arises.\nThe processes, tools and methods in a digital factory are standardised. All processes are automated wherever possible, and built-in quality is the norm. This standardises digital product development. Quality, time-to-market and customer satisfaction are increased over the long term. However, with all of this standardisation, we shouldn’t forget the human factor. Like any other concept, the digital factory will not be very successful without people and organisations that are open and motivated to develop the best product together as one team.\nIrrespective of the degree of automation and standardisation: companies must establish a supporting and appreciative collaboration culture, and actively cultivate it beyond all of the hierarchical levels. Employees must feel personally appreciated and accepted; this is the only way to achieve top performance and sustainable product development.\nWhat do you think about our concept of the digital factory? We look forward to receiving your feedback and questions about this article.\nOriginal Post: Zühlke: Back to the future of software development\n","date":"3 January 2023","externalUrl":null,"permalink":"/en/blogs/back-to-the-future-of-software-development/","section":"Blogs","summary":"By Pia Wiedermayer and Romano Roth\nIn many organizations and projects, software development involves numerous employees and machines performing tasks separately. This approach results in problems. Here’s how going back to the original way of developing software and building an organic digital factory can help.\n","title":"Back to the future of software development","type":"blogs"},{"content":"","date":"3 January 2023","externalUrl":null,"permalink":"/en/tags/interdisciplinary-teams/","section":"Tags","summary":"","title":"Interdisciplinary Teams","type":"tags"},{"content":"","date":"3 January 2023","externalUrl":null,"permalink":"/en/tags/team-topology/","section":"Tags","summary":"","title":"Team Topology","type":"tags"},{"content":"Von Pia Wiedermayer und Romano Roth\nIn vielen Organisationen und Projekten sind an der Softwareentwicklung zahlreiche Mitarbeitende und Maschinen beteiligt, die ihre Aufgaben getrennt voneinander erledigen. Dieser Ansatz führt zu Problemen. So kann die Rückkehr zur ursprünglichen Art der Softwareentwicklung und der Aufbau einer organischen digitalen Fabrik helfen.\nIn der heutigen Softwareentwicklung werden Unmengen an Ressourcen verbraucht und manuelle Schritte ausgeführt. Die Prozessphasen laufen nacheinander ab, völlig getrennt voneinander. Nach Abschluss einer Phase (sei sie erfolgreich oder nicht) werden die Arbeitsergebnisse über die sogenannte «Wall of Confusion» geworfen. Ganz nach dem Motto «nach mir die Sintflut». Dieses Vorgehen führt zu folgenden Hauptproblemen, die in den unterschiedlichsten Organisationen in gleicher Weise anzutreffen sind:\nViele manuelle Schritte, die den Gesamtprozess langsam und fehleranfällig machen. Qualitätssicherung und Testing als separate Phasen am Ende des Gesamtprozesses. Sicherheitsanforderungen und andere nicht-funktionale Anforderungen, wie Last und Performance oder Wartbarkeit, werden erst kurz vor der finalen Auslieferung diskutiert und überprüft. Mangelnde Zusammenarbeit aufgrund getrennter Arbeitsbereiche und Phasen. Erschwerend kommt hinzu, dass es Transformationsprojekte gibt, die nicht die Organisation als Ganzes betrachten, sondern lediglich neue Bezeichnungen auf bestehende Strukturen übertragen. Wir treffen häufig auf Abteilungen, die nun Dev-[hier könnte Ihre Abteilung stehen]-Ops heissen, aber genau gleich wie immer hinter der neuen agilen Fassade arbeiten und funktionieren. Der einzige Unterschied ist, dass alles schneller und agiler erfolgen muss. Das setzt die Mitarbeitenden und die gesamte Organisation enorm unter Druck. Es besteht die ernsthafte Gefahr, wertvolle Ressourcen zu verschwenden und Mitarbeitende zu überfordern. In Zeiten, in denen Nachhaltigkeit und der «War for Talent» immer wichtiger werden, können es sich Organisationen nicht mehr leisten, ihre besten Köpfe zu verlieren und die Umwelt unbedacht zu schädigen.\nWir sehen grosses Potenzial in der Rückkehr zur ursprünglichen Art der Softwareentwicklung, die selbstverständlich interdisziplinäre Teams und enge Zusammenarbeit beinhaltet. Angereichert mit modernen Ansätzen wie DevOps, integrativer Qualitätssicherung und agilen Arbeitsweisen kann die klassische Softwareentwicklung die oben genannten Probleme effizient und nachhaltig lösen. Doch was bedeuten diese Begriffe genau?\nDevOps # DevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken. Es sorgt für Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Personen, die für die Planung, Entwicklung, Prüfung, Bereitstellung, Freigabe und Wartung eines Produkts erforderlich sind.\nSowohl ein Kulturwandel als auch ein Wandel des Mindsets sind dabei von zentraler Bedeutung. Es geht nicht mehr um «die anderen», sondern um «uns». DevOps basiert auf Teamwork. Gegenseitiges Vertrauen, Empowerment, Verantwortung, kontinuierliche Verbesserung, datenbasierte Entscheidungsfindung und Kundenempathie sind zentrale DevOps-Werte.\nDas Ziel von DevOps ist es, die Markteinführung zu beschleunigen, Experimentieren zu ermöglichen, Software in kürzeren Abständen zu releasen, die Durchlaufzeit für Bugfixes zu reduzieren und die durchschnittliche Wiederherstellungszeit zu verbessern. Dabei geht es nicht nur um die Zusammenarbeit zwischen Dev (Entwicklung) und Ops (Betrieb), sondern um die Zusammenarbeit zwischen allen Personen, die an der Erstellung des Produkts beteiligt sind.\nWie in der Abbildung dargestellt, sind dies Entwicklung, Sicherheit, Business, Architektur, Compliance, Qualitätssicherung und Betrieb. Wir sind uns jedoch sicher, dass wir einige Personengruppen vergessen haben.\nSie haben wahrscheinlich schon von folgenden neuen Begriffen gehört:\nDevSecOps: Dev = Entwicklung, Sec = Sicherheit, Ops = Betrieb BizDevOps: Biz = Business, Dev = Entwicklung, Ops = Betrieb Diese neuen Begriffe sind ein Versuch, den Begriff DevOps mit weiteren Personengruppen zu vervollständigen. Leider sind auch diese neuen Begriffe unvollständig. Denn ein Begriff wie DevSecBizArchCompQAOps oder Dev*Ops oder DevXOps wäre nötig, um dem gerecht zu werden, was wir mit DevOps erreichen wollen. Aus diesem Grund bleiben wir einfach bei DevOps, auch wenn es nicht der idealste Begriff ist. Bei DevOps geht es darum, alle Personen, Prozesse und Technologien zum Zweck der kontinuierlichen Wertschöpfung zusammenzubringen.\nQualitätssicherung # Qualitätssicherung wird oft als Synonym für Testing verwendet. Da dies nicht nur falsch ist, sondern auch erhebliche Verwirrung in den Arbeitsalltag bringt, erläutern wir im Folgenden die wesentlichen Merkmale und Unterschiede zwischen den beiden Begriffen.\nQualitätssicherung ist klar prozessorientiert, während sich Testing hauptsächlich auf das Produkt konzentriert. Testing ist ein Teil der Qualitätssicherung. Die Qualitätssicherung wiederum ist Teil eines grösseren Qualitätsmanagementsystems und es geht primär darum, Fehler zu vermeiden.\nDamit wird sichergestellt, dass die Prozesse zur Steuerung und Erstellung der Ergebnisse funktionsfähig sind. Bewährte (agile) Methoden wie Reviews oder Retrospektiven werden eingesetzt, um zu prüfen, ob dies der Fall ist. Bei der Qualitätssicherung geht es auch um technische Prozesse, die sicherstellen, dass Qualität effektiv und effizient erreicht wird (Built-in Quality). Hier besteht grosses Synergiepotenzial mit DevOps.\nTesting ist ein wesentlicher Teil der Qualitätssicherung. Der Hauptfokus liegt dabei auf der Detektion, also dem Finden von Bugs. Zum Testing gehören Aufgaben zur Planung und Steuerung, Analyse und Konzeption, Realisierung und Durchführung, Bewertung der Endekriterien und Berichterstattung sowie Aktivitäten zum Testabschluss. Zum Testing gehören auch fachliche und technische Reviews sowie Code-Inspektionen.\nTesting in der agilen Entwicklung erfordert einen hohen Automatisierungsgrad. Hier gilt jedoch: Qualität vor Quantität! Die Tatsache, dass Tests automatisiert werden können, sagt nichts darüber aus, ob sie sinnvoll sind. Jeder Test, ob manuell oder automatisiert, ist mit Aufwand verbunden. Der Fokus muss daher klar auf Tests liegen, die einen Mehrwert bieten.\nLeider hält sich der Mythos hartnäckig, dass Testautomatisierung manuelles Testing ersetzen muss. Unsere Erfahrung hat jedoch klar gezeigt, dass Testautomatisierung kein Ersatz für exploratives (manuelles) Testing oder Spezialistinnen und Spezialisten mit umfassender Expertise ist. Allerdings befindet sich diese Rolle klar im Wandel. Testautomatisierungstools und andere Entwicklungsverfahren helfen dem gesamten Team, schneller und effizienter zu arbeiten. So können sich die einzelnen Teammitglieder den Aufgaben widmen, für die das menschliche Gehirn benötigt wird.\nAgile und interdisziplinäre Zusammenarbeit # Agile Arbeitsmodelle verändern die Art unserer Zusammenarbeit. Ob dies positiv oder negativ ist, hängt stark von der Organisation, ihrer Kultur und ihren Menschen ab. Im Team ist Vielfalt gefragt, um agile Praktiken effizient zu erleben und umzusetzen. Eine ganze Fussballmannschaft, die nur aus Stürmern oder Verteidigern besteht, wäre nur mässig erfolgreich. Es ist die Kombination unterschiedlicher Spezialitäten, die den Unterschied macht und der Schlüssel zum Erfolg ist.\nIn Bezug auf die Produktentwicklung bedeutet dies: weg von den Silos, hin zu interdisziplinären Teams, die alle für das Produkt relevanten Disziplinen und Rollen unter einem gemeinsamen Teamdach vereinen. Jede Disziplin ist gleichwertig, jedes Teammitglied ist wichtig und jede Rolle schafft einen Mehrwert.\nSo einfach es klingt, in der Praxis kann die Umsetzung herausfordernd sein. Ein hervorragender Ausgangspunkt für interdisziplinäre Teams ist die Definition gemeinsamer Qualitätsprinzipien. Hier ist es entscheidend, dass die Prinzipien des gesamten Teams gemeinsam definiert, verstanden und von jedem Teammitglied aktiv gelebt und eingefordert werden. Diese gemeinsamen Qualitätsprinzipien dürfen nicht mit der «Definition of Done» oder «Definition of Ready» gleichgesetzt werden, die wir aus Scrum kennen. Bei den Prinzipien geht es vielmehr um die «Definitions» und sie bilden die gemeinsamen Werte des Teams.\nFolgende bewährte Ansätze können einen guten Einstieg bieten und im Alltag der interdisziplinären Zusammenarbeit unterstützen:\nDie 3 Amigos Whole-Team Testing Die 3 Amigos # Gute Anforderungen erfordern unterschiedliche Perspektiven. Business, Entwicklung und Testing/QA arbeiten daher während des gesamten Produktentwicklungszyklus eng zusammen. Alle drei Disziplinen müssen jederzeit eingebunden sein, von der Anforderungsanalyse über die kooperative Definition konkreter Anforderungen (z. B. User Stories) bis hin zur Entwicklung und finalen Abnahme. So entsteht ein gemeinsames Verständnis und die Wahrscheinlichkeit von Missverständnissen und Fehlern wird minimiert.\nAuf potenzielle Stolpersteine ist zu achten:\nBeschränkung der 3-Amigo-Diskussionen auf nur drei Personen. Wenn weitere Personen beteiligt sind, die für einen bestimmten Arbeitsschritt relevant sind, müssen sie in die Diskussion einbezogen werden. Ausweitung der 3-Amigo-Diskussion auf das gesamte Team. Das Ziel dieser Praktik ist es, jede benötigte Perspektive in einer möglichst kleinen Gruppe einzubeziehen. 3-Amigo-Diskussionen werden zu regelmässigen Meetings und werden als zusätzliche Teamzeremonie behandelt, anstatt eine praktische Roadmap für die Perspektiven zu sein, die in eine Diskussion über ein bestimmtes Arbeitsinkrement einbezogen werden sollten. Whole-Team Testing # Das Wesen des Whole-Team Testing ist die geteilte Teamverantwortung für Qualitätssicherung und Testing. Das bedeutet, dass Testing nicht mehr ausschliesslich die Aufgabe und der Fokus professioneller Tester ist, sondern jeder einzelnen Person im Team. Die Testing-Rolle wandelt sich zu einer Rolle, die auf Unterstützung und Coaching ausgerichtet ist. Das Team verfügt also über einen sogenannten Quality Coach, der professionelle Test- und QA-Expertise ins Team bringt. Diese Person kann natürlich aktiv beim Testing unterstützen, dies steht jedoch nicht mehr im Mittelpunkt.\nEin weiterer wichtiger Aspekt des Whole-Team Testing ist die Vereinbarung gemeinsamer Prinzipien. Diese können beispielsweise aus dem Testing Manifesto abgeleitet oder individuell definiert werden. Gemeinsames Teamverständnis und Commitment zu den Prinzipien sind entscheidend für den Erfolg.\nUnabhängig vom gewählten Ansatz, den eingesetzten Tools oder dem Automatisierungsgrad: Erfolg stellt sich ein, wenn das Mindset jedes Teammitglieds verändert und persönliche Arbeitsweisen aktiv angepasst werden. Ein Mini-Wasserfall in einem agilen Sprint ist schlimmer als jedes umständliche Projekt nach dem V-Modell. Dies erzeugt übermässigen Stress, Frustration und führt im schlimmsten Fall zu Burnout, reduzierter Produktqualität und höheren Kosten (für Bugfixes etc.). Eine Lose-Lose-Situation ist unausweichlich.\nWie sieht die Zukunft aus?\nIn Zukunft müssen Unternehmen die richtigen Produkte oder Features zur richtigen Zeit und in hoher Qualität liefern. Mit anderen Worten: Sie müssen aus all den guten Ideen jene mit dem höchsten wirtschaftlichen Wert für ihre Kunden identifizieren und sie mit der richtigen Qualität so schnell und kostengünstig wie möglich liefern. Das bedeutet, dass Unternehmen ihre digitale Produktentwicklung professionalisieren und in einem gewissen Mass standardisieren müssen. Die Zukunft liegt daher in der Industrialisierung der digitalen Produktentwicklung und im Aufbau einer organischen digitalen Fabrik im Unternehmen.\nIn der digitalen Fabrik arbeiten alle in einem Value Stream gemeinsam an einem Produkt. Dieses eine Team übernimmt dabei die vollständige End-to-End-Verantwortung (E2E) für das Produkt und trägt somit die volle Verantwortung für Vision, Mission, Backlog, Budget, Qualität und Betrieb. Eine solche organische digitale Fabrik ist nicht statisch. Die Entwicklungsplattform des Produkts, also das Förderband, wird von einem zentralen Engineering-Team entwickelt und betrieben. Dieses Team coacht und unterstützt die Produktteams, damit sie die Verantwortung für das Förderband selbst übernehmen können und keine Abhängigkeit entsteht.\nDie Prozesse, Tools und Methoden in einer digitalen Fabrik sind standardisiert. Alle Prozesse sind, wo immer möglich, automatisiert und Built-in Quality ist die Norm. Dies standardisiert die digitale Produktentwicklung. Qualität, Time-to-Market und Kundenzufriedenheit werden langfristig gesteigert. Bei all dieser Standardisierung sollten wir jedoch den menschlichen Faktor nicht vergessen. Wie jedes andere Konzept wird auch die digitale Fabrik ohne Menschen und Organisationen, die offen und motiviert sind, gemeinsam als ein Team das beste Produkt zu entwickeln, nicht sehr erfolgreich sein.\nUnabhängig vom Grad der Automatisierung und Standardisierung: Unternehmen müssen eine unterstützende und wertschätzende Kollaborationskultur etablieren und sie aktiv über alle Hierarchieebenen hinweg pflegen. Mitarbeitende müssen sich persönlich wertgeschätzt und akzeptiert fühlen; nur so lassen sich Spitzenleistungen und nachhaltige Produktentwicklung erreichen.\nWas halten Sie von unserem Konzept der digitalen Fabrik? Wir freuen uns auf Ihr Feedback und Ihre Fragen zu diesem Artikel.\nOriginalbeitrag: Zühlke: Back to the future of software development\n","date":"3. January 2023","externalUrl":null,"permalink":"/de/blogs/zurueck-in-die-zukunft-der-softwareentwicklung/","section":"Blogs","summary":"Von Pia Wiedermayer und Romano Roth\nIn vielen Organisationen und Projekten sind an der Softwareentwicklung zahlreiche Mitarbeitende und Maschinen beteiligt, die ihre Aufgaben getrennt voneinander erledigen. Dieser Ansatz führt zu Problemen. So kann die Rückkehr zur ursprünglichen Art der Softwareentwicklung und der Aufbau einer organischen digitalen Fabrik helfen.\n","title":"Zurück in die Zukunft der Softwareentwicklung","type":"blogs"},{"content":"After we finished the GitLab DevSecOps series, Patrick changed jobs — and his new team is on GitHub. The problem is the same: no security checks during development. The platform is different. In Part 1 of our GitHub DevSecOps series, we cover what GitHub is, the CI/CD vocabulary you have to share before any pipeline conversation works, and the shape of the DevSecOps pipeline we will build over the next sessions.\nWhat GitHub Is # GitHub is a distributed development platform where you host source code and build your development pipelines. It was acquired by Microsoft in 2018 and is one of the largest developer platforms in the world, with roughly 83 million developers and 28 million repositories. We will compare GitLab and GitHub directly at the end of this series. For now, we focus only on GitHub.\nWhat a DevSecOps Pipeline Has to Do # Products evolve continuously. The DevSecOps cycle — plan, code, build, test, deploy, release, operate, monitor — is what your platform has to support end to end. Before talking about specific tools, you have to be precise about three terms that get mixed up constantly: continuous integration, continuous delivery, and continuous deployment.\nContinuous Integration # The developer commits code. The CI server picks it up, builds it, runs static code analysis, runs static security analysis, and executes the unit tests and some integration tests. The output is a deployable artifact. Security testing is part of CI from the start — not a separate gate at the end.\nFeedback time matters more than people realize. If the loop takes hours, the developer has already moved on by the time the result arrives. The cost of context switching wipes out the value of catching the issue early. We are talking minutes, not hours.\nContinuous Delivery # The deployable artifact is automatically deployed to a staging environment that mirrors production. There you run additional automated tests and, if you want them, manual ones. The deployment is automated; the release is a separate decision.\nContinuous Deployment # Continuous deployment goes one step further. After staging, the artifact is automatically deployed to production. A second set of automated tests runs there. If they fail, you immediately roll back to the last stable version. There is no manual gate.\nIn many organizations, that last step is intentionally not automated — security or compliance procedures require a formal manual trigger. That is fine, but it means you are doing continuous delivery, not continuous deployment. Be honest about which one you run.\nThe Continuous Delivery Pipeline # CI/CD on its own is not enough. A real pipeline includes continuous exploration (ideation and backlog management) at the front and release on demand (enabling features in production via toggles) at the back. The full thing is called the continuous delivery pipeline. In any mature pipeline you will see many tools wired together; the work is not picking the tools, it is integrating them so they actually run on every commit.\nWhat GitHub Promises and What You Actually Get # GitHub promises a single platform that covers everything. Reality is more nuanced: GitHub gives you very nice integration points, but you will replace some inadequate parts and pull in third-party tools for several steps. There is no GitHub-provided default for every security task — for SCA, SAST, container scanning, and others, you pick from the Marketplace.\nWhy We Do This # Fixing a security issue early is dramatically cheaper than fixing it after release. If a penetration test finds a problem after the product is in production, you may have to take it offline, lose revenue, and rerun the entire chain — code, build, test, deploy. Compare that to catching the issue while the developer is still working on the same piece of code, when context is fresh and the fix takes minutes. The economics make the case on their own.\nThe Pipeline We Will Build with GitHub # The next sessions will cover, in order: setting up the project with build and unit testing, software composition analysis, license compliance, static application security testing, container scanning, secret detection, merge requests as a security gate, dynamic application security testing, and scheduled pipelines. The final session will give recommendations and lessons learned from the whole journey.\nKey Takeaways # GitHub is a starting point, not a complete DevSecOps platform. You get strong integration points and a marketplace; you do not get a default tool for every security task. Plan for third-party pieces.\nUse CI, CD, and continuous deployment with precision. Continuous integration ends with a tested artifact. Continuous delivery deploys to staging. Continuous deployment deploys to production. The trade-offs are different — call them by their right names.\nFeedback in minutes is the design constraint. If the pipeline takes hours, the developer has already moved on and the early-detection benefit is lost. Optimize relentlessly for fast feedback.\nA manual production gate is fine — just call it continuous delivery. Many companies cannot fully automate the production step due to compliance. That is a legitimate choice, not a failure of DevOps.\nCatching security issues early is dramatically cheaper. A vulnerability found in production can mean taking the system offline. The same vulnerability found at commit time costs minutes of developer attention.\nThe work is integration, not tool selection. The Marketplace has plenty of tools. Wiring them into a pipeline that runs on every commit, with reliable feedback to the developer, is the real engineering effort.\n","date":"3 January 2023","externalUrl":null,"permalink":"/en/blogs/github-devsecops-introduction/","section":"Blogs","summary":"After we finished the GitLab DevSecOps series, Patrick changed jobs — and his new team is on GitHub. The problem is the same: no security checks during development. The platform is different. In Part 1 of our GitHub DevSecOps series, we cover what GitHub is, the CI/CD vocabulary you have to share before any pipeline conversation works, and the shape of the DevSecOps pipeline we will build over the next sessions.\n","title":"GitHub DevSecOps Part 1: What Is GitHub and Why Shift Security Left?","type":"blogs"},{"content":"Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.\nWas GitHub ist # GitHub ist eine verteilte Entwicklungsplattform, auf der du Source Code hostest und deine Entwicklungspipelines baust. GitHub wurde 2018 von Microsoft übernommen und ist eine der grössten Entwicklerplattformen weltweit, mit rund 83 Millionen Entwicklern und 28 Millionen Repositories. Am Ende dieser Serie vergleichen wir GitLab und GitHub direkt. Vorerst konzentrieren wir uns auf GitHub.\nWas eine DevSecOps-Pipeline leisten muss # Produkte entwickeln sich kontinuierlich weiter. Der DevSecOps-Zyklus — plan, code, build, test, deploy, release, operate, monitor — ist das, was deine Plattform durchgängig unterstützen muss. Bevor wir über konkrete Tools sprechen, müssen wir drei Begriffe sauber trennen, die ständig vermischt werden: Continuous Integration, Continuous Delivery und Continuous Deployment.\nContinuous Integration # Der Entwickler committet Code. Der CI-Server holt ihn, baut ihn, führt statische Code-Analyse durch, statische Security-Analyse, Unit Tests und einen Teil der Integrationstests. Output ist ein deploybares Artefakt. Security-Tests sind von Anfang an Teil der CI — kein separates Gate am Ende.\nFeedback-Zeit zählt mehr, als viele denken. Dauert der Loop Stunden, hat der Entwickler längst etwas Neues angefangen, wenn das Ergebnis kommt. Der Aufwand für den Context Switch frisst den Vorteil des frühen Findens komplett auf. Wir reden über Minuten, nicht über Stunden.\nContinuous Delivery # Das deploybare Artefakt wird automatisch in eine Staging-Umgebung deployed, die der Produktion entspricht. Dort laufen weitere automatisierte Tests, bei Bedarf auch manuelle. Das Deployment ist automatisiert; der Release ist eine separate Entscheidung.\nContinuous Deployment # Continuous Deployment geht einen Schritt weiter. Nach Staging wird das Artefakt automatisch in Produktion deployed. Dort läuft ein zweites Set automatisierter Tests. Falls die scheitern, wird sofort auf die letzte stabile Version zurückgerollt. Es gibt kein manuelles Gate.\nIn vielen Organisationen ist dieser letzte Schritt absichtlich nicht automatisiert — Security- oder Compliance-Vorgaben verlangen einen formellen manuellen Trigger. Das ist in Ordnung, aber es heisst, dass du Continuous Delivery machst, nicht Continuous Deployment. Sei ehrlich, was du tatsächlich tust.\nDie Continuous Delivery Pipeline # CI/CD allein reicht nicht. Eine vollständige Pipeline enthält am Anfang Continuous Exploration (Ideenfindung und Backlog-Management) und am Ende Release on Demand (Aktivieren von Features in Produktion über Toggles). Das Ganze nennt sich Continuous Delivery Pipeline. In jeder reifen Pipeline siehst du viele Tools, die zusammengeschaltet sind; die Arbeit liegt nicht in der Tool-Wahl, sondern in der Integration, sodass die Tools bei jedem Commit zuverlässig laufen.\nWas GitHub verspricht und was du tatsächlich bekommst # GitHub verspricht eine einzige Plattform, die alles abdeckt. Die Realität ist nuancierter: GitHub gibt dir sehr gute Integrationspunkte, aber du wirst einige unzureichende Teile ersetzen und für mehrere Schritte Drittanbieter-Tools einbinden. Es gibt nicht für jede Security-Aufgabe ein GitHub-eigenes Default-Tool — für SCA, SAST, Container Scanning und andere wählst du aus dem Marketplace.\nWarum wir das tun # Ein Security-Problem früh zu beheben ist dramatisch günstiger als die Behebung nach dem Release. Findet ein Penetration Test ein Problem nach dem Go-live, musst du das Produkt möglicherweise vom Netz nehmen, Umsatz verlieren und die gesamte Kette — code, build, test, deploy — erneut durchlaufen. Vergleiche das mit einem Fund, während der Entwickler noch am selben Codestück arbeitet, der Kontext frisch ist und der Fix Minuten dauert. Die Wirtschaftlichkeit spricht für sich.\nDie Pipeline, die wir mit GitHub bauen werden # Die nächsten Sessions decken in dieser Reihenfolge ab: Setup des Projekts mit Build und Unit Tests, Software Composition Analysis, License Compliance, Static Application Security Testing, Container Scanning, Secret Detection, Merge Requests als Security-Gate, Dynamic Application Security Testing und Scheduled Pipelines. Die letzte Session liefert Empfehlungen und Lessons Learned aus der gesamten Reise.\nKey Takeaways # GitHub ist ein Startpunkt, keine vollständige DevSecOps-Plattform. Du bekommst starke Integrationspunkte und einen Marketplace; du bekommst kein Default-Tool für jede Security-Aufgabe. Plane Drittanbieter-Bausteine ein.\nVerwende CI, CD und Continuous Deployment präzise. Continuous Integration endet mit einem getesteten Artefakt. Continuous Delivery deployed nach Staging. Continuous Deployment deployed nach Produktion. Die Trade-offs sind unterschiedlich — nenn sie beim richtigen Namen.\nFeedback in Minuten ist die Design-Vorgabe. Dauert die Pipeline Stunden, ist der Entwickler längst woanders, und der Vorteil des frühen Findens ist verloren. Optimiere kompromisslos auf schnelles Feedback.\nEin manuelles Produktions-Gate ist okay — nenn es einfach Continuous Delivery. Viele Unternehmen können den Produktions-Schritt aus Compliance-Gründen nicht voll automatisieren. Das ist eine legitime Wahl, kein DevOps-Versagen.\nSecurity früh zu finden ist dramatisch günstiger. Eine Schwachstelle, die in Produktion entdeckt wird, kann bedeuten, dass du das System abschalten musst. Dieselbe Schwachstelle zur Commit-Zeit kostet Minuten Entwickler-Aufmerksamkeit.\nDie Arbeit ist Integration, nicht Tool-Wahl. Der Marketplace bietet reichlich Tools. Sie so in eine Pipeline zu verdrahten, dass sie bei jedem Commit laufen und zuverlässiges Feedback liefern, ist die eigentliche Engineering-Leistung.\n","date":"3. January 2023","externalUrl":null,"permalink":"/de/blogs/github-devsecops-einfuehrung/","section":"Blogs","summary":"Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.\n","title":"GitHub DevSecOps Teil 1: Was ist GitHub und warum Security nach links verschieben?","type":"blogs"},{"content":"","date":"1. January 2023","externalUrl":null,"permalink":"/de/tags/aufkommende-technologien/","section":"Tags","summary":"","title":"Aufkommende Technologien","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/cloud-native/","section":"Tags","summary":"","title":"Cloud Native","type":"tags"},{"content":"","date":"1. January 2023","externalUrl":null,"permalink":"/de/tags/containerisierung/","section":"Tags","summary":"","title":"Containerisierung","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/containerization/","section":"Tags","summary":"","title":"Containerization","type":"tags"},{"content":" DevOps trends 2023\nWe quickly review my projections for 2021 and 2022 before moving on to the difficulties businesses are already facing. Due to silo organizations, there is almost no coordination between the various organizational divisions, and businesses continue to plan annual projects rather than products. Hence, businesses must adopt some DevOps methods or trends. DevOps is a mindset, culture with technical practices that align all people across the value stream to continuously deliver value to the customer. The top DevOps trends for 2023 include building products, running the product, ensuring product quality, monitoring the product, organizing across the value stream, enabling DevOps in product teams, and industrializing the whole product development.\n​DevOps Trends 2022\nWe discuss the top DevOps trends for 2022 using the technology adaption lifecycle. The late majority will continue DevOps adoption and focus on continuous integration, monitoring, logging, infrastructure as code, containerization, orchestration, and cloud. In the early majority, DevSecOps is a huge topic due to the increased number of cyber-attacks. Observability, GitOps, enterprise continuous delivery pipelines, FinOps, and continuous testing are also hot topics. Early adapters are investing in AIOps.\n​DevOps Trends 2021\nWe discuss the top DevOps trends for 2021. These include a strong adoption of DevOps and agile transformation, a shift towards DevSecOps for security, a focus on continuous delivery pipelines and cloud computing, and the emergence of AIOps as a young but promising area for automation using AI and machine learning.\n","date":"1 January 2023","externalUrl":null,"permalink":"/en/blogs/what-are-the-top-devops-trends-in-2021/","section":"Blogs","summary":" DevOps trends 2023\nWe quickly review my projections for 2021 and 2022 before moving on to the difficulties businesses are already facing. Due to silo organizations, there is almost no coordination between the various organizational divisions, and businesses continue to plan annual projects rather than products. Hence, businesses must adopt some DevOps methods or trends. DevOps is a mindset, culture with technical practices that align all people across the value stream to continuously deliver value to the customer. The top DevOps trends for 2023 include building products, running the product, ensuring product quality, monitoring the product, organizing across the value stream, enabling DevOps in product teams, and industrializing the whole product development.\n","title":"DevOps Top Trends and Emerging Technologies to Watch","type":"blogs"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/emerging-tech/","section":"Tags","summary":"","title":"Emerging Tech","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/future-of-devops/","section":"Tags","summary":"","title":"Future of DevOps","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/infrastructure/","section":"Tags","summary":"","title":"Infrastructure","type":"tags"},{"content":"","date":"1. January 2023","externalUrl":null,"permalink":"/de/tags/infrastruktur/","section":"Tags","summary":"","title":"Infrastruktur","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/trend-analysis/","section":"Tags","summary":"","title":"Trend Analysis","type":"tags"},{"content":"","date":"1. January 2023","externalUrl":null,"permalink":"/de/tags/trendanalyse/","section":"Tags","summary":"","title":"Trendanalyse","type":"tags"},{"content":"","date":"1. January 2023","externalUrl":null,"permalink":"/de/tags/zukunft-von-devops/","section":"Tags","summary":"","title":"Zukunft Von DevOps","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/2023/","section":"Tags","summary":"","title":"2023","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/devops-trends/","section":"Tags","summary":"","title":"DevOps Trends","type":"tags"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/en/tags/internal-developer-platform/","section":"Tags","summary":"","title":"Internal Developer Platform","type":"tags"},{"content":"Two years of trend predictions later, the DevOps conversation has shifted. In 2021 we talked about adoption. In 2022 we mapped trends onto the adoption lifecycle. In 2023 the most useful lens is the value stream: how products get built, run, quality-assured, monitored, organised, enabled and industrialised end-to-end. Most organisations still suffer from silos and project-based annual planning. The 2023 trends are about closing those gaps.\nFrom Projects to Products, From Silos to Streams # Before getting to the trends, the framing matters. DevOps is a mindset and a culture with technical practices that align everyone across the value stream to continuously deliver value to the customer. As long as your organisation plans annual projects and runs siloed business units, no tool will save you. The 2023 trends only pay off in organisations that take the value stream seriously.\nBuilding the Product # On the build side, expect more emphasis on cloud-native architectures, containerization, infrastructure as code and trunk-based development. The new entrants are AI-assisted development — code generation, code review, test generation — and a sharper focus on developer experience as a measurable outcome.\nRunning the Product # Running the product is where platform engineering takes centre stage in 2023. Internal developer platforms (IDPs) wrap the cloud, Kubernetes, CI/CD, security and observability into a paved road that product teams can self-serve. Site reliability engineering (SRE) practices — SLOs, error budgets, blameless postmortems — go mainstream. GitOps continues its march as the default operating model for Kubernetes-based systems.\nEnsuring Product Quality # Quality is no longer a phase; it is a property of the pipeline. Continuous testing, contract testing, chaos engineering and security testing all run as automated gates. DevSecOps tightens further: SBOMs (Software Bill of Materials), supply chain security, signed artifacts and policy as code. Expect regulators in finance, healthcare and the public sector to push hard on these topics in 2023.\nMonitoring the Product # Observability matures from a tooling conversation to a practice. Metrics, logs and traces feed into AIOps for anomaly detection and alert correlation. The leading teams move beyond reactive monitoring to predictive operations, using ML on production telemetry. The hard part is not the tooling; it is getting the data quality good enough to act on.\nOrganising Across the Value Stream # Team Topologies has become the default vocabulary: stream-aligned teams, platform teams, enabling teams and complicated-subsystem teams. Value Stream Management (VSM) tools give leadership end-to-end visibility from idea to customer outcome. The 2023 trend is leadership stopping the pretence that a single org chart can deliver products and instead designing the team interactions explicitly.\nEnabling DevOps in Product Teams # Enabling teams help stream-aligned teams adopt new practices and technologies. In 2023 this means coaching on platform usage, on DevSecOps, on observability and on AI-assisted development. The shift is from training-as-a-class to enabling-as-a-relationship — small, embedded engagements that leave the team with new capability rather than slides.\nIndustrialising the Whole Product Development # The endgame is industrialisation: standardised, repeatable, measurable end-to-end product delivery. Golden paths, paved roads, platform-as-a-product, FinOps to keep the cloud bill honest, and DORA metrics or SPACE to measure performance. Organisations that get there in 2023 will have a structural advantage over those still firefighting individual pipelines.\nKey Takeaways # Value stream is the right lens for 2023. Silos and project planning are the actual blocker. Tools alone will not fix that.\nPlatform engineering goes mainstream. Internal developer platforms wrap the messy underneath into a paved road that teams self-serve.\nSupply chain security is non-negotiable. SBOMs, signed artifacts, policy as code. Regulators and customers will demand it.\nTeam Topologies is the new vocabulary. Stream-aligned, platform, enabling and complicated-subsystem teams — design the interactions explicitly.\nObservability becomes a practice, not a tool. AIOps and predictive operations only work if the data is good.\nIndustrialise the value stream. Golden paths, FinOps, DORA / SPACE. Standardised, measurable, end-to-end delivery is the durable advantage.\n","date":"1 January 2023","externalUrl":null,"permalink":"/en/blogs/top-devops-trends-2023/","section":"Blogs","summary":"Two years of trend predictions later, the DevOps conversation has shifted. In 2021 we talked about adoption. In 2022 we mapped trends onto the adoption lifecycle. In 2023 the most useful lens is the value stream: how products get built, run, quality-assured, monitored, organised, enabled and industrialised end-to-end. Most organisations still suffer from silos and project-based annual planning. The 2023 trends are about closing those gaps.\n","title":"The Future of DevOps: Top Trends to Watch in 2023","type":"blogs"},{"content":"","date":"28 December 2022","externalUrl":null,"permalink":"/en/tags/code-security/","section":"Tags","summary":"","title":"Code Security","type":"tags"},{"content":"","date":"28 December 2022","externalUrl":null,"permalink":"/en/tags/gitlab/","section":"Tags","summary":"","title":"GitLab","type":"tags"},{"content":"by Romano Roth and Patrick Steger\nThis video series will show you how to build up an enterprise-ready DevSecOps Pipeline with GitLab and GitHub and compare the two platforms.\nIntroduction # GitLab GitHub Topic GitLab GitHub Security Tools Provides integration points to include security tools. Offers GitLab maintained integrations for GitLab recommended default security tools. Provides integration points to include security tools. There are no default GitHub recommended/maintained security tools. There are security tools provided by the community for open source and commercial tools. Creating a simple project # GitLab GitHub Aspect GitLab GitHub Repository Creation Can create new empty repository. Offers to start with GitLab provided default project/repo-structure (e.g. C#, SpringBoot, PHP, etc). They are easy to find. Can create new empty repository. Can create a new repository based on a template project. Template projects are hard to find when there are none in your organization. Import Can import from other repositories like any Git repository (URL), GitHub, Jira, Bitbucket, etc. Can import from existing Repositories. Including GitLab. But does not work when using Social-Login. Pipeline Definition .gitlab-ci.yml is the entry point defining the whole pipeline. Option to include additional files (their content is included automatically at runtime). Pipelines are called Workflows. We can have a dedicated file for each workflow we want. Within the workflow file we define what triggers the workflow/pipeline. It is possible to \u0026ldquo;call\u0026rdquo; sub-workflows from a workflow file. Pipeline Structure Pipeline is broken down into stages and jobs, where stages are executed after each other and all jobs of a stage run in parallel (dependencies can be configured). This is a very neat approach but can become tricky to understand for complex pipelines. Pipelines/Workflows are cleanly separated in the UI and make it easy to find the right workflow/pipeline. Workflows use actions to implement jobs/steps. Such Actions are available over a Marketplace and not always easy to be found. Ease of Start Very easy to create a simple first pipeline because GitLab provides defaults for most everything that is required to start. Quite complex to get the first simple pipeline running because not much is automatically provided by GitHub. Pipeline Runs Pipeline runs are found in menu CI/CD -\u0026gt; pipelines. Pipeline/Workflow runs are found cleanly listed by Workflow in tab \u0026ldquo;Actions\u0026rdquo; in the UI. Artifacts Artifacts can simply be declared and are then available in the pipeline results view for download, this is GitLab provided and well documented. Standard artifacts like test-results can be made visible in the GitLab UI using default GitLab functionality. Artifacts are made available using an Action (for example using upload-artifact Action found in the Marketplace). Standard artifacts like test-results require other actions from the marketplace. UI quality varies. Multiple Pipelines Different pipelines must be configured with rules (e.g. based on what branch was committed). This may become complicated for complex scenarios. Different pipelines are simply configured in extra workflow files. This becomes natural after some time and supports complex scenarios. Visualization Nice graphical view to visualize stages and jobs as well as their dependencies (but not the conditions). Nice graphical view to visualize the workflow/pipeline run for executed runs. Software Composition Analysis (SCA) # GitLab GitHub Aspect GitLab GitHub Default Tool GitLab provided open source scanner available, documented and easily found. Simply add a GitLab provided template. No GitHub provided default tool. Find one in the Marketplace. We chose CRDA of RedHat based on Snyk (which proved to be not enterprise ready). Tool Quality The default tool has adequate quality and findings and is enterprise ready. Marketplace tools (Actions) are provided by third parties. Be aware of the risk and consider what providers you trust. Integration Findings are well integrated in GitLab UI (Pipeline view, Security\u0026amp;Compliance -\u0026gt; Vulnerability report). Vulnerabilities are also available as a download (json). GitHub has built-in functionality called Dependabot that can be enabled in settings and allows regular, scheduled scans of unchanged code. Format GitLab uses a GitLab specific format to integrate vulnerabilities in the GitLab UI. The GitHub format to display vulnerabilities is based on standards. This proves to be better for custom integration. Scheduled Scans No built-in scheduled re-scans, but can be defined explicitly. Dependabot can alert of new findings and offer pull requests for known fixes. But it is not executed on commit and cannot block merges. Special Feature Comparable simple editor of files in the project. Fully integrated development environment (similar to Visual Studio Code). This proved to be very powerful. License Compliance # GitLab GitHub Aspect GitLab GitHub Tool License compliance is provided as a managed GitLab tool (based on License-Finder open source project) that is easy and straightforward to add. Requires community provided (Marketplace) or custom Action to implement this. It\u0026rsquo;s meaningful to define an extra sub-workflow for this. Configuration All used licenses of the project are visible in a default GitLab UI. Can configure acceptable licenses as part of the platform (project settings). Can define what licenses are configurable, get error/failed pipeline when other licenses are found. Workflow Support of basic workflows to verify and accept new licenses (i.e. include a security team member as acceptor/reviewer). Failed licenses are reported as \u0026ldquo;customized Test Results\u0026rdquo;. Results are visible in the pipeline run only. Visibility Failed (not marked as acceptable) licenses are reported. There is no easy way to see \u0026ldquo;all licenses used by the project\u0026rdquo; (this is only in the log-output of the pipeline run). Static Application Security Testing (SAST) # GitLab GitHub Aspect GitLab GitHub Default Tool GitLab provided standard tool based on semgrep and other open source tools (e.g. spotbugs) available. Easy to integrate with a few lines of configuration. GitHub provides a standard tool for static analysis (CodeQL). We added in addition the open source tools semgrep and spotbugs. Quality GitLab added extra rules to the open source tools, so that it finds way more security issues than the plain open source semgrep tool. Overall findings look good enough. The combined results of all three tools still miss important findings. Custom work (i.e. defining custom rules) or extra licenses are required to improve. Marketplace N/A Finding appropriate SAST tools (Actions) in the Marketplace is not straight forward. Many tools require licenses. Integration Findings of the tools are integrated in the GitLab user interface (vulnerability view). Findings of the tools (they need to support sarif) are integrated in the GitHub user interface (security tab). Container Scanning # GitLab GitHub Aspect GitLab GitHub Tool Standard tool provided by GitLab (based on Trivy and Grype). Easy to add. No GitHub standard. We selected Trivy as container scanner, you have to find it in the Marketplace. Integration Result is Integrated in the GitLab UI in two places: In the pipeline run, in the Vulnerability Report. Results are integrated into the GitHub UI in Security -\u0026gt; Code Scanning (when they provide a sarif report). Findings Findings are reasonably good. Findings are reasonably good (with our selected tool). Duplicates with SCA may happen. Container Registry Creating a container image and making it available in the default container registry requires a bit more effort but is documented. Creating a container and making it available in the container registry is reasonably documented but not trivial. Pipeline Break Findings will not break the pipeline; they are just reported. We cannot configure GitLab to break a pipeline when vulnerabilities are found. Findings will not break the pipeline; they are just reported. Making the pipeline break will require some custom work. Secret Detection # GitLab GitHub Aspect GitLab GitHub Tool GitLab provides a standard tool based on GitLeaks. Integration is easy. GitHub has built-in functionality for secrets. Integration is easy. Capabilities Secrets found are limited; a good SCA tool is required as complement. GitLeaks focus is on security tokens (e.g. AWS access tokens), not regular keys or passwords. Finds secrets in the repository. Secrets found are limited. The focus is on security tokens, not regular keys or passwords. You can define and test your own secret patterns. Integration Findings are reported in the GitLab UI; both in the pipeline and the Vulnerability Report. At the time when we recorded the video \u0026ldquo;push protection\u0026rdquo; of secrets did not work. Secret Storage GitLab has no integrated secure way to store secrets. They support HashiCorp Vault, but the Vault must be hosted somewhere else and managed by you. GitHub has a well-protected secrets area where secrets can be stored securely. AND they also support Azure KeyVault out-of-the-box. A huge plus point. Dynamic Application Security Testing (DAST) # GitLab GitHub Aspect GitLab GitHub Tool Provides default tooling based on OWASP ZAP. No out-of-the-box solution. We chose OWASP ZAP based on the action zaproxy/action-full-scan. Capabilities Scan capabilities are very limited out-of-the-box, needs considerable configuration. Out-of-the-box findings are mostly irrelevant. Scan capabilities are limited out-of-the-box, but results better than in GitLab. Container Having to create a container first that can be started to run DAST against. Container can be started in GitLab internal runtime environment. Having to create a container first. Container can be started in GitHub using an Ubuntu image that has docker installed. Integration Results are nicely integrated in Pipeline run. Results can also be found in the vulnerability management report of the GitLab UI. Results are not integrated in the GitHub UI. Just a standalone report is made available. The reason is missing sarif support in OWASP ZAP. Vulnerability Management # GitLab GitHub Aspect GitLab GitHub Functionality GitLab offers functionality to manage vulnerabilities in the platform UI. You can add Vulnerabilities manually. GitHub offers limited functionality to manage vulnerabilities in the platform UI. Most critically missing: the capability to add custom vulnerabilities/findings. Dismissing Dismissing a finding is possible but without reasoning. We are missing most the capability to add a description why we dismissed a finding. Dismissing findings as false positive, won\u0026rsquo;t fix (accepted risk), test code only is possible with a comment. Issues You can create an issue from a vulnerability -\u0026gt; \u0026ldquo;Developer Task\u0026rdquo;. You can create an issue from a vulnerability/finding -\u0026gt; \u0026ldquo;Developer Task\u0026rdquo;. Resolving You can manually mark findings as resolved or accept the automatically detected resolving. Resolving is only automatically possible. No marking as fixed in the vulnerability management. Integration While it is possible to integrate findings of additional tools they are required in a non-standard format, so hard to get. You can integrate findings of additional tools when they deliver the report in sarif format. Limitations N/A You cannot dismiss for a limited time. You can\u0026rsquo;t change the severity of a finding. Merge Request / Pull Request # GitLab GitHub Aspect GitLab GitHub Branch Protection You can protect branches, so that merge requests are mandatory. You can enforce that pull requests are mandatory for a branch. Security Findings Lists security findings delta between the merged and the default branch. Deltas and findings are available for all the security tools integrated in GitLab. You can present some results of the security tools, quite a bit of customization is required to get acceptable quality. Presentation Deltas/Findings are nicely presented and can be navigated to. New findings are then available, to some degree, for the security tools (checks). Resolved findings are not visible. Findings are not aggregated between tools. Approvals You can have defined people eligible to approve if new vulnerabilities of a given criticality are found. You can have defined people eligible to approve the pull request, but this is not based on new findings/vulnerabilities. Other Info You can see also non-security stuff such as: code changes, review comments, test results, pipeline runs. You can see also non-security stuff such as: code changes, review comments, test results. Schedule Pipeline # GitLab GitHub Aspect GitLab GitHub Trigger Triggered by a dedicated scheduler found in GitLab. Triggered directly from within a workflow definition file. Branch Selection You can freely choose the branch on which it should run. Always executes on the default branch only, which is most likely not what you need. There are (complicated) workarounds to trigger execution on another branch. Configuration You need to enhance the pipeline definition file to understand when a scheduler triggered the run (to exclude unused jobs, adapt the pipeline run, etc). Create a dedicated workflow file for this. This new workflow only includes jobs required to do security checks on the production branch/code. Our Recommendation # GitLab GitHub GitLab GitHub Define default branch: This will be the branch that is used by GitLab to display security vulnerabilities in the built-in vulnerability management tool. Create top-level workflows (pipelines) orchestrating (simpler) workflows into complete DevSecOps pipelines. Define a scheduled pipeline: This is to make sure you scan your production code for new vulnerabilities. Define re-usable workflows on a per-job level. Use Merge Requests: To visualize the impact of changes on the security posture. Define on what branches to run pipelines. Consider using a Vault to store credentials: GitLab has no real solution built in. You should consider a third-party tool. Define a scheduled pipeline for the current production release branch. Consider using out-of-the-box GitLab tooling: This greatly simplifies matters and gives you a head start applying potentially \u0026ldquo;just-good-enough\u0026rdquo; tools relatively cheap. Use Pull Requests to find newly introduced security issues. Summary view is less ideal. DAST: Remember to customize the scanner configuration: Without customization results are weak. Use the capability to protect branches. At least the release branch should be protected. (Security-) review the tools you source from the marketplace. Use the GitHub-provided default GitHub secrets to store secrets or use the professional Azure Key Vault. Evaluate security tools and use a set that works good enough for you. Sadly, there is no out-of-the-box standard tooling. DAST: Remember to customize the scanner configuration. Until GitHub provides the capability to add vulnerabilities manually, you might have to use an extra tool to track vulnerabilities. Code # GitLab GitHub https://gitlab.com/romano_roth/gitlabdevsecopspipeline https://github.com/romanoroth/GitHubDevSecOps Summary # Our epic journey comes to an end. In the past month, we have created 24 videos, 12 on GitLab and 12 on GitHub, in which we have built up a DevSecOps pipeline. Now in this 25th video, we are going to compare GitLab vs. GitHub.\n📌 GitLab is faster to deliver results and has out-of-the-box tooling for everything but lacks proper secret management.\n➡️ GitLab is our recommendation when you want to get there fast and are ok to stick to the defaults.\n📌 GitHub offers more flexibility, supports great secret management and has a living community but comes with high supply chain risk, has no reasonable security tool defaults and is missing a critical vulnerability management feature (add external vulnerability).\n➡️ GitHub is our recommendation when you have complex applications/pipelines, or you must integrate with a few external (security) tools.\n💡 Whether you\u0026rsquo;re a developer, a project manager, or just someone interested in tech, our recommendations can help you make an informed decision about which platform is best for you.\n","date":"28 December 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-vs-github-devsecops/","section":"Blogs","summary":"by Romano Roth and Patrick Steger\nThis video series will show you how to build up an enterprise-ready DevSecOps Pipeline with GitLab and GitHub and compare the two platforms.\n","title":"GitLab vs. GitHub: DevSecOps Pipeline","type":"blogs"},{"content":"","date":"28 December 2022","externalUrl":null,"permalink":"/en/tags/security-tools/","section":"Tags","summary":"","title":"Security Tools","type":"tags"},{"content":"","date":"28 December 2022","externalUrl":null,"permalink":"/en/tags/source-control/","section":"Tags","summary":"","title":"Source Control","type":"tags"},{"content":"","date":"9 December 2022","externalUrl":null,"permalink":"/en/tags/clean-code/","section":"Tags","summary":"","title":"Clean Code","type":"tags"},{"content":"","date":"9 December 2022","externalUrl":null,"permalink":"/en/tags/code-quality/","section":"Tags","summary":"","title":"Code Quality","type":"tags"},{"content":"","date":"9. December 2022","externalUrl":null,"permalink":"/de/tags/code-qualit%C3%A4t/","section":"Tags","summary":"","title":"Code-Qualität","type":"tags"},{"content":"What defines high-quality work in software engineering? Is it Scrum? Clean Code? TDD? Functional programming? In this Expert Talks session, my colleague Milan and I present two complementary perspectives. Milan covers the pillars of high-quality engineering work, from team building and customer centricity to clean code and engineering culture. I then show how DevOps and continuous delivery help build great products by moving from a project mindset to a product mindset.\nThere Is No Silver Bullet # The session starts with a clear message: there is no single practice that guarantees high-quality engineering work. Not Scrum. Not Clean Code. Not TDD. Not functional programming. Instead, it is a combination of practices, culture, and mindset. And it all begins with the team. You need people with a can-do attitude, who are proactive, who want to learn and can receive feedback. Give them purpose and autonomy, and they will deliver great results.\nFive Pillars of High-Quality Engineering # Milan presents five pillars that form the foundation of quality engineering:\nCustomer centricity: The customer wants their problems solved. They do not care about our shiny architectures or clean code frameworks. We need to keep their needs in mind at all times.\nProper software design: Architecture is overrated, but simple design is very much underrated. Start with a document, employ design reviews and Architectural Decision Records. Be explicit about trade-offs. Design for change, with high separation of concerns and low coupling.\nGood code quality: Good code is like a joke: you do not need to explain it. Follow the Boy Scout Rule, coined by Uncle Bob Martin. Every time you open a file, make a small improvement. Rename a variable, refactor some logic, write a test that was missing.\nEngineering culture: Create a culture where people can ask for help when stuck, where there is time for education and training, where knowledge sharing sessions happen regularly, and where psychological safety allows for experimentation and failure.\nQuality first mindset: If you do not have tests, it does not work. Follow the test pyramid, aim for 60 to 90 percent code coverage, apply a zero bug policy, and automate everything you can.\n\u0026ldquo;Good code is like a joke. You don\u0026rsquo;t need to explain it. If the code is simple and understandable, you don\u0026rsquo;t need code comments.\u0026rdquo;\nFighting Technical Debt # Technical debt comes in many forms: bad code quality, lack of tests, highly coupled code, unused features, outdated libraries, bad tooling, manual processes, and lack of knowledge sharing. The impact is real: over time, the time available for new feature development shrinks while the time spent struggling with complexity and technical debt increases.\nHow to fight it? First, be transparent. Make technical debt visible to product and management. Second, management needs to empower the team to fix these problems. Ideally, create a culture where you do not need permission to refactor and improve things. Yes, it might slow you down 10 to 20 percent in the short term, but you will get it all back in the long run.\nThe Broken Window Theory # Why do we write bad code? The Broken Window Theory explains it well: if you see a building with broken windows, throwing another rock at it does not feel wrong. But if the building is pristine, you would not dare damage it. Small messes grow bigger over time. This is why the Boy Scout Rule matters: leave the codebase cleaner than you found it, every single time.\nFrom Projects to Products with DevOps # In the second part of the session, I explain a challenge I see in every company I work with. The business has great ideas. They write them into documents and Jira tickets and throw them over the \u0026ldquo;wall of confusion\u0026rdquo; to the development team. The development team implements something and throws it to the testing team. The testing team throws it to operations. The customer says: \u0026ldquo;What is that? That is not what we ordered.\u0026rdquo;\nThe root cause is siloed organizations and a project mindset. In a project, scope, budget, and time are fixed, and the focus is on maximizing output, the number of features delivered. But when building products, the focus must be on outcome: understanding the real customer need and solving the real problem.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices that provides close communication, integration, automation, and collaboration among all the people in the value stream.\u0026rdquo;\nBuilding the Continuous Delivery Pipeline # To move from projects to products, we need to identify the value stream. Value stream mapping brings all the people together to visualize every step from idea to production. It reveals bottlenecks by comparing lead time (total elapsed time) to process time (actual value-adding work). Often, the difference is shocking.\nThe continuous delivery pipeline is the conveyor belt of the digital factory. It automates the entire flow from code to production. This is essentially platform engineering: providing the platform on which teams build great products.\nBuilding in Quality and Operability # Quality must be built in from the beginning through continuous feedback. The traditional V-model with delayed feedback, where months pass between writing a feature and testing it, must be replaced with a shift-left approach. Behavior-Driven Development (BDD) creates clear acceptance criteria that can be turned directly into tests. Test-Driven Development (TDD) ensures tests exist from the start.\nEqually important is designing for operability. \u0026ldquo;You build it, you run it\u0026rdquo; is not just a slogan. It means thinking about monitoring, logging, alerting, and disaster recovery from the very beginning. Infrastructure as code, application telemetry, and automated incident response are all essential.\nKey Takeaways # There is no silver bullet. High-quality engineering requires a combination of great teams, customer focus, simple design, clean code, and strong engineering culture.\nTechnical debt is a real threat. Make it visible, empower teams to fix it, and follow the Boy Scout Rule: leave code cleaner than you found it.\nMove from projects to products. Focus on outcomes (solving real customer problems) instead of outputs (delivering a fixed number of features).\nIdentify and optimize the value stream. Value stream mapping reveals bottlenecks. The continuous delivery pipeline is the conveyor belt of your digital factory.\nBuild in quality from the start. Use BDD and TDD to shift testing left. Design for operability from day one.\nAutomate everything. From builds to tests to deployments to monitoring. Manual processes are the enemy of speed and quality.\n","date":"9 December 2022","externalUrl":null,"permalink":"/en/blogs/high-quality-work-in-software-engineering/","section":"Blogs","summary":"What defines high-quality work in software engineering? Is it Scrum? Clean Code? TDD? Functional programming? In this Expert Talks session, my colleague Milan and I present two complementary perspectives. Milan covers the pillars of high-quality engineering work, from team building and customer centricity to clean code and engineering culture. I then show how DevOps and continuous delivery help build great products by moving from a project mindset to a product mindset.\n","title":"High-Quality Work in Software Engineering and Building Great Developer Experience","type":"blogs"},{"content":"Was definiert hochwertige Arbeit in der Softwareentwicklung? Ist es Scrum? Clean Code? TDD? Funktionale Programmierung? In dieser Expert Talks Session präsentieren mein Kollege Milan und ich zwei komplementäre Perspektiven. Milan behandelt die Säulen hochwertiger Engineering-Arbeit, von Teambildung und Kundenzentrierung bis zu Clean Code und Engineering-Kultur. Ich zeige dann, wie DevOps und Continuous Delivery helfen, grossartige Produkte zu bauen, indem man vom Projekt-Mindset zum Produkt-Mindset wechselt.\nEs gibt kein Patentrezept # Die Session beginnt mit einer klaren Botschaft: Es gibt keine einzelne Praxis, die hochwertige Engineering-Arbeit garantiert. Nicht Scrum. Nicht Clean Code. Nicht TDD. Nicht funktionale Programmierung. Stattdessen ist es eine Kombination aus Praktiken, Kultur und Mindset. Und alles beginnt mit dem Team. Man braucht Menschen mit einer Can-Do-Einstellung, die proaktiv sind, lernen wollen und Feedback annehmen können. Gibt man ihnen Sinn und Autonomie, werden sie grossartige Ergebnisse liefern.\nFünf Säulen hochwertiger Engineering-Arbeit # Milan präsentiert fünf Säulen, die das Fundament für qualitativ hochwertige Engineering-Arbeit bilden:\nKundenzentrierung: Der Kunde will seine Probleme gelöst haben. Er interessiert sich nicht für unsere schicken Architekturen oder Clean Code Frameworks. Wir müssen seine Bedürfnisse jederzeit im Blick behalten.\nGutes Software-Design: Architektur wird überschätzt, aber einfaches Design wird sehr unterschätzt. Mit einem Dokument starten, Design Reviews und Architectural Decision Records einsetzen. Explizit über Trade-offs sein. Für Veränderung designen, mit hoher Separation of Concerns und loser Kopplung.\nGute Code-Qualität: Guter Code ist wie ein Witz: Man muss ihn nicht erklären. Die Boy Scout Rule befolgen, geprägt von Uncle Bob Martin. Jedes Mal, wenn man eine Datei öffnet, eine kleine Verbesserung machen. Eine Variable umbenennen, Logik refactoren, einen fehlenden Test schreiben.\nEngineering-Kultur: Eine Kultur schaffen, in der man um Hilfe bitten kann wenn man feststeckt, in der es Zeit für Weiterbildung und Training gibt, in der regelmässig Knowledge-Sharing-Sessions stattfinden, und in der psychologische Sicherheit Experimentieren und Scheitern ermöglicht.\nQuality-First-Mindset: Wenn man keine Tests hat, funktioniert es nicht. Die Testpyramide befolgen, 60 bis 90 Prozent Code Coverage anstreben, eine Zero-Bug-Policy anwenden und alles automatisieren, was möglich ist.\n\u0026ldquo;Guter Code ist wie ein Witz. Man muss ihn nicht erklären. Wenn der Code einfach und verständlich ist, braucht man keine Code-Kommentare.\u0026rdquo;\nTechnische Schulden bekämpfen # Technische Schulden kommen in vielen Formen: schlechte Code-Qualität, fehlende Tests, stark gekoppelter Code, ungenutzte Features, veraltete Bibliotheken, schlechtes Tooling, manuelle Prozesse und mangelnder Wissensaustausch. Die Auswirkungen sind real: Im Laufe der Zeit schrumpft die verfügbare Zeit für neue Feature-Entwicklung, während die Zeit, die man mit Komplexität und technischen Schulden kämpft, zunimmt.\nWie kämpft man dagegen an? Erstens: Transparenz schaffen. Technische Schulden für Produkt und Management sichtbar machen. Zweitens: Das Management muss das Team ermächtigen, diese Probleme zu beheben. Im Idealfall entsteht eine Kultur, in der man keine Erlaubnis braucht, um zu refactoren und Dinge zu verbessern. Ja, es mag kurzfristig 10 bis 20 Prozent langsamer machen, aber langfristig gewinnt man alles zurück.\nDie Broken-Window-Theorie # Warum schreiben wir schlechten Code? Die Broken-Window-Theorie erklärt es gut: Wenn man ein Gebäude mit eingeschlagenen Fenstern sieht, fühlt es sich nicht falsch an, noch einen Stein zu werfen. Aber wenn das Gebäude makellos ist, würde man es nicht wagen, es zu beschädigen. Kleine Unordnungen wachsen über die Zeit. Deshalb ist die Boy Scout Rule so wichtig: Die Codebasis jedes Mal sauberer hinterlassen, als man sie vorgefunden hat.\nVon Projekten zu Produkten mit DevOps # Im zweiten Teil der Session erkläre ich eine Herausforderung, die ich in jedem Unternehmen sehe, in dem ich arbeite. Das Business hat grossartige Ideen. Sie schreiben sie in Dokumente und Jira-Tickets und werfen sie über die \u0026ldquo;Wall of Confusion\u0026rdquo; zum Entwicklungsteam. Das Entwicklungsteam implementiert etwas und wirft es dem Testing-Team zu. Das Testing-Team wirft es dem Operations-Team zu. Der Kunde sagt: \u0026ldquo;Was ist das? Das haben wir nicht bestellt.\u0026rdquo;\nDie Ursache liegt in Silo-Organisationen und dem Projekt-Mindset. In einem Projekt sind Scope, Budget und Zeit fixiert, und der Fokus liegt auf der Maximierung des Outputs, der Anzahl gelieferter Features. Aber beim Bauen von Produkten muss der Fokus auf dem Outcome liegen: das echte Kundenbedürfnis verstehen und das echte Problem lösen.\n\u0026ldquo;DevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken, die enge Kommunikation, Integration, Automatisierung und Zusammenarbeit zwischen allen Beteiligten im Wertstrom ermöglicht.\u0026rdquo;\nDie Continuous Delivery Pipeline aufbauen # Um von Projekten zu Produkten zu gelangen, müssen wir den Wertstrom identifizieren. Value Stream Mapping bringt alle Beteiligten zusammen, um jeden Schritt von der Idee bis zur Produktion zu visualisieren. Es deckt Engpässe auf, indem Lead Time (gesamte verstrichene Zeit) mit Process Time (tatsächlich wertschöpfende Arbeit) verglichen wird. Oft ist der Unterschied erschreckend.\nDie Continuous Delivery Pipeline ist das Fliessband der digitalen Fabrik. Sie automatisiert den gesamten Fluss von Code bis Produktion. Das ist im Grunde Platform Engineering: Die Plattform bereitstellen, auf der Teams grossartige Produkte bauen.\nQualität und Betreibbarkeit einbauen # Qualität muss von Anfang an durch kontinuierliches Feedback eingebaut werden. Das traditionelle V-Modell mit verzögertem Feedback, bei dem Monate zwischen dem Schreiben eines Features und dem Testen vergehen, muss durch einen Shift-Left-Ansatz ersetzt werden. Behavior-Driven Development (BDD) erstellt klare Akzeptanzkriterien, die direkt in Tests umgewandelt werden können. Test-Driven Development (TDD) stellt sicher, dass Tests von Anfang an existieren.\nGenauso wichtig ist das Design für Betreibbarkeit. \u0026ldquo;You build it, you run it\u0026rdquo; ist nicht nur ein Slogan. Es bedeutet, von Anfang an an Monitoring, Logging, Alerting und Disaster Recovery zu denken. Infrastructure as Code, Application Telemetry und automatisierte Incident Response sind alle essenziell.\nKernaussagen # Es gibt kein Patentrezept. Hochwertige Engineering-Arbeit erfordert eine Kombination aus grossartigen Teams, Kundenfokus, einfachem Design, sauberem Code und starker Engineering-Kultur.\nTechnische Schulden sind eine echte Bedrohung. Sichtbar machen, Teams ermächtigen sie zu beheben, und die Boy Scout Rule befolgen: Code sauberer hinterlassen, als man ihn vorgefunden hat.\nVon Projekten zu Produkten wechseln. Auf Outcomes fokussieren (echte Kundenprobleme lösen) statt auf Outputs (eine fixe Anzahl Features liefern).\nDen Wertstrom identifizieren und optimieren. Value Stream Mapping deckt Engpässe auf. Die Continuous Delivery Pipeline ist das Fliessband der digitalen Fabrik.\nQualität von Anfang an einbauen. BDD und TDD nutzen, um das Testen nach links zu verschieben. Vom ersten Tag an für Betreibbarkeit designen.\nAlles automatisieren. Von Builds über Tests über Deployments bis zu Monitoring. Manuelle Prozesse sind der Feind von Geschwindigkeit und Qualität.\n","date":"9. December 2022","externalUrl":null,"permalink":"/de/blogs/hochwertige-arbeit-in-der-softwareentwicklung/","section":"Blogs","summary":"Was definiert hochwertige Arbeit in der Softwareentwicklung? Ist es Scrum? Clean Code? TDD? Funktionale Programmierung? In dieser Expert Talks Session präsentieren mein Kollege Milan und ich zwei komplementäre Perspektiven. Milan behandelt die Säulen hochwertiger Engineering-Arbeit, von Teambildung und Kundenzentrierung bis zu Clean Code und Engineering-Kultur. Ich zeige dann, wie DevOps und Continuous Delivery helfen, grossartige Produkte zu bauen, indem man vom Projekt-Mindset zum Produkt-Mindset wechselt.\n","title":"Hochwertige Arbeit in der Softwareentwicklung und grossartige Developer Experience","type":"blogs"},{"content":"","date":"9 December 2022","externalUrl":null,"permalink":"/en/tags/technical-debt/","section":"Tags","summary":"","title":"Technical Debt","type":"tags"},{"content":"","date":"9. December 2022","externalUrl":null,"permalink":"/de/tags/technische-schulden/","section":"Tags","summary":"","title":"Technische Schulden","type":"tags"},{"content":"","date":"7 December 2022","externalUrl":null,"permalink":"/en/tags/conflict-management/","section":"Tags","summary":"","title":"Conflict Management","type":"tags"},{"content":"In every project, every company, every department, there is a Game of Thrones being played. Power plays between people, teams, and departments that result in massive conflicts. In this talk, I share why these conflicts exist, what strategies you can use to survive them, and how to stay healthy during difficult times. The Game of Thrones is played everywhere. It starts in kindergarten with the fight over a puppet and ends at your deathbed when descendants fight over your heritage.\nThe Five Inner Demons: Why We Are Violent # Violence is deeply rooted in each one of us because evolutionarily, it was important for human survival. We all have five characteristics that lead us to use violence. I call them the Five Inner Demons.\nPredatory violence is often an easy way to gain an evolutionary advantage. The stronger simply took what they needed. In one of my projects at a private bank, the IT department lost control of a project to the business department after we successfully introduced agile methods. The IT department called it robbery. The business department called it a logical step for the good of the company.\nDominance is about gaining or maintaining power. Once you have established that you are in charge, you do not need to fight every time. A manager once yelled at me in a meeting: \u0026ldquo;I have 13 years of software engineering experience, I have been working for 10 years in this bank as a manager. You don\u0026rsquo;t need to tell me how we should build software.\u0026rdquo; As Tywin Lannister would say: \u0026ldquo;Any man who must say I am the manager is no true manager.\u0026rdquo;\nRevenge is spread across all cultures. \u0026ldquo;An eye for an eye, a tooth for a tooth.\u0026rdquo; Evolution has made revenge feel sweet. Experiments with laboratory rats showed that their brains react to revenge as euphorically as to sugar or cocaine. At the private bank, after business moved the project away from IT, IT made business\u0026rsquo;s life as hard as possible, and business returned the favor. Sweet revenge, and we were stuck in the middle.\nSadism fortunately does not live in all of us, but the capacity for it is present in every human being. I have never encountered pure sadism in my work, but I will never tolerate it.\nIdeology is perhaps surprising on this list. Ideology is always about achieving a perfect state where everybody is happy. But practically, the path to that state is often paved with conflict. At the private bank, the IT department had a waterfall process. Then Zühlke appeared, promoting agile, a different way. And the conflict started.\nThe Four Angels: What Keeps Violence in Check # Fortunately, we also have positive characteristics that help suppress violence.\nEmpathy originally served the purpose of caring for our children and relatives. Evolutionarily, empathic behavior made it possible to have beneficial relationships beyond blood relations. If you think you are not empathic, good news: empathy can be trained. I use empathy constantly in my work, always asking myself: what are the motives, goals, and feelings of my counterpart?\nSelf-control is governed by the prefrontal cortex, which makes rational and complex decisions. When a quick reward is available, the older limbic system can override it with emotional impulses. Violent people struggle with impulse control. Fortunately, self-control can be trained through exercise, strict diets, or any discipline that builds impulse control in one area and transfers to others.\nMorality is a shaky candidate. It can suppress violence by strengthening group cohesion, but it can also promote violence toward people who think differently.\nThe mind is perhaps our greatest asset. Being violent is often easy and promises quick success, but it is usually quite foolish. The smarter and more educated we become, the more alternative paths we discover.\nYou need to know the Five Inner Demons: predatory, dominance, revenge, sadism, and ideology. And you need to know they can be managed by empathy, self-control, morality, and the mind.\nSeven Conflict Types in the Workplace # A conflict occurs when the interests, objectives, or values of individuals or groups appear to be incompatible. Here are the seven most common types you will encounter:\nGoal Conflict: Two goals cannot be achieved simultaneously (cheap price but high quality) Relationship Conflict: One party hurts, humiliates, or disregards the other (driven by dominance) Conflict of Matter: Differences of opinion or viewpoints (is Java better than .NET?) Conflict of Strategy: Agreement on goals, but different views on how to achieve them (agile vs. waterfall) Value Conflict: Different value systems, arising when someone tries to force their values on others (religious conflicts, environmental values) Role Conflict: Incompatible demands placed upon a person (seller expected to be honest by customers but to maximize sales by management) Conflict of Interest: A person involved in multiple interests where serving one works against the other (insider trading, company vs. customer interests) Note that a conflict can also consist of multiple other conflicts. Behind a relationship conflict, there is often a goal conflict as the root cause.\nNine Stages of Conflict Escalation # The model of conflict escalation has nine stages across three levels:\nLevel 1: Both parties can still win\nStage 1: Tension (occasional clashes of opinion) Stage 2: Debate (strategies to convince, black-and-white thinking, ideology joins) Stage 3: Action instead of words (pressure increases, communication breaks off, dominance joins) Level 2: One party loses\nStage 4: Coalition (searching for followers, winning becomes more important than the issue) Stage 5: Loss of face (destruction through fake facts, trust is completely lost, revenge joins) Stage 6: Threat strategies (attempts to gain absolute control through threats) Level 3: Both parties lose\nStage 7: Limited destruction (opponent no longer regarded as human, sadism joins) Stage 8: Total extinction (opponent to be destroyed by all means) Stage 9: Together into the abyss (personal extinction accepted to defeat the opponent) For de-escalation: in stages 1 to 3, you can mediate yourself. In stages 4 to 6, you need a professional like a psychologist. In stages 7 to 9, you need forced intervention: lawyers, judges, or authorities.\nThe Battle Map and Strategy Matrix # For conflict resolution, I use a strategy matrix with two axes: cooperation level and pressure level.\nHigh cooperation + High pressure = Cooperative mode (both parties win) Low cooperation + High pressure = Pressure mode (I win, opponent loses) High cooperation + Low pressure = Withdrawal (I lose, opponent wins) Low cooperation + Low pressure = Avoidance (conflict not resolved, both lose) Medium on both axes = Trade-off (nobody is happy, but it is a resolution) I also use a battle map: a network diagram of all stakeholders with green lines (allies), orange lines (light conflicts), and red lines (heavy conflicts), annotated with conflict types. This map helps with stakeholder management and identifying problem areas.\nTwo Survival Strategies: Meditation and Sleep # Conflicts are not solved in a day. You need strategies to stay healthy during difficult times.\nMeditation: I meditate at least four times every week. It relaxes the brain, makes me calm, and measurably changes brain waves. Studies show meditation improves your mind, self-control, and empathy. Simply sit upright, keep your eyes open looking at a wall, breathe in and out, count breaths from 1 to 10, and try not to think about anything for 20 minutes. As an old saying goes: \u0026ldquo;You should sit in meditation for 20 minutes a day. Unless you are too busy. Then you should sit for an hour.\u0026rdquo;\nSleep: Too often completely underestimated. Only during sleep can your body store what you have learned, repair cells, and recharge batteries. Sleep at least seven to nine hours every day. If you cannot sleep because your mind is wandering, get up and meditate. After meditation, you will sleep very well.\nKey Takeaways # Workplace conflicts are driven by five inner demons: predatory instinct, dominance, revenge, sadism, and ideology Four angels help manage these demons: empathy, self-control, morality, and the mind Learn to identify the seven conflict types and the nine stages of escalation to choose the right resolution strategy Use the strategy matrix (cooperation vs. pressure) and battle maps for systematic conflict resolution Meditation and sufficient sleep are the two most important survival strategies for staying healthy during conflict Knowledge is the key. When you understand why people behave the way they do, the whole Game of Thrones loses its horror ","date":"7 December 2022","externalUrl":null,"permalink":"/en/blogs/how-to-survive-game-of-thrones-in-the-workplace/","section":"Blogs","summary":"In every project, every company, every department, there is a Game of Thrones being played. Power plays between people, teams, and departments that result in massive conflicts. In this talk, I share why these conflicts exist, what strategies you can use to survive them, and how to stay healthy during difficult times. The Game of Thrones is played everywhere. It starts in kindergarten with the fight over a puppet and ends at your deathbed when descendants fight over your heritage.\n","title":"How to Survive Game of Thrones in the Workplace: A Guide for Conflict Management","type":"blogs"},{"content":"","date":"7. December 2022","externalUrl":null,"permalink":"/de/tags/konfliktmanagement/","section":"Tags","summary":"","title":"Konfliktmanagement","type":"tags"},{"content":"","date":"7 December 2022","externalUrl":null,"permalink":"/en/tags/soft-skills/","section":"Tags","summary":"","title":"Soft Skills","type":"tags"},{"content":"In jedem Projekt, jedem Unternehmen, jeder Abteilung wird ein Game of Thrones gespielt. Machtspiele zwischen Menschen, Teams und Abteilungen, die zu massiven Konflikten führen. In diesem Vortrag zeige ich, warum diese Konflikte existieren, welche Strategien man nutzen kann, um sie zu überleben, und wie man in schwierigen Zeiten gesund bleibt. Das Game of Thrones wird überall gespielt. Es beginnt im Kindergarten mit dem Kampf um eine Puppe und endet auf dem Sterbebett, wenn Nachkommen um das Erbe kämpfen.\nDie fünf inneren Dämonen: Warum wir gewalttätig sind # Gewalt ist tief in uns verwurzelt, weil sie evolutionär für das Überleben der Menschheit wichtig war. Wir alle haben fünf Eigenschaften, die uns zur Gewalt führen. Ich nenne sie die Fünf Inneren Dämonen.\nRaubgewalt ist oft ein einfacher Weg, einen evolutionären Vorteil zu erlangen. Der Stärkere nahm einfach, was er brauchte. In einem meiner Projekte bei einer Privatbank verlor die IT-Abteilung die Kontrolle über ein Projekt an die Geschäftsabteilung, nachdem wir erfolgreich agile Methoden eingeführt hatten. Die IT nannte es Raub. Das Business nannte es einen logischen Schritt zum Wohl des Unternehmens.\nDominanz dreht sich darum, Macht zu gewinnen oder zu erhalten. Wenn man einmal klargestellt hat, dass man das Sagen hat, muss man nicht jedes Mal kämpfen. Ein Manager schrie mich einmal in einem Meeting an: \u0026ldquo;Ich habe 13 Jahre Erfahrung in Software Engineering, ich arbeite seit 10 Jahren als Manager in dieser Bank. Sie müssen mir nicht sagen, wie wir Software bauen sollen.\u0026rdquo; Wie Tywin Lannister sagen würde: \u0026ldquo;Jeder Mann, der sagen muss, ich bin der Manager, ist kein wahrer Manager.\u0026rdquo;\nRache ist in allen Kulturen verbreitet. \u0026ldquo;Auge um Auge, Zahn um Zahn.\u0026rdquo; Die Evolution hat Rache süss gemacht. Experimente mit Laborratten zeigten, dass ihre Gehirne auf Rache genauso euphorisch reagieren wie auf Zucker oder Kokain. Bei der Privatbank machte die IT dem Business das Leben so schwer wie möglich, nachdem das Business das Projekt abgezogen hatte, und das Business revanchierte sich. Süsse Rache, und wir steckten mittendrin.\nSadismus lebt glücklicherweise nicht in uns allen, aber die Fähigkeit dazu ist in jedem Menschen vorhanden. Ich bin in meiner Arbeit nie auf reinen Sadismus gestossen, aber ich würde ihn niemals tolerieren.\nIdeologie ist vielleicht überraschend auf dieser Liste. Ideologie strebt immer einen perfekten Zustand an, in dem alle glücklich sind. Aber praktisch ist der Weg zu diesem Zustand oft mit Konflikten gepflastert. Bei der Privatbank hatte die IT-Abteilung einen Wasserfall-Prozess. Dann erschien Zühlke und propagierte einen neuen Weg, den agilen Weg. Und der Konflikt begann.\nDie vier Engel: Was Gewalt in Schach hält # Glücklicherweise haben wir auch positive Eigenschaften, die Gewalt unterdrücken.\nEmpathie diente ursprünglich der Fürsorge für unsere Kinder und Verwandten. Evolutionär ermöglichte empathisches Verhalten vorteilhafte Beziehungen über Blutsverwandtschaft hinaus. Wer denkt, nicht empathisch zu sein, dem sei gesagt: Empathie kann trainiert werden. Ich nutze Empathie ständig bei der Arbeit und frage mich immer: Was sind die Motive, Ziele und Gefühle meines Gegenübers?\nSelbstkontrolle wird vom präfrontalen Kortex gesteuert, der rationale und komplexe Entscheidungen trifft. Wenn eine schnelle Belohnung verfügbar ist, kann das ältere limbische System es mit emotionalen Impulsen übersteuern. Gewalttätige Menschen haben Probleme mit Impulskontrolle. Glücklicherweise kann Selbstkontrolle durch Sport, strikte Diäten oder jede Disziplin trainiert werden, die Impulskontrolle in einem Bereich aufbaut und auf andere überträgt.\nMoral ist ein wackeliger Kandidat. Sie kann Gewalt unterdrücken, indem sie den Gruppenzusammenhalt stärkt, aber sie kann auch Gewalt gegenüber Menschen fördern, die anders denken.\nDer Verstand ist vielleicht unser grösstes Gut. Gewalttätig zu sein ist oft einfach und verspricht schnellen Erfolg, ist aber meist ziemlich dumm. Je klüger und gebildeter wir werden, desto mehr alternative Wege entdecken wir.\nMan muss die Fünf Inneren Dämonen kennen: Raubinstinkt, Dominanz, Rache, Sadismus und Ideologie. Und man muss wissen, dass sie durch Empathie, Selbstkontrolle, Moral und Verstand gemanagt werden können.\nSieben Konflikttypen am Arbeitsplatz # Ein Konflikt entsteht, wenn die Interessen, Ziele oder Werte von Individuen oder Gruppen als unvereinbar erscheinen. Hier sind die sieben häufigsten Typen:\nZielkonflikt: Zwei Ziele können nicht gleichzeitig erreicht werden (günstiger Preis bei hoher Qualität) Beziehungskonflikt: Eine Partei verletzt, demütigt oder missachtet die andere (getrieben durch Dominanz) Sachkonflikt: Unterschiedliche Meinungen oder Standpunkte (ist Java besser als .NET?) Strategiekonflikt: Einigkeit über Ziele, aber unterschiedliche Ansichten über den Weg (agil vs. Wasserfall) Wertekonflikt: Unterschiedliche Wertesysteme, entstehen wenn jemand versucht, seine Werte anderen aufzuzwingen Rollenkonflikt: Unvereinbare Anforderungen an eine Person (Verkäufer soll ehrlich zum Kunden sein, aber vom Management möglichst viel verkaufen) Interessenkonflikt: Eine Person ist in mehrere Interessen involviert, wobei die Bedienung eines Interesses gegen das andere arbeitet Ein Konflikt kann auch aus mehreren anderen Konflikten bestehen. Hinter einem Beziehungskonflikt steckt oft ein Zielkonflikt als Grundursache.\nNeun Stufen der Konflikteskalation # Das Modell der Konflikteskalation hat neun Stufen auf drei Ebenen:\nEbene 1: Beide Parteien können noch gewinnen\nStufe 1: Spannung (gelegentliche Meinungsverschiedenheiten) Stufe 2: Debatte (Strategien zum Überzeugen, Schwarz-Weiss-Denken, Ideologie tritt bei) Stufe 3: Taten statt Worte (Druck steigt, Kommunikation bricht ab, Dominanz tritt bei) Ebene 2: Eine Partei verliert\nStufe 4: Koalition (Anhänger suchen, Gewinnen wird wichtiger als das Thema) Stufe 5: Gesichtsverlust (Zerstörung durch falsche Fakten, Vertrauen komplett verloren, Rache tritt bei) Stufe 6: Drohstrategien (Versuch, absolute Kontrolle durch Drohungen zu gewinnen) Ebene 3: Beide Parteien verlieren\nStufe 7: Begrenzte Vernichtung (Gegner wird nicht mehr als Mensch betrachtet, Sadismus tritt bei) Stufe 8: Totale Vernichtung (Gegner soll mit allen Mitteln zerstört werden) Stufe 9: Gemeinsam in den Abgrund (persönliche Vernichtung wird akzeptiert, um den Gegner zu besiegen) Zur Deeskalation: In den Stufen 1 bis 3 kann man selbst vermitteln. In den Stufen 4 bis 6 braucht man einen Profi wie einen Psychologen. In den Stufen 7 bis 9 braucht man erzwungene Intervention: Anwälte, Richter oder Behörden.\nDie Battle Map und die Strategiematrix # Für die Konfliktlösung nutze ich eine Strategiematrix mit zwei Achsen: Kooperationsniveau und Druckniveau.\nHohe Kooperation + Hoher Druck = Kooperativer Modus (beide Parteien gewinnen) Niedrige Kooperation + Hoher Druck = Druckmodus (ich gewinne, Gegner verliert) Hohe Kooperation + Niedriger Druck = Rückzug (ich verliere, Gegner gewinnt) Niedrige Kooperation + Niedriger Druck = Vermeidung (Konflikt nicht gelöst, beide verlieren) Mittig auf beiden Achsen = Kompromiss (niemand ist glücklich, aber es ist eine Lösung) Zusätzlich nutze ich eine Battle Map: ein Netzwerkdiagramm aller Stakeholder mit grünen Linien (Verbündete), orangenen Linien (leichte Konflikte) und roten Linien (schwere Konflikte), annotiert mit Konflikttypen. Diese Karte hilft beim Stakeholder-Management und der Identifikation von Problemfeldern.\nZwei Überlebensstrategien: Meditation und Schlaf # Konflikte werden nicht an einem Tag gelöst. Man braucht Strategien, um in schwierigen Zeiten gesund zu bleiben.\nMeditation: Ich meditiere mindestens viermal pro Woche. Es entspannt das Gehirn, macht mich ruhig und verändert messbar die Gehirnwellen. Studien zeigen, dass Meditation den Verstand, die Selbstkontrolle und die Empathie verbessert. Einfach aufrecht sitzen, Augen offen auf eine Wand schauen, ein- und ausatmen, Atemzüge von 1 bis 10 zählen und versuchen, 20 Minuten an nichts zu denken. Wie ein altes Sprichwort sagt: \u0026ldquo;Du solltest 20 Minuten am Tag meditieren. Es sei denn, du bist zu beschäftigt. Dann solltest du eine Stunde meditieren.\u0026rdquo;\nSchlaf: Viel zu oft völlig unterschätzt. Nur im Schlaf kann der Körper Gelerntes speichern, Zellen reparieren und Batterien aufladen. Mindestens sieben bis neun Stunden täglich schlafen. Wenn man nicht schlafen kann, weil die Gedanken wandern: aufstehen und meditieren. Nach der Meditation schläft man sehr gut.\nKernaussagen # Konflikte am Arbeitsplatz werden durch fünf innere Dämonen angetrieben: Raubinstinkt, Dominanz, Rache, Sadismus und Ideologie Vier Engel helfen, diese Dämonen zu managen: Empathie, Selbstkontrolle, Moral und Verstand Lerne, die sieben Konflikttypen und die neun Eskalationsstufen zu erkennen, um die richtige Lösungsstrategie zu wählen Nutze die Strategiematrix (Kooperation vs. Druck) und Battle Maps für systematische Konfliktlösung Meditation und ausreichend Schlaf sind die zwei wichtigsten Überlebensstrategien, um in Konflikten gesund zu bleiben Wissen ist der Schlüssel. Wenn man versteht, warum Menschen sich so verhalten, wie sie sich verhalten, verliert das ganze Game of Thrones seinen Schrecken ","date":"7. December 2022","externalUrl":null,"permalink":"/de/blogs/wie-man-game-of-thrones-am-arbeitsplatz-ueberlebt/","section":"Blogs","summary":"In jedem Projekt, jedem Unternehmen, jeder Abteilung wird ein Game of Thrones gespielt. Machtspiele zwischen Menschen, Teams und Abteilungen, die zu massiven Konflikten führen. In diesem Vortrag zeige ich, warum diese Konflikte existieren, welche Strategien man nutzen kann, um sie zu überleben, und wie man in schwierigen Zeiten gesund bleibt. Das Game of Thrones wird überall gespielt. Es beginnt im Kindergarten mit dem Kampf um eine Puppe und endet auf dem Sterbebett, wenn Nachkommen um das Erbe kämpfen.\n","title":"Wie man Game of Thrones am Arbeitsplatz überlebt: Ein Leitfaden für Konfliktmanagement","type":"blogs"},{"content":"I was invited to deliver the keynote at the Baloise OpenX Day, an internal conference where Baloise brings together their technology community. The session combined impulse presentations with interactive discussions, giving me the chance to share DevOps fundamentals and then hear directly from the teams about their real challenges. The conversations with the Baloise engineers were incredibly valuable, especially around topics like continuous deployment in regulated industries and the role of platform engineering.\nThe Broken Value Stream # I started by showing a picture that I encounter at many companies: the broken value stream. Business throws requirements over a wall to development, development throws code to testing, testing passes something to operations, and the customer receives something they did not ask for. These \u0026ldquo;walls of confusion\u0026rdquo; stem from silo organizations and a fundamental lack of alignment.\nThe deeper issue is the project mindset. Projects focus on maximizing output, meaning the number of features delivered within a fixed budget and timeline. Products, on the other hand, focus on outcomes: understanding the customer, solving their problems, and changing their behavior. DevOps enables this product mindset by aligning all people, processes, and technology across the value stream.\n\u0026ldquo;DevOps is a mindset, a culture, and a set of technical practices which provides communication, integration, automation, and close collaboration among all the people in the value stream.\u0026rdquo;\nUnderstanding and Measuring the Value Stream # One of the most powerful DevOps techniques I shared is Value Stream Mapping. You bring all the people who work on the value stream into one room: business, architects, developers, testers, security, quality assurance, operations. Together you map every step from idea to production, identify who is responsible, and then measure three things: lead time (total time including waiting), process time (actual value-adding work), and percentage complete and accurate (how often the next step can use the output as is).\nThe results are often eye-opening. In my example, the testing step had a lead time of 336 hours but only 8 hours of actual process time. That means most of the time is spent waiting. The rolling percentage complete and accurate was just 5%, meaning only 5% of work flows through the entire process without rework. When teams see these numbers, they immediately understand where the bottlenecks are and can begin to address them.\nContinuous Delivery: Getting the Terms Right # A topic I always spend time on is clarifying the CI/CD terminology, because I see many teams using these terms incorrectly. Continuous Integration means every code commit triggers an automated build with code analysis, security analysis, unit tests, and integration tests, and feedback comes within minutes. The output is a deployable artifact.\nContinuous Delivery takes that artifact and automatically installs it in a staging environment for further testing. Continuous Deployment goes one step further: the artifact automatically moves through staging into production, with automated tests at each stage and automatic rollback if something fails.\nThe important insight: you do not necessarily need continuous deployment. Continuous delivery is absolutely fine for many teams. But you need to be clear about which level you are at and what your business actually requires. The key is to always ask: how fast does the business need to deliver?\nDevOps in Regulated Industries # The most engaging part of the session was the discussion about DevOps in regulated financial services. A recurring concern was: \u0026ldquo;We need manual sign-off before production deployment. Is continuous deployment even possible for us?\u0026rdquo; My answer was clear: yes, it is.\nThe common argument in financial institutions is that segregation of duty requires a different person to approve deployments. But when you actually read the regulation, it says that a developer should not be able to directly deploy into production. It does not say a human must manually check every deployment. An automated pipeline with proper security checks, static code analysis, automated testing, and audit trails fulfills the regulatory intent far better than a human reviewing Jira tickets.\n\u0026ldquo;Science says: if you have a manual release management gate, your software delivery performance will be hurt. The best thing, sorry to say, is to get rid of it.\u0026rdquo;\nI recommended a revealing experiment: intentionally introduce a small piece of bad code through the organization\u0026rsquo;s release process. In most cases, the manual review gates will not catch it, which demonstrates that automation provides far superior protection.\nPlatform Engineering for Scale # The later discussions touched on platform engineering as the key to scaling DevOps. When each product team builds and maintains their own CI/CD tooling, the cognitive load becomes overwhelming. New team members need months to become productive. Ordering a new Kubernetes cluster or database takes weeks.\nPlatform engineering solves this by creating a dedicated team that provides a shared platform. API gateways, CI/CD pipelines, Kubernetes clusters, repositories, security scanning, synthetic test data: everything teams need is available as a self-service product. The platform team is not another silo. They deliver a product that enables product teams to focus on feature development and customer value.\nThis concept turns an organization into a \u0026ldquo;digital factory,\u0026rdquo; not in the sense of repetitive assembly line work, but as a modern, automated foundation where all the boring infrastructure tasks are handled, and developers can concentrate on what truly matters.\nThe Three Ways of DevOps # Throughout the session, I kept returning to the three ways of DevOps. First, optimize the flow of work through the value stream from left to right. Second, create fast feedback loops from right to left so that issues are caught and corrected quickly. Third, foster a culture of continuous learning and experimentation. These three principles apply regardless of company size, industry, or regulatory environment.\nThe Baloise teams were already making progress: they had moved from monthly releases to several releases per week. Some teams had platform teams running their continuous delivery tooling. The DevOps spirit was growing, even if not yet at every level of the company. As I told them, it is a continuous improvement journey, and every step forward counts.\nKey Takeaways # Value Stream Mapping is one of the most powerful tools to visualize waste and bottlenecks in your software delivery process. Continuous Delivery vs. Continuous Deployment: know which level fits your needs, and do not confuse the terms. Regulated industries can adopt DevOps: automation meets regulatory requirements better than manual gates, if you read the actual regulations carefully. Platform engineering enables scale by reducing cognitive load on product teams and providing self-service infrastructure. The digital factory concept is about automating all the infrastructure work so teams can focus on customer value. Always ask: how fast does the business need to deliver? Speed is only valuable when it is directed toward solving real customer problems. ","date":"23 November 2022","externalUrl":null,"permalink":"/en/blogs/baloise-openx-day-devops-keynote/","section":"Blogs","summary":"I was invited to deliver the keynote at the Baloise OpenX Day, an internal conference where Baloise brings together their technology community. The session combined impulse presentations with interactive discussions, giving me the chance to share DevOps fundamentals and then hear directly from the teams about their real challenges. The conversations with the Baloise engineers were incredibly valuable, especially around topics like continuous deployment in regulated industries and the role of platform engineering.\n","title":"Baloise OpenX Day: Keynote on DevOps, Value Streams, and Platform Engineering","type":"blogs"},{"content":"","date":"23 November 2022","externalUrl":null,"permalink":"/en/tags/finance/","section":"Tags","summary":"","title":"Finance","type":"tags"},{"content":"","date":"23. November 2022","externalUrl":null,"permalink":"/de/tags/finanzbranche/","section":"Tags","summary":"","title":"Finanzbranche","type":"tags"},{"content":"","date":"23 November 2022","externalUrl":null,"permalink":"/en/tags/keynote/","section":"Tags","summary":"","title":"Keynote","type":"tags"},{"content":"After eleven sessions building a full DevSecOps pipeline with GitLab — from Software Composition Analysis to Container Scanning, SAST, Secret Detection, DAST, merge request integration, and scheduled pipelines — Patrick Steger and I close the series with our recommendations. What worked, what tripped us up, and what we would tell anyone setting out to build the same pipeline today.\nWhat We Built and What Stuck # Quick recap: we started with two introductory videos on GitLab and project setup, then layered in Software Composition Analysis to find vulnerabilities in dependencies, License Compliance to flag licensing issues, Static Application Security Testing for our own code, Container Scanning, Secret Detection to catch passwords accidentally committed, Dynamic Application Security Testing as an automated penetration test against the running app, merge request integration so the security impact of changes is visible before they land, and finally scheduled pipelines so production code keeps getting checked against newly disclosed vulnerabilities.\nThat is a lot of moving parts. Here is what we would actually recommend you focus on.\nDefine Your Default Branch # The default branch is the branch GitLab uses for Vulnerability Management. It is where all the results from your security tools surface. Get this right at the start of the project, because everything else — merge request gates, scheduled scans, the vulnerability dashboard — keys off it.\nSchedule Pipelines Against Production Code # Your application sits in production long after the last commit. Vulnerabilities in dependencies, base images, and frameworks are disclosed every day. If your pipeline only runs when someone changes code, you will miss them. Scheduled pipelines run your security tests on a regular cadence against the production code so you find new vulnerabilities as they become known. This is not optional — it is the only way to stay current.\nUse Merge Requests as Your Security Gate # Whenever code is merged into the default branch, route it through a merge request. The pipeline runs, and any newly introduced security issues become visible alongside the change that introduced them. Define which approvers are allowed to accept new issues — security findings should not be silently waved through by whoever happens to be online. A clear approval rule keeps the bar honest.\nNever Store Secrets in Source Code # Secret Detection exists because every team eventually commits a credential by accident. Run it on every commit so that mistake is caught immediately, not weeks later when someone scrapes the public repo. And put your secrets in a vault. GitLab integrates well with HashiCorp Vault, and that is what we recommend. Source code is for code; secrets belong in a secret store.\nOut-of-the-Box Tools Are Easier — Custom Tools Are Real Effort # GitLab ships a default set of security scanners, and using them is the path of least resistance: easy integration, low maintenance, predictable upgrades. If you bring your own tools, expect significant integration and maintenance effort. The exception worth highlighting is DAST — even with the GitLab-provided scanner, you must customize it. An out-of-the-box DAST configuration produces very limited results because the scanner does not know how to authenticate, where to crawl, or which inputs to exercise. Plan time for that customization. It is the difference between a real penetration test and a checkbox.\nBring a Security Expert into the Team # A DevSecOps pipeline is genuinely complex. Many tools, many configurations, many findings to triage. We strongly recommend including a security expert from the start — someone who can help you decide which tools to use, how to configure them, what to gate on, and how to manage the resulting vulnerability backlog. Without that expertise the pipeline will either be too noisy and ignored, or too lax and useless.\nKey Takeaways # Set the default branch deliberately. It anchors Vulnerability Management and every gate downstream of it. Get it right before you wire anything else up.\nScheduled pipelines protect production code. Vulnerabilities are disclosed daily; your pipeline cannot only run on commits. Schedule it.\nMerge requests are where security gates belong. New code into the default branch goes through a merge request, the pipeline runs, and approvers decide what gets accepted.\nSecrets never live in source code. Run Secret Detection on every commit, store secrets in a vault — HashiCorp Vault integrates cleanly with GitLab.\nOut-of-the-box scanners save weeks. Custom tools are possible but expensive. The exception: even GitLab\u0026rsquo;s own DAST needs serious customization to produce useful results.\nYou need a security expert on the team. The tooling is the easy part. Knowing what to gate, what to ignore, and how to manage the vulnerability backlog requires real expertise — bring it in early.\n","date":"16 November 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-recommendations/","section":"Blogs","summary":"After eleven sessions building a full DevSecOps pipeline with GitLab — from Software Composition Analysis to Container Scanning, SAST, Secret Detection, DAST, merge request integration, and scheduled pipelines — Patrick Steger and I close the series with our recommendations. What worked, what tripped us up, and what we would tell anyone setting out to build the same pipeline today.\n","title":"GitLab DevSecOps Part 12: Our Recommendations and Lessons Learned","type":"blogs"},{"content":"","date":"16 November 2022","externalUrl":null,"permalink":"/en/tags/secret-management/","section":"Tags","summary":"","title":"Secret Management","type":"tags"},{"content":"Over ten sessions we wired six security tools into a GitLab pipeline that fires on every commit and every Merge Request. So are we done? Not quite. Code in production sits there for weeks or months, and during that time researchers keep finding new CVEs in the dependencies you are already shipping. In Part 11 of the GitLab DevSecOps series, Patrick Steger and I add a scheduled pipeline so the production branch gets re-scanned automatically — without anyone having to push a commit.\nWhy a Commit-Triggered Pipeline Is Not Enough # Every job we built so far runs when something changes. That covers new code, but it does not cover what happens to old code as the world around it changes. A library you pulled in three months ago might have been clean back then and have a critical CVE today. The unit tests will not tell you. The static analyzer will not tell you. The only thing that catches it is re-running the dependency scanner against the same unchanged code.\nThat is what scheduled pipelines are for: re-execute the security checks on the branch that contains your production release, on a schedule, so newly disclosed vulnerabilities surface even when development has moved on.\nWhat to Run — and What to Skip # A scheduled run does not need the entire pipeline. Plenty of jobs are pure waste in this context. Unit tests against unchanged code will give the same answer in three months as they do today. The same is true for SAST against code that has not moved. Re-running them adds minutes and noise, nothing else.\nThe two jobs that earn their keep on a schedule are the ones that look outside your repo:\nSCA / Dependency Scanning. Walks the dependency tree, matches every library and version against the latest CVE database. This is the whole reason we are doing this. Container Scanning. The Docker image you shipped to production may have picked up new OS-level vulnerabilities since you built it. Same idea, different layer. Two jobs, run on a schedule, against the production branch. That is enough for the vast majority of teams.\nSetting It Up in GitLab # The mechanics are simple, with one trick. GitLab\u0026rsquo;s scheduled pipelines run a normal .gitlab-ci.yml, so we need a way for each job to know whether it is allowed to run in scheduled mode or not. We do that with a variable.\nThe recipe:\nMake sure you have a distinct release branch — the one that mirrors what is in production. In GitLab, go to CI/CD → Schedules and create a new schedule. Pick the cron interval (daily is a good default, weekly is fine for many teams), select your production release branch, and add a variable named SCAN_ONLY set to any value (we use true). In .gitlab-ci.yml, add a rules: block to every job you do not want to run on the scheduled pass. The rule says: if SCAN_ONLY is defined, never run this job. The SCA and container-scanning jobs get no such rule, so they keep running. Save the schedule. From here on, GitLab kicks off the pipeline on the cron you defined, on the branch you picked, with SCAN_ONLY set — and only the security jobs you care about execute.\nWhy the Variable Is the Key # You could solve this with two pipeline files, but then you have two pipelines to keep in sync. As soon as you add a new tool, you have to remember to add it in both places. Using one pipeline file with a SCAN_ONLY rule on every irrelevant job keeps everything in one place. The schedule decides what runs by setting the variable; every job decides for itself whether it cares.\nIt also makes the intent obvious when someone reads the pipeline. A job with if: $SCAN_ONLY and when: never is self-documenting: \u0026ldquo;this is not part of the scheduled scan.\u0026rdquo;\nAre We Secure Now? # If you have everything we built across the series — SAST, secret detection, SCA, container scanning, DAST, vulnerability management, Merge Request gating, and now a scheduled re-scan of production — you are on the best path GitLab makes available without bolting on third-party tools. You will still find issues. You will still need to triage. But you will find them when they are cheap, instead of when an auditor or an incident hands them to you.\nIn the next session, we wrap the series with the recommendations Patrick and I would actually give a team starting this from scratch.\nKey Takeaways # Commit triggers do not catch new CVEs in old code. A library that was clean three months ago can be critical today. You need a schedule to find that.\nRun only what changes between runs. SCA and container scanning earn their keep on a schedule. Unit tests and SAST against unchanged code are noise.\nOne pipeline file, one variable. Set SCAN_ONLY from the schedule, gate irrelevant jobs with a rules: block. No second pipeline to keep in sync.\nPick a real production branch. The schedule is only as useful as the branch it points at. Make sure that branch actually mirrors what is in production.\nDaily or weekly is enough. You do not need to scan every six minutes. Pick a cadence that matches how fast you can react to a new finding.\nScheduled scanning closes the loop. Pipelines on commit catch what you wrote. Schedules catch what the world wrote about your dependencies. You need both.\n","date":"9 November 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-schedule-pipeline/","section":"Blogs","summary":"Over ten sessions we wired six security tools into a GitLab pipeline that fires on every commit and every Merge Request. So are we done? Not quite. Code in production sits there for weeks or months, and during that time researchers keep finding new CVEs in the dependencies you are already shipping. In Part 11 of the GitLab DevSecOps series, Patrick Steger and I add a scheduled pipeline so the production branch gets re-scanned automatically — without anyone having to push a commit.\n","title":"GitLab DevSecOps Part 11: Scheduled Pipelines for Production Code","type":"blogs"},{"content":"In the previous nine sessions Patrick Steger and I built a GitLab DevSecOps pipeline that runs SAST, secret detection, software composition analysis, container scanning and DAST. Useful — but only if it actually catches issues before they reach the default branch. In Part 10 we close that loop: we wire the pipeline into Merge Requests so every change is scanned, the deltas against the default branch are visible, and approvals are required when new high or critical vulnerabilities appear.\nWhy Merge Requests Are the Real Gate # Up to now we always committed straight to the default branch in our demos. That is fine for showing a tool, but it is not how anyone runs a real project. In real projects you have a branching strategy: you work on a feature branch and you eventually merge it back to the default branch. The question is what happens at that merge point.\nGitLab\u0026rsquo;s answer is that the Merge Request itself is a security gate. It runs the full pipeline on the working branch, compares the security findings of that pipeline against the default branch, and reports the deltas — what is new, what disappeared. On top of that, you can define approvers for new critical or high vulnerabilities. Without their sign-off the merge is blocked.\nThe Workflow End to End # The flow is the same one most teams already know, with security findings folded in:\nCreate a feature branch for the issue or feature. Open a Merge Request right away — it does not have to be \u0026ldquo;ready.\u0026rdquo; Commit changes. The pipeline runs on every push and reports new security findings on the Merge Request. Review the code with the product owner and other developers. Discuss findings with developers and security experts. If a finding is a false positive, request approval to merge anyway. Merge, then delete the branch. The point of opening the MR early is the same as in any modern team: discussion happens during development, not after.\nWhat the MR Actually Looks Like in GitLab # In the demo we open a prepared Merge Request with two changes: a Java class that introduces an insecure MessageDigest using MD5, and a Spring Boot upgrade from 2.7.2 to 2.7.4. Both are deliberate — one to trigger SAST, one to exercise SCA on changed dependencies.\nScrolling down to the Security Scanning section, the new findings are listed inline. Click the SAST finding \u0026ldquo;Inadequate encryption strength\u0026rdquo; and GitLab jumps to the exact line of code where MD5 is used. That is what a delta should look like — not a 200-page report, but \u0026ldquo;here is what this MR added.\u0026rdquo;\nWhen everything is green and reviewed, the Merge button at the bottom does the work. The pipeline then re-runs on the default branch, because the default branch now has new code.\nConfiguring the Behaviour # The interesting settings live under Settings → Merge Requests. Two areas matter for DevSecOps.\nMerge checks. Enable \u0026ldquo;Pipelines must succeed\u0026rdquo;. This is exactly what it sounds like: a red pipeline blocks merging. We strongly recommend turning this on. It is the single line of defence between \u0026ldquo;the tools found something\u0026rdquo; and \u0026ldquo;the something is in main\u0026rdquo;.\nMerge Request approvals. Further down, you define approval rules. We had a license-check rule with Patrick and me as approvers. Below that come the security approvals — the powerful piece. You define rules around new vulnerabilities: which severity, who must approve, how many approvals. If your organisation has a security department, give them the security approver role. They then see exactly what new risk a Merge Request brings in and can accept it, decline it, or ask questions before it lands in the default branch.\nThe configuration is extensive — almost overwhelming the first time you see it. The good news is that you only need a few rules to start: pipeline must succeed, plus security approval for new high and critical vulnerabilities.\nRecap # The Merge Request is where the GitLab DevSecOps pipeline stops being a passive scanner and becomes a gate. The pipeline runs on the feature branch, the security findings are diffed against the default branch and shown inline, and defined approvers must sign off when serious new vulnerabilities appear. With that wired up, the team gets fast feedback during development, security experts see only the changes that matter to them, and nothing critical lands in main without a deliberate human decision.\nThe next session is about scheduled pipelines — making sure that code already in production keeps getting checked, even when nobody is committing.\nKey Takeaways # The Merge Request is the gate, not the pipeline. A green pipeline on the default branch only tells you about the past. The gate is the MR pipeline diffed against main, with approvals enforced on the diff.\nOpen Merge Requests early. They are a discussion tool, not a final-submit form. Early MRs mean early reviews, early security feedback and fewer surprises right before the merge.\nShow deltas, not totals. GitLab presents new versus existing findings on the Merge Request. Reviewers focus on what this change introduced, which is exactly what they can act on.\nTurn on \u0026ldquo;Pipelines must succeed\u0026rdquo;. It is one checkbox in Settings → Merge Requests and it is the difference between \u0026ldquo;the scanner ran\u0026rdquo; and \u0026ldquo;the scanner blocked the merge\u0026rdquo;. Skip it and everything else is theatre.\nUse security approval rules with intent. Configure them by severity (start with high and critical) and route them to the people who can actually make the call — typically a small security group, not every developer.\nFalse positives need a documented escape hatch. A finding will eventually be wrong. The approval flow gives you a clean path: discuss it, get the approver to sign off, merge — without disabling the rule for everyone else.\n","date":"2 November 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-merge-request/","section":"Blogs","summary":"In the previous nine sessions Patrick Steger and I built a GitLab DevSecOps pipeline that runs SAST, secret detection, software composition analysis, container scanning and DAST. Useful — but only if it actually catches issues before they reach the default branch. In Part 10 we close that loop: we wire the pipeline into Merge Requests so every change is scanned, the deltas against the default branch are visible, and approvals are required when new high or critical vulnerabilities appear.\n","title":"GitLab DevSecOps Part 10: How to Do a Merge Request the Right Way","type":"blogs"},{"content":"","date":"2 November 2022","externalUrl":null,"permalink":"/en/tags/merge-request/","section":"Tags","summary":"","title":"Merge Request","type":"tags"},{"content":"DevOps is far more than automation or tooling: it is the interplay of people, processes, and technology to develop products faster, more reliably, and more customer-focused.\nWhat This Talk Covers # This talk shows why companies must shift from project-oriented thinking to product-centric working, how a Continuous Delivery Pipeline works as the backbone of modern product development, and why quality, testing, and operability must be considered from the start.\nKey Messages # 1. From Projects to Products Companies need to move from project-oriented thinking to product-centric working to deliver value continuously and respond to customer needs faster.\n2. Continuous Delivery as Backbone A Continuous Delivery Pipeline is the backbone of modern product development. Quality, testing, and operability must be built in from the start, not bolted on at the end.\n3. Breaking Down Silos Using practical concepts and examples, the talk shows how organizations can break down silos, identify bottlenecks in their value stream, and build the foundation for effective digital product development.\n","date":"27 October 2022","externalUrl":null,"permalink":"/en/speaking/devops-wie-unternehmen-kontinuierlich-wert-liefern/","section":"Speaking","summary":"DevOps is far more than automation or tooling: it is the interplay of people, processes, and technology to develop products faster, more reliably, and more customer-focused.\nWhat This Talk Covers # This talk shows why companies must shift from project-oriented thinking to product-centric working, how a Continuous Delivery Pipeline works as the backbone of modern product development, and why quality, testing, and operability must be considered from the start.\n","title":"DevOps: How Companies Continuously Deliver Value","type":"speaking"},{"content":"","date":"19. October 2022","externalUrl":null,"permalink":"/de/tags/agiles-testing/","section":"Tags","summary":"","title":"Agiles Testing","type":"tags"},{"content":"In diesem Konferenzvortrag bespreche ich eines der grundlegendsten Themen in DevOps: das Denken in Systemen und Wertströmen. Wenn ich mit Unternehmen an ihren DevOps-Transformationen arbeite, sehe ich immer wieder dieselben Muster. Das Business hat tolle Ideen. Diese werden in Word-Dokumente und Jira-Tickets geschrieben. Dann werden sie über die Mauer der Verwirrung zum Entwicklungsteam geworfen. Das Entwicklungsteam baut etwas und wirft es zum Testing. Das Testing vergleicht die Spezifikation mit dem Gebauten (was nie ganz übereinstimmt), testet etwas und wirft es zum Betrieb. Der Betrieb fragt: \u0026ldquo;Wie sollen wir das betreiben?\u0026rdquo; Und irgendwie, mit grossem Aufwand, bringen sie es zum Laufen. Dann sieht der Kunde das Ergebnis und sagt: \u0026ldquo;Was ist das? Das haben wir nicht bestellt.\u0026rdquo;\nVon Projekten zu Produkten # Die Wurzel des Problems liegt oft darin, wie Organisationen über Arbeit denken. Früher machten wir alle Waterfall: Scope war fix, Budget war fix, Zeit war fix. Dann kamen wir zu Agile und arbeiteten inkrementell. Aber in vielen Organisationen arbeiten wir immer noch in Projekten, nur eben inkrementell. Was wir tun sollten, ist in Produkten arbeiten, denn das ist es, was unsere Kunden wirklich wollen.\nDer Unterschied ist fundamental. Projekte fokussieren auf Output: die Anzahl gelieferter Features, User Stories, Tasks oder Codezeilen maximieren. Produkte fokussieren auf Outcome: das Kundenbedürfnis verstehen, das echte Problem lösen, Verhalten verändern und Wert liefern. Der eine Ansatz zählt, was geliefert wird. Der andere misst, ob es einen Unterschied gemacht hat.\nDevOps hilft uns bei diesem Wechsel. DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das Kommunikation, Integration, Automatisierung und enge Zusammenarbeit über den gesamten Wertstrom ermöglicht.\nDevOps ist für alle # Der Begriff \u0026ldquo;DevOps\u0026rdquo; ist völlig irreführend. Man denkt, es geht um Development und Operations. Manche versuchen es zu korrigieren: \u0026ldquo;DevSecOps\u0026rdquo; (mit Security) oder \u0026ldquo;BizDevOps\u0026rdquo; (mit Business). Aber all diese Begriffe schliessen jemanden aus. Was wir eigentlich bräuchten, ist so etwas wie \u0026ldquo;DevSecBizArcCompQAOps.\u0026rdquo; Oder wir nennen es einfach DevOps, denn DevOps bedeutet, alle Menschen, alle Prozesse und alle Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. Das ist DevOps.\nWarum ist das wichtig? Im Jahr 2000 begannen kleine Firmen mit lustigen Namen wie Netflix und Google, mit Agile und DevOps zu experimentieren. Heute dominieren sie den Markt. Dasselbe passiert gerade in der Hardware-Branche. Tesla experimentiert mit DevOps und agilen Arbeitsweisen, und die Auswirkungen sind enorm.\nEin konkretes Beispiel von Elon Musk: Im Oktober 2021 veröffentlichte er ein Autopilot-Update an 1.000 Autobesitzer mit perfektem Safety Score. Das ist ein Canary Release für Autos. Acht Tage später, nach positiven Ergebnissen, erweiterte er die Gruppe. Dann wurde ein Problem gefunden, und er machte einen Rollback. Das sind Autos auf der Strasse, und er macht einen Software-Rollback. Viele Unternehmen schaffen das nicht einmal mit normaler Software. Keine 24 Stunden später war der Fix deployed. So sieht DevOps in der Praxis aus.\nValue Stream Mapping # Bevor man das System verbessern kann, muss man das ganze System sehen. Value Stream Mapping ist eine einfache und wirkungsvolle Technik. Man bringt alle Personen, die in einem Wertstrom arbeiten, in einen Raum, gibt ihnen Post-its und fragt: Welche Schritte braucht es von der Idee bis zur Produktion?\nFür jeden Schritt identifiziert man die Verantwortlichen und misst drei Dinge:\nLead Time: Die Gesamtzeit vom Ende eines Prozessschritts bis zum Ende des nächsten, inklusive aller Wartezeiten. Process Time: Die tatsächliche wertschöpfende Arbeitszeit innerhalb eines Schritts. Percentage Complete and Accurate (%C\u0026amp;A): Wie oft der Output eines Schritts vom nächsten Schritt ohne Nacharbeit genutzt werden kann. Die Ergebnisse sind oft augenöffnend. Zum Beispiel könnte ein Testing-Schritt 8 Stunden tatsächliche Arbeit zeigen, aber 336 Stunden Lead Time, was massive Wartezeiten offenbart. Wenn der Code-Schritt nur 60% C\u0026amp;A zeigt, bedeutet das, dass in 40% der Fälle Arbeit zurückgehen muss. Diese Engpässe werden sichtbar, und Teams können systematisch daran arbeiten, sie zu beseitigen.\nDie Continuous Delivery Pipeline # Dieser Wertstrom ist nichts anderes als eine Continuous Delivery Pipeline. Um sie zu verstehen, müssen wir die Begriffe klären:\nContinuous Integration (CI): Entwickler schreiben Code auf ihren Maschinen und committen in ein Source-Code-Repository. Der CI-Server baut den Code, führt statische Analyse, Security-Checks und Unit Tests durch. Das Feedback muss den Entwickler in Minuten erreichen, nicht in Stunden oder Tagen. Das Ergebnis ist ein deploybares Artefakt.\nContinuous Delivery (CD): Das deploybare Artefakt wird automatisch in eine Staging-Umgebung (eine produktionsnahe Umgebung) installiert, wo weitere Tests ausgeführt werden. Das Feedback geht wieder an den Entwickler.\nContinuous Deployment: Alles von CI und CD geschieht automatisch, und wenn alle Tests bestanden sind, wird das Artefakt automatisch in die Produktion deployed. Die meisten Unternehmen machen CI und CD. Sehr wenige machen Continuous Deployment. Das ist völlig in Ordnung.\nShift Left: Qualität einbauen # Im traditionellen V-Modell wurden Tests mit verzögerten Feedback-Zyklen von drei bis sechs Monaten geschrieben und ausgeführt. Im agilen Umfeld machen wir Shift Left. Wir nutzen Behavior Driven Development (BDD), um Akzeptanzkriterien im Given-When-Then-Format zu schreiben und so ausführbare Spezifikationen zu erstellen. Wir nutzen Test Driven Development (TDD) als Test-First-Ansatz. Durch testbare Spezifikationen von Anfang an schreiben wir Tests vor dem Code und erkennen Probleme sofort.\nAuch die Testpyramide verändert sich. Der traditionelle Ansatz versuchte, alle Bugs mit vielen End-to-End-Tests (oft manuell), einigen Integrationstests und wenigen Unit Tests zu finden. Der agile Ansatz will Bugs verhindern: viele schnelle Unit Tests, einige Integrationstests und nur wenige End-to-End-Tests. Es ist ein fundamentaler Wechsel vom Finden zum Verhindern von Bugs.\nArchitektur für den Betrieb # Etwas, das ich viel zu oft sehe: Teams bauen Dinge, ohne darüber nachzudenken, wie sie in der Produktion funktionieren. You build it, you run it, and when it breaks, you fix it, als ganzes Team. Dafür braucht man Monitoring mit Toleranzschwellen und Alerting, eine klare Benachrichtigungsstrategie und geübte Disaster-Recovery-Verfahren. Kein Word-Dokument, das veraltet ist, wenn die Katastrophe eintritt. Tatsächlich geübte Verfahren.\nTeamübergreifende Zusammenarbeit ist essenziell. Alle sind verantwortlich für ein grossartiges Produkt. Und Incident Post-Mortems sind unschätzbar wertvoll für die kontinuierliche Verbesserung. Infrastructure as Code, Full-Stack-Telemetrie (inklusive Infrastruktur, nicht nur Anwendung), Feature-Nutzungsmetriken zur Unterstützung von Geschäftsentscheidungen: all das wird gebraucht.\n\u0026ldquo;Das grösste Hindernis bei DevOps-Transformationen? Das mittlere Management. Sie wollen die Transformation nicht, weil sie ihre Silos aufbricht und sie einen Teil ihrer Macht verlieren.\u0026rdquo;\nKernaussagen # Von Projekten zu Produkten wechseln. Auf Outcomes (gelöste Kundenprobleme) fokussieren statt auf Outputs (gelieferte Features). Ganzheitliches Systemdenken anwenden. Alle im Wertstrom brauchen eine klare Sicht auf den gesamten Fluss, nicht nur auf ihren Teil. Den Wertstrom visualisieren. Alle Schritte von der Idee bis zur Produktion identifizieren, Lead Time, Process Time und Qualität messen und Engpässe systematisch beseitigen. Die Continuous Delivery Pipeline automatisieren. CI/CD ist die Automatisierung des Wertstroms. Qualität von Anfang an einbauen mit BDD und TDD. Für den Betrieb architekturieren. Von Tag eins an die Produktion denken. Telemetrie einbauen, Disaster Recovery üben und Post-Mortems für kontinuierliche Verbesserung nutzen. DevOps ist für alle. Es geht nicht um Dev und Ops. Es geht darum, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. ","date":"19. October 2022","externalUrl":null,"permalink":"/de/blogs/devops-denken-in-systemen-und-wertstroemen/","section":"Blogs","summary":"In diesem Konferenzvortrag bespreche ich eines der grundlegendsten Themen in DevOps: das Denken in Systemen und Wertströmen. Wenn ich mit Unternehmen an ihren DevOps-Transformationen arbeite, sehe ich immer wieder dieselben Muster. Das Business hat tolle Ideen. Diese werden in Word-Dokumente und Jira-Tickets geschrieben. Dann werden sie über die Mauer der Verwirrung zum Entwicklungsteam geworfen. Das Entwicklungsteam baut etwas und wirft es zum Testing. Das Testing vergleicht die Spezifikation mit dem Gebauten (was nie ganz übereinstimmt), testet etwas und wirft es zum Betrieb. Der Betrieb fragt: “Wie sollen wir das betreiben?” Und irgendwie, mit grossem Aufwand, bringen sie es zum Laufen. Dann sieht der Kunde das Ergebnis und sagt: “Was ist das? Das haben wir nicht bestellt.”\n","title":"DevOps: Denken in Systemen und Wertströmen","type":"blogs"},{"content":"In this conference talk, I discuss one of the most fundamental topics in DevOps: thinking in systems and value streams. When I work with companies on their DevOps transformations, I consistently see the same patterns. The business has bright ideas. They write them into Word documents and Jira tickets. They throw them over a wall of confusion to development. Development builds something and throws it to testing. Testing compares what was specified with what was built (never quite the same), tests something, and throws it to operations. Operations asks \u0026ldquo;How can we operate that?\u0026rdquo; and somehow, with great effort, they get it running. Then the customer sees it and says: \u0026ldquo;What is that? That is not what we ordered.\u0026rdquo;\nFrom Projects to Products # The root of the problem is often found in how organizations think about work. In the past, we all did waterfall: scope was fixed, budget was fixed, time was fixed. Then we moved to agile and started working incrementally. But in many organizations, we are still working in projects, just incrementally. What we should be doing is working in products, because that is what our customers actually want.\nThe difference is fundamental. Projects focus on output: maximizing the number of features, user stories, tasks, or lines of code delivered. Products focus on outcome: understanding the customer need, solving the real problem, changing behavior, and delivering value. One approach counts what you ship. The other measures whether it made a difference.\nDevOps helps us make this shift. DevOps is a mindset, a culture, and a set of technical practices that provides communication, integration, automation, and close collaboration across the entire value stream.\nDevOps is for Everyone # The term \u0026ldquo;DevOps\u0026rdquo; is completely misleading. People think it is about Development and Operations. Some try to fix it by saying \u0026ldquo;DevSecOps\u0026rdquo; (adding Security) or \u0026ldquo;BizDevOps\u0026rdquo; (adding Business). But all of these exclude someone. What we really need is something like \u0026ldquo;DevSecBizArcCompQAOps.\u0026rdquo; Or we can just call it DevOps, because DevOps is about bringing all people, all processes, and all technology together to continuously deliver value. That is what DevOps is.\nWhy does this matter? In the year 2000, small companies with funny names like Netflix and Google started experimenting with agile and DevOps. Today they dominate the market. We are seeing the same happening in hardware. Tesla is experimenting with DevOps and agile ways of working, and the impact is massive.\nConsider this real example from Elon Musk: in October 2021, he released an Autopilot update to 1,000 car owners with a perfect safety score. That is a canary release for cars. Eight days later, after positive results, he expanded to a larger group. Then a problem was found, and he did a rollback. These are cars driving on roads, and he is doing a software rollback. Many companies cannot do that with normal software. Not even 24 hours later, the fix was deployed. This is what DevOps in action looks like.\nValue Stream Mapping # Before you can improve your system, you need to see the whole system. Value stream mapping is a straightforward and powerful technique. You bring all the people working in a value stream into a room, give them Post-its, and ask: what steps are needed from idea to production?\nFor each step, you identify who is responsible and measure three things:\nLead Time: The total time from the end of one process step to the end of the next, including all waiting. Process Time: The actual value-adding work time within a step. Percentage Complete and Accurate (%C\u0026amp;A): How often the output of one step can be used by the next step without any rework. The results are often eye-opening. For example, a testing step might have 8 hours of actual work but 336 hours of lead time, revealing massive waiting time. When the code step shows only 60% C\u0026amp;A, that means in 40% of cases, work needs to go back. These bottlenecks become visible, and teams can work systematically to remove them.\nThe Continuous Delivery Pipeline # This value stream is nothing else than a continuous delivery pipeline. To understand it, we need to be clear on the terminology:\nContinuous Integration (CI): Developers write code on their machines and commit to a source code repository. The CI server builds the code, runs static analysis, security checks, and unit tests. Feedback must reach the developer in minutes, not hours or days. The output is a deployable artifact.\nContinuous Delivery (CD): The deployable artifact is automatically installed in a staging environment (a production-like environment), where further tests are executed. Feedback is again given to the developer.\nContinuous Deployment: Everything from CI and CD happens automatically, and if all tests pass, the artifact is deployed to production automatically. Most companies do CI and CD. Very few do continuous deployment. That is perfectly fine.\nShift Left: Building Quality In # In the traditional V-model, tests were written and executed with delayed feedback cycles of three to six months. In agile, we shift left. We use Behavior Driven Development (BDD) to write acceptance criteria in Given-When-Then format, creating executable specifications. We use Test Driven Development (TDD) as a test-first approach. By having specifications in testable format from the start, we write tests before code and catch problems immediately.\nThe testing pyramid also changes. The traditional approach tried to find all bugs with many end-to-end tests (often manual), some integration tests, and few unit tests. The agile approach is about preventing bugs: many fast unit tests, some integration tests, and only a few end-to-end tests. It is a fundamental shift from finding bugs to preventing them.\nArchitect for Operability # Something I see too often: teams build things without thinking about how they will work in production. You build it, you run it, and when it breaks, you fix it as a team. For that, you need monitoring with tolerance thresholds and alerting, a clear notification strategy, and practiced disaster recovery procedures. Not a Word document that is outdated when disaster strikes. Actual practiced procedures.\nCross-team collaboration is essential. Everyone is responsible for a great product. And incident post-mortems are invaluable for continuous improvement. Infrastructure as code, full-stack telemetry (including infrastructure, not just application), feature usage metrics to support business decisions: all of these are needed.\n\u0026ldquo;The biggest obstacle in DevOps transformations? The middle management. They do not want the transformation because it breaks down their silos and they lose some of their power.\u0026rdquo;\nKey Takeaways # Move from projects to products. Focus on outcomes (customer problems solved) rather than outputs (features shipped). Apply whole-system thinking. Everyone in the value stream needs a clear view of the entire flow, not just their piece. Map your value stream. Identify all steps from idea to production, measure lead time, process time, and quality, and systematically remove bottlenecks. Automate your continuous delivery pipeline. CI/CD is the automation of your value stream. Build quality in from the start with BDD and TDD. Architect for operability. Think about production from day one. Build in telemetry, practice disaster recovery, and use post-mortems to continuously improve. DevOps is for everyone. It is not about Dev and Ops. It is about bringing all people, processes, and technology together to continuously deliver value. ","date":"19 October 2022","externalUrl":null,"permalink":"/en/blogs/devops-thinking-in-systems-and-value-streams/","section":"Blogs","summary":"In this conference talk, I discuss one of the most fundamental topics in DevOps: thinking in systems and value streams. When I work with companies on their DevOps transformations, I consistently see the same patterns. The business has bright ideas. They write them into Word documents and Jira tickets. They throw them over a wall of confusion to development. Development builds something and throws it to testing. Testing compares what was specified with what was built (never quite the same), tests something, and throws it to operations. Operations asks “How can we operate that?” and somehow, with great effort, they get it running. Then the customer sees it and says: “What is that? That is not what we ordered.”\n","title":"DevOps: Thinking in Systems and Value Streams","type":"blogs"},{"content":"After eight sessions of adding scanners to our GitLab pipeline — SAST, secret detection, SCA, license compliance, container scanning, DAST — we now have a different problem. We have hundreds of vulnerability findings. In Part 9, Patrick Steger and I look at GitLab\u0026rsquo;s built-in Vulnerability Management: what it gives you, where it falls short, and how to actually triage findings without losing your mind.\nWhat GitLab\u0026rsquo;s Vulnerability Management Gives You # GitLab Ultimate ships a Vulnerability Management module that aggregates findings from every scanner we wired into the pipeline. There are two main views. The security dashboard shows the number of vulnerabilities and how they develop over time. The vulnerability report lets you view and track individual findings.\nOne important detail: both views always reflect your default branch. In our project that is master. Vulnerabilities found on feature branches are not what you see here — only what hits the default branch counts.\nIn our sample Java project the report lists 165 vulnerabilities: 35 critical, 70 high, 48 medium, 11 low, and one unknown. You can filter by tool (SAST, dependency scanning, DAST, container scanning, secret detection) and by severity. Open a finding and you get an extended description — for example, a container scanning finding pointing at an SSL library, or a critical secret detection finding showing the exact line where an AWS access token landed in the source code.\nFrom a finding you can do three things that matter: create an issue in GitLab\u0026rsquo;s issue tracker, mark it as fixed, or dismiss it. When you re-run the pipeline after a fix, GitLab even detects findings that are no longer reported by the scanners and marks them as potentially fixed, which you can then confirm as resolved.\nThe Limitations You Need to Plan Around # The tool is a good starting point, but Patrick lists the limitations clearly, and they matter for any serious security process.\nNo comment on dismissals. When you dismiss a finding, you cannot say why. Six months later nobody knows whether it was a false positive, an accepted risk, or a misclick.\nNo time-boxed dismissal. You cannot say \u0026ldquo;accept this risk for six months and re-review.\u0026rdquo; It is dismissed or it is not.\nDismissal does not distinguish between false positive and accepted risk. Both end up in the same bucket. From a governance perspective those are very different things.\nStrict format for third-party tools. You can integrate other scanners, but they must produce reports in the format GitLab expects. We would prefer the Vulnerability Management to be flexible enough to adapt to multiple formats — instead it is the tools that have to adapt.\nManual entries are clumsy. When you want to add a finding from a manual penetration test, GitLab demands fields like a CVE ID and an identifier URL — fields that simply do not exist for a manual finding. The workaround is to enter dummy values, which then live forever in the report. The information you can attach is also very limited.\nFindings drift when source code changes. Patrick saw cases where, after a code change, the existing finding no longer pointed to the right line.\nTriage Workflow in Practice # In the demo we walked through the typical lifecycle. Most findings start as Needs Triage. Investigate one: if it is real, set it to Confirmed, then create an issue from the finding so a developer picks it up. The issue and the vulnerability are linked both ways, so you can navigate from finding to issue and back. If it is not real, Dismiss it — and accept that you cannot record why.\nFor a manual entry we tried \u0026ldquo;cross-site scripting from a penetration test.\u0026rdquo; GitLab refused the submission until we filled in an identifier code and URL. We added placeholder values, submitted again, and then filtered the report by tool = \u0026ldquo;manually added\u0026rdquo; to see it.\nAfter fixing a batch of findings — in our case, bumping Spring Boot from version 2 to 2.7.2 and updating the test framework accordingly — we re-ran the pipeline. Filtering the vulnerability report by activity = no longer detected showed a long list of issues the scanners no longer find. We bulk-set them to Resolved. Same shortcoming as dismissal: no place to record context.\nCreating an issue is also the practical workaround for the missing comment field. The issue gives you a place to write down what you actually did, which the vulnerability record itself does not offer.\nKey Takeaways # Vulnerability Management is part of the pipeline, not an afterthought. Once you have five or six scanners running on every commit, you need a place to triage their output. Without it, the scanners produce noise that nobody acts on.\nThe default-branch-only view is a real constraint. Findings on feature branches do not show up in the dashboard. Plan your branching model and your security gates around that.\nDismissal without a reason is a governance gap. False positive and accepted risk should not look the same. Until GitLab fixes this, use linked issues to record the reasoning.\nManual findings deserve a first-class workflow. The current path forces you to fake CVE IDs. If you do a lot of manual penetration testing, expect to keep a separate tool alongside GitLab.\nRe-runs detect \u0026ldquo;no longer present\u0026rdquo; findings. Use the activity = no longer detected filter after every fix sweep — it is the fastest way to clean up the report and see real progress.\nIssues are the workaround for everything the report cannot store. Comments, history, attachments, audit trail — all of that lives on the issue, not on the vulnerability. Build that habit early.\n","date":"12 October 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-vulnerability-management/","section":"Blogs","summary":"After eight sessions of adding scanners to our GitLab pipeline — SAST, secret detection, SCA, license compliance, container scanning, DAST — we now have a different problem. We have hundreds of vulnerability findings. In Part 9, Patrick Steger and I look at GitLab’s built-in Vulnerability Management: what it gives you, where it falls short, and how to actually triage findings without losing your mind.\n","title":"GitLab DevSecOps Part 9: Overcoming Vulnerability Management Challenges","type":"blogs"},{"content":"","date":"12 October 2022","externalUrl":null,"permalink":"/en/tags/security-dashboard/","section":"Tags","summary":"","title":"Security Dashboard","type":"tags"},{"content":"","date":"12 October 2022","externalUrl":null,"permalink":"/en/tags/triage/","section":"Tags","summary":"","title":"Triage","type":"tags"},{"content":"Everything we have done in the GitLab DevSecOps pipeline so far has been static — analysis of source code, dependencies, containers and configuration. In Part 8, Patrick Steger and I cross the line into Continuous Delivery and add Dynamic Application Security Testing. DAST means we deploy the application, start it, and then attack it from the outside with an automated penetration testing tool. GitLab ships this capability out of the box, powered by OWASP ZAP.\nWhat DAST Actually Does # Patrick puts it simply: DAST finds vulnerabilities in your running application — think of it as automated penetration testing. The GitLab default is the OWASP ZAP attack proxy, which probes the live system and looks for issues a static scanner cannot see, such as response headers, misconfigured TLS, or injection points exposed at runtime.\nThere is one important caveat up front. Without explicit, manual configuration, DAST is very basic. If you want findings that move the needle on a real product, you have to invest serious time in tuning OWASP ZAP. We do not do that in this video. The OWASP ZAP project itself has dedicated sessions for that. What we show here is how to wire DAST into the pipeline so it runs on every commit.\nWhy It Lives in Continuous Delivery # DAST cannot run on source code. It needs a deployed, running system. That is why this is the first step that pulls us out of pure CI and into CD. The container we built and scanned in earlier sessions is now started inside the pipeline so OWASP ZAP can attack it.\nDefining the Stages Explicitly # The first surprise is that enabling DAST is not \u0026ldquo;one extra line.\u0026rdquo; The default DAST job from GitLab requires a stage called dast. The moment you define stages explicitly, you have to list all of them, otherwise the existing jobs lose their build, test, and deploy stages. So in .gitlab-ci.yml we add:\nstages: - build - test - deploy - dast build, test, and deploy exist by default, but as soon as you start declaring stages they all need to be there.\nWiring Up the Running Container # Next we set the variable CONTAINER_TEST_IMAGE to point to the container image we built earlier for container scanning. Then in the dast: job we extend services so the container is started for the job and reachable under the alias demoApp.\nThe DAST job expects a DOCKER_IMAGE variable telling it what to test, and we set DAST_WEBSITE to the demoApp service alias so OWASP ZAP knows where to send its requests. To get more useful findings, we also set DAST_FULL_SCAN_ENABLED: \u0026quot;true\u0026quot;. Without that flag, ZAP only does passive observation. With it, ZAP performs active attacks — actually trying to break things, not just watching.\nFinally we include the GitLab-provided DAST template so the job definition itself is pulled in.\nLooking at the Results # When the pipeline runs, the new stage shows up. In the job log you see the service container starting first — that is the application under test. Then the ZAP server starts, performs its scan, and reports the findings. In our small Java application it found two warnings.\nThe findings show up in two places. First, directly on the pipeline view under the Security tab — the summary shows two new vulnerabilities and you can filter by DAST. Second, in Security and Compliance under the Vulnerability Report, again filterable by tool. The two findings we got are very basic, for example that HTTPS is not enabled. As mentioned, real findings require real ZAP configuration — but the integration itself works exactly as it should, and that is the point of this session.\nRecap # We added the new dast stage and re-declared the default stages alongside it. We included the GitLab DAST template, configured the endpoint where DAST finds the application, enabled full scan so ZAP actively attacks, and extended the DAST job with a service so the container is reachable. Five small pieces, and DAST runs on every commit.\nThe full DevSecOps toolset for our pipeline is now in place. In the next session we will look at the integrated Vulnerability Management capabilities of GitLab and how all these findings come together.\nKey Takeaways # DAST tests the running system, not the code. This is the moment where the pipeline crosses from CI into CD. Without a deployed, running container there is nothing for OWASP ZAP to attack.\nOut-of-the-box DAST is basic on purpose. Treat the default GitLab DAST job as the integration scaffolding. Real, high-value findings require dedicated time tuning OWASP ZAP — that is a project of its own.\nExplicit stages mean all stages. As soon as you declare a dast stage, you also have to declare build, test, and deploy, otherwise the existing jobs break. Easy to miss, easy to debug.\nUse a service to host the application under test. The container built earlier is started as a service under an alias and pointed at via DAST_WEBSITE. Same image, same artifact — no separate deployment dance.\nEnable full scan or you are only watching. Without DAST_FULL_SCAN_ENABLED: \u0026quot;true\u0026quot;, OWASP ZAP only observes traffic passively. With it, ZAP actively attacks the application, which is what you want from a penetration test.\nFindings flow into the same security dashboard. DAST results land in the pipeline Security tab and the project-wide Vulnerability Report alongside SAST, SCA, secret detection and container scanning. One place to triage everything.\n","date":"5 October 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-dast/","section":"Blogs","summary":"Everything we have done in the GitLab DevSecOps pipeline so far has been static — analysis of source code, dependencies, containers and configuration. In Part 8, Patrick Steger and I cross the line into Continuous Delivery and add Dynamic Application Security Testing. DAST means we deploy the application, start it, and then attack it from the outside with an automated penetration testing tool. GitLab ships this capability out of the box, powered by OWASP ZAP.\n","title":"GitLab DevSecOps Part 8: Dynamic Application Security Testing (DAST)","type":"blogs"},{"content":"","date":"28 September 2022","externalUrl":null,"permalink":"/en/tags/gitlab-ci/","section":"Tags","summary":"","title":"GitLab CI","type":"tags"},{"content":"Hard-coded passwords and API keys are still one of the most common ways credentials leak. They get committed by accident, stay in the git history forever, and only show up when someone is already exploiting them. In Part 7 of our GitLab DevSecOps series, Patrick Steger and I add Secret Detection to the same pipeline we have been growing — one line of YAML — and then look at what GitLeaks actually finds, what it quietly misses, and what to do about it.\nWhat Secret Detection Is For # Secret Detection scans every source and configuration file you committed to the Git repository and looks for things that should not be in source control: passwords, API keys, tokens — anything you would consider confidential. If it finds one, you do not \u0026ldquo;fix\u0026rdquo; it by editing the file. The secret is compromised the moment it lands in the repo, so the only real remediation is to revoke it everywhere it is used and rotate it. The GitLab implementation is built on the open-source GitLeaks project.\nPatrick makes the obvious follow-up: if secrets do not belong in source code, where do they belong? In an external secret store. GitLab supports HashiCorp Vault for this — but you have to host and manage Vault yourself. GitLab does not currently provide an integrated, secure place to store secrets.\nOne Line of YAML # Adding Secret Detection to the pipeline is the same pattern we used for the previous tools: include the GitLab template. We open .gitlab-ci.yml in the web editor and add the Secret-Detection.gitlab-ci.yml template. Commit, and GitLab kicks off the pipeline. Everything stays green and a new secret_detection job appears in the pipeline view.\n\u0026ldquo;It Did Not Find Anything\u0026rdquo; # The first run of the GitLeaks tool reports zero leaks. That is suspicious, because in the previous SAST session we had deliberately added hard-coded passwords on lines 19 and 20 of the controller. We expected those to show up.\nThey did not. Looking at the GitLeaks pattern file, the regex for \u0026ldquo;password\u0026rdquo; is very specific — it only matches lowercase letters, for example. Whether that is a bug or by design, the consequence is that ordinary password literals in code do not get detected.\nSo if Secret Detection misses obvious passwords, why bother? Because SAST already catches them — when we go into the Vulnerability Report and filter by the SAST tool, the same hard-coded password is right there. Secret Detection and SAST overlap, and that is fine. They cover different patterns.\nWhat Secret Detection Is Actually Good At # The real value of Secret Detection is the curated list of well-known secret formats: AWS access tokens, cloud provider keys, and dozens of other tokens with predictable structure. To prove it, I add an AWS-style access key to the controller and commit. The pipeline runs, the secret_detection job opens, and the finding is right there: an AWS access token that should be revoked.\nYou can see the same finding in two places in the GitLab UI: the Security tab on the pipeline run (filter by Secret Detection) and the Security \u0026amp; Compliance → Vulnerability Report. The report tells you exactly which file and line — in this case, line 22 — and that the access key was detected.\nWhy It Reports the ID, Not the Secret Value # Patrick points out something subtle: the tool reports the AWS access key ID, not the secret value next to it. That is because the ID has a well-defined structure GitLeaks can match. The secret value itself is random — there is no pattern to match against. So GitLeaks flags the ID as a marker that a credential is probably nearby, and leaves you to decide whether the value is also exposed or being pulled in safely from a vault.\nThis is also why Secret Detection generates false positives. If your code retrieves a credential securely from Vault but the variable name or surrounding code matches a known pattern, GitLeaks will still flag it. Plan for that — a real Secret Detection workflow includes triaging findings, marking false positives, and tracking the genuine ones in the vulnerability management process. We will get to that workflow in a later session.\nKey Takeaways # One line of YAML enables Secret Detection. Including Secret-Detection.gitlab-ci.yml is all it takes. The cost of turning it on is essentially zero — there is no excuse not to.\nGitLeaks is pattern-based, and the patterns are conservative. Hard-coded passwords in your own code can slip past it. Do not rely on Secret Detection alone — make sure SAST is running so you have overlapping coverage.\nSecret Detection is best at well-known token formats. AWS access keys, cloud provider tokens, structured credentials — anything with a predictable shape. That is where the tool earns its keep.\nA detected secret is a compromised secret. You do not patch it out of the file. You revoke it in the system it belongs to and rotate it everywhere. Build that response into your process before the first finding lands.\nGitLab gives you the scanner, not the vault. Secrets belong in an external store like HashiCorp Vault. GitLab supports Vault, but you host and operate it. There is no built-in secure secret store yet.\nExpect false positives — plan the triage. Pattern matching flags anything that looks like a credential, including legitimate references to vault-stored secrets. Define how findings get reviewed, marked, and managed before you turn it on at scale.\n","date":"28 September 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-secret-detection/","section":"Blogs","summary":"Hard-coded passwords and API keys are still one of the most common ways credentials leak. They get committed by accident, stay in the git history forever, and only show up when someone is already exploiting them. In Part 7 of our GitLab DevSecOps series, Patrick Steger and I add Secret Detection to the same pipeline we have been growing — one line of YAML — and then look at what GitLeaks actually finds, what it quietly misses, and what to do about it.\n","title":"GitLab DevSecOps Part 7: Finding Secrets in Your Code with Secret Detection","type":"blogs"},{"content":"","date":"28 September 2022","externalUrl":null,"permalink":"/en/tags/gitleaks/","section":"Tags","summary":"","title":"GitLeaks","type":"tags"},{"content":"","date":"28 September 2022","externalUrl":null,"permalink":"/en/tags/secret-detection/","section":"Tags","summary":"","title":"Secret Detection","type":"tags"},{"content":"We have already wired SAST, secret detection, and software composition analysis into the GitLab pipeline. Those checks cover the source code and its dependencies — but the artifact we actually ship is a container image. Operating system packages, the base image, and everything copied in along the way can carry vulnerabilities of their own. In Part 6 of our series, Patrick Steger and I add container scanning to the pipeline, build a Docker image from the jar we compiled earlier, and push it through Trivy and Grype.\nWhat Container Scanning Does # Container scanning looks for known vulnerabilities inside your container image. It scans every file in the image — OS packages, libraries, the application binaries — against vulnerability databases. GitLab uses two open source tools under the hood: Trivy and Grype. The feature is part of GitLab Ultimate, and it works for Linux images only; Windows containers are not supported yet.\nA heads-up Patrick raises early: container scanning will overlap with the SCA results we already produced. If you have an Ultimate license, GitLab can filter those duplicates out for you. Without Ultimate, expect to see the same library show up in both reports.\nEnabling the Job # As with the previous stages, the scanning job itself is one include line. We pull Container-Scanning.gitlab-ci.yml from GitLab\u0026rsquo;s templates and add it to the existing list of imports. The catch this time is that the job needs an actual image to scan — and we do not have one yet.\nBuilding the Image First # Before container scanning can run, we have to produce a container. We start from the Dockerfile that came with the project template, but we change it. The original ran mvn package inside the image and rebuilt the whole application from scratch. That is wasteful — we already compiled the jar in the build job earlier in the pipeline. So we strip the Maven step out and use COPY target to pull the prebuilt jar into the image. The last entry in the Dockerfile runs that jar. The base image is JDK 13.\nThen we extend the pipeline with a build_image job. We define a variable CONTAINER_TEST_IMAGE for the image name in the GitLab registry, log in to Docker, build the image, and push it. Because we need the compiled jar, we add a needs: statement at the bottom that makes build_image depend on the earlier build job. Without it, the COPY target line would have nothing to copy.\nTo run Docker commands inside a GitLab job, we need Docker available. We add docker:dind (Docker-in-Docker) as a service in the services: section of build_image. That makes the Docker tooling available inside the runner.\nFinally, we point the container scanning job at the image we just built. The template exposes a predefined variable called DOCKER_IMAGE — we set it to CONTAINER_TEST_IMAGE in the global variables section. That tells the scanner exactly which image to pull from the registry and analyse.\nSo Many Images # It is worth pausing to count Docker images at this point. Each build job runs inside its own image. Now we have created a new image that holds our application. And that new application image is the one container scanning will analyse. Three different roles for \u0026ldquo;Docker image\u0026rdquo;, and the pipeline has them all.\nFindings — and a Green Pipeline # The pipeline runs. The container scanning job goes green. Then we open it and find vulnerabilities. Why is the pipeline not red?\nGitLab considers a job successful if it finished its work — in this case, \u0026ldquo;I scanned the image and produced a report.\u0026rdquo; Findings on their own do not break the pipeline. From a pure security standpoint Patrick would prefer a hard fail on any finding, but in practice you almost always have at least one CVE somewhere, and a pipeline that is permanently red is a pipeline nobody trusts. A reasonable middle ground would be failing only on high or critical severity, but GitLab does not currently offer that switch out of the box. The remediation Patrick points to is merge request approval rules — we can require sign-off from specific reviewers when a change introduces new vulnerabilities. We will dig into that in a later session.\nYou can review the findings in two places. First, the Security tab on the pipeline run, filtered by tool — pick \u0026ldquo;Container Scanning\u0026rdquo;. Second, in Security \u0026amp; Compliance → Vulnerability Report in the project\u0026rsquo;s governance area, again filterable by tool.\nKey Takeaways # Container scanning checks the artifact you actually ship. SAST and SCA cover source and dependencies. Container scanning covers the image: OS packages, base image, copied binaries. Skip it and you ship blind.\nReuse the build, do not rebuild in the Dockerfile. Drop mvn package from the Dockerfile and COPY target the jar that the pipeline already produced. Anything else duplicates work and fragments the artifact you tested.\nWire dependencies explicitly with needs:. Container scanning needs an image. The image-build job needs the compiled jar. State those dependencies in the YAML or the order will surprise you.\nDocker-in-Docker is the price of building images in CI. Add docker:dind as a service on the build_image job. Without it, the Docker CLI inside the runner has nothing to talk to.\nA green pipeline with vulnerabilities is by design. GitLab marks the job successful if the scan ran. Severity-based pipeline failure is not built in. Use merge request approval rules to keep new findings from sneaking in.\nExpect overlap with SCA — and have a plan. Container scanning will rediscover application-library CVEs that SCA already flagged. Ultimate filters duplicates; without Ultimate, agree upfront on which report owns which finding so the team is not arguing in two places.\n","date":"6 September 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-container-scanning/","section":"Blogs","summary":"We have already wired SAST, secret detection, and software composition analysis into the GitLab pipeline. Those checks cover the source code and its dependencies — but the artifact we actually ship is a container image. Operating system packages, the base image, and everything copied in along the way can carry vulnerabilities of their own. In Part 6 of our series, Patrick Steger and I add container scanning to the pipeline, build a Docker image from the jar we compiled earlier, and push it through Trivy and Grype.\n","title":"GitLab DevSecOps Part 6: How to Use Container Scanning","type":"blogs"},{"content":"Software composition analysis takes care of the libraries you pull in. But what about the code your own team writes? That is where Static Application Security Testing comes in. In Part 5 of our GitLab DevSecOps series, Patrick Steger and I add SAST to the pipeline, plant a few realistic vulnerabilities in our Spring Boot sample, and watch GitLab pick them up.\nWhat SAST Actually Does # SAST scans your source code for security vulnerabilities without running the application. Patrick gives the classic example: cryptography. If you reach for a weak cipher, or use the regular Random class to generate something that should be unpredictable, that is a security flaw — and it is the kind of thing a static analyzer can spot by reading the code.\nGitLab\u0026rsquo;s SAST primarily uses Semgrep, an open-source pattern-based scanner. Depending on the language, it may pull in additional tools too. For our Java sample, Semgrep is paired with SpotBugs. Each tool has its own strengths and weaknesses; combining them widens coverage.\nWiring SAST into the Pipeline # The mechanic is the same as everything else we have added so far. We open .gitlab-ci.yml, add one include line that references GitLab\u0026rsquo;s managed SAST.gitlab-ci.yml template, commit to master, and the pipeline takes it from there.\nBefore we add the line, Patrick simplifies the Spring Boot main app and drops in a new controller with deliberate problems. The one we expect SAST to flag sits on line 47: an insecure java.util.Random used where SecureRandom belongs. A predictable pseudorandom generator wherever cryptographic keys or tokens are involved is exactly the kind of finding SAST is supposed to surface.\nTwo Tools Under the Hood # Open the managed template and search for Java, and you see GitLab orchestrates two scanners: Semgrep and SpotBugs. The pipeline grows two new jobs accordingly — semgrep-sast and spotbugs-sast. Click into either one and the log shows the same recipe we have seen before: pull a Docker image, run the scanner, upload findings to GitLab\u0026rsquo;s vulnerability system.\nThe job logs themselves are not where you read the results. They are noisy and not designed for humans. The real surface is the Security tab on the pipeline, with a SAST filter. There, our predictable pseudorandom finding shows up exactly where we expected it, with a direct link into the source file at line 47.\nWhere the Findings Live # GitLab gives you two views of vulnerabilities. The pipeline\u0026rsquo;s Security tab shows what this run found. The Security \u0026amp; Compliance → Vulnerability Report under the project gives you the governance view — everything across pipelines, with filters and triage. That governance view requires the Ultimate edition. Running the SAST scanners themselves is part of the free license. Worth knowing before anyone signs a contract based on screenshots.\nWhat This Buys You # One include line gave us two scanners, two new pipeline jobs, automatic vulnerability uploads, and a clean UI to triage findings. Compared to wiring this together by hand on another platform, that is genuinely cheap. The trade-off is that you accept GitLab\u0026rsquo;s choices about which tools to run and which rules to enable. For most teams, that is the right trade — start with the managed template, and only invest in custom rules or extra scanners once you can prove the defaults are missing things you care about.\nKey Takeaways # SAST scans code you wrote, not dependencies. SCA covers third-party libraries; SAST is about your own source. Both belong in CI, and they answer different questions.\nOne include line buys two scanners. GitLab\u0026rsquo;s managed SAST.gitlab-ci.yml template wires up Semgrep plus, for Java, SpotBugs. You do not have to choose tools, install them, or maintain Docker images.\nCombining scanners improves coverage. Each tool has different strengths. Running Semgrep and SpotBugs together catches more than either one alone — and you get that for free with the managed template.\nRead findings in the Security tab, not the job log. The pipeline log shows that the scanner ran. The actual vulnerabilities live under the pipeline\u0026rsquo;s Security tab, with deep links into the offending code.\nRandom instead of SecureRandom is exactly the kind of bug SAST catches. Predictable pseudorandom generators used for security-relevant values are a textbook static-analysis finding. If your team writes any cryptographic or auth code, this alone justifies the few minutes it takes to enable SAST.\nScanning is free; governance is Ultimate. The SAST scanners run on the free tier. The cross-pipeline Vulnerability Report under Security \u0026amp; Compliance requires the Ultimate edition. Plan your tier accordingly — do not assume the dashboards in screenshots come with the free plan.\n","date":"31 August 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-sast/","section":"Blogs","summary":"Software composition analysis takes care of the libraries you pull in. But what about the code your own team writes? That is where Static Application Security Testing comes in. In Part 5 of our GitLab DevSecOps series, Patrick Steger and I add SAST to the pipeline, plant a few realistic vulnerabilities in our Spring Boot sample, and watch GitLab pick them up.\n","title":"GitLab DevSecOps Part 5: Static Application Security Testing (SAST)","type":"blogs"},{"content":"You ship a Java application that depends on Spring Boot, which depends on dozens of other libraries, each with its own license — and most teams cannot tell you what those licenses actually are. In Part 4 of our GitLab DevSecOps series, Patrick Steger and I add license compliance to the pipeline so the question is answered automatically on every commit. The good news: with GitLab Ultimate, this is one template line away.\nWhy a Java Project Needs License Compliance # Patrick frames it the same way as software composition analysis. We pull in a long list of libraries to build a simple Spring Boot app, and each one comes with its own license. Some licenses are friendly, some are restrictive, some are downright dangerous for a commercial product. Reading every license by hand is not realistic, and even if you tried once, the dependency graph changes the next time someone bumps a version. You need a tool that tells you what you are using and lets you decide what is acceptable.\nWhat License Compliance Does in GitLab # License compliance is a GitLab Ultimate feature. The job runs through your project\u0026rsquo;s dependencies, derives the license for each one, checks the resulting list against the licenses you have marked as acceptable, and flags anything that is not compliant. Under the hood, GitLab uses the open source License Finder tool. You do not configure the scanner yourself; you configure the policy.\nEnabling It in .gitlab-ci.yml # Enabling the scan is the same pattern we used for the dependency analysis: include the GitLab-provided template in .gitlab-ci.yml. In this case the template is License-Scanning.gitlab-ci.yml. Add the include, commit, and the next pipeline run picks up a new license scanning job. If you want to pin the version of the scanner, copy the template into your own repo and reference it from there — same trick as before.\nThe Maven Bug We Hit # When we first ran it, the job failed on line 41 with LicenseFinder::Maven is not installed. The image GitLab shipped at the time of recording had a bug — Maven was present in the container but not marked as executable. The fix is five lines at the top of the pipeline that mark the Maven binary as executable. With that in place the job runs cleanly. Worth knowing: when a managed scanner suddenly breaks, it is almost never your YAML — check the upstream image first.\nWhere the Results Live # Results show up in two places. Inside the pipeline, the job adds a Licenses tab. At project level, you find the full report under Security \u0026amp; Compliance → License Compliance. On our Spring Boot demo we were surprised to see five distinct licenses — for a project that pulled in Spring Boot and very little else. That visibility alone is worth the setup cost. Most teams have no idea how many licenses they ship with.\nDefining the Policy # In License Compliance → Policies → Add license policy, you mark each license as allowed or denied. We allowed four of the five we found and intentionally left one without a decision so we could see how the pipeline reports it. The next pipeline run flagged exactly that one as \u0026ldquo;not yet acceptable\u0026rdquo; and the four others as approved. The pipeline does not fail on it by default in our setup, but you can wire that in.\nApproval Workflow for New Licenses # GitLab also supports a basic approval workflow for licenses that have not been classified yet. Under approvals you add an approval rule and assign a group as approvers — we added the zuehlke-devsecops group, which at the time meant Patrick and me. From then on, when a merge request introduces a dependency with an unclassified license, the merge request needs an approval from someone in that group before it can be merged. The full effect of this only becomes visible when you start working with feature branches and merge requests, which is a later session, but it is worth setting up now.\nWhat This Buys You # For one line in the pipeline file (plus the temporary Maven fix) you get a full inventory of every license your project depends on, a UI to classify them, an approval workflow for new ones, and a license report on every pipeline run. The whole point of shifting compliance left is exactly this: turning a manual, painful, end-of-project scramble into a check that runs on every commit and surfaces issues while they are still cheap to fix.\nKey Takeaways # You ship more licenses than you think. A bare Spring Boot demo pulled in five distinct licenses. On a real product, expect dozens. Without a scanner, no one on the team can answer the question \u0026ldquo;what licenses are we shipping?\u0026rdquo;\nAdd the template, get the scan. License-Scanning.gitlab-ci.yml is a one-line include. The scanner uses License Finder under the hood; you do not have to wire it up yourself.\nThe policy matters more than the tool. Scanning is the easy part. Deciding which licenses are acceptable for your business — and who is allowed to make that call — is the work that actually has to happen.\nUse the approval workflow. Assign a group as license approvers. New, unclassified licenses then become a conscious decision in a merge request, not something that slips into production unnoticed.\nWatch the upstream image. We hit a Maven-not-executable bug in the GitLab-provided container. When a managed scanner breaks, suspect the image before you suspect your config.\nCompliance is a CI concern, not a release concern. Running this on every commit means you classify a new license once, when it appears. Running it at release time means a panic the week before go-live.\n","date":"24 August 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-license-compliance/","section":"Blogs","summary":"You ship a Java application that depends on Spring Boot, which depends on dozens of other libraries, each with its own license — and most teams cannot tell you what those licenses actually are. In Part 4 of our GitLab DevSecOps series, Patrick Steger and I add license compliance to the pipeline so the question is answered automatically on every commit. The good news: with GitLab Ultimate, this is one template line away.\n","title":"GitLab DevSecOps Part 4: How to Ensure License Compliance","type":"blogs"},{"content":"","date":"17 August 2022","externalUrl":null,"permalink":"/en/tags/gemnasium/","section":"Tags","summary":"","title":"Gemnasium","type":"tags"},{"content":"Your code is the small part. The libraries you pull in are the big part — and that is where most of your CVEs live. In Part 3 of the GitLab DevSecOps series, Patrick Steger and I bring up a tiny Spring Boot demo, wire it into a GitLab pipeline, and then add Software Composition Analysis with a single include line.\nThe Demo Project # To make SCA tangible we need something to scan. We create a new GitLab project from the Spring template and call it videodemo. What you get is a minimal Spring Boot application: a web service that returns \u0026ldquo;Spring is here!\u0026rdquo;, a unit test that calls the service and asserts the response, and a Maven build with a pom.xml. Tiny — but exactly the point. The handful of lines we wrote drag in dozens of third-party JARs.\nA Minimal Pipeline First # Before we touch security, we need a pipeline. We add a .gitlab-ci.yml at the repo root with two jobs: build and test. The build job uses a versioned Maven Docker image, runs in the default build stage, and stores the resulting JAR as an artifact. The test job runs in the default test stage, executes the unit tests, and publishes the test report so GitLab can render it in the UI. Commit, push, and GitLab kicks off the run. Both jobs go green. Now we have a baseline to add security on top of.\nWhat SCA Actually Is # Software Composition Analysis — also called dependency scanning — looks for known vulnerabilities in the libraries your application uses. The scanner walks your dependency tree, matches each library and version against public CVE databases, and reports anything with a known issue. In GitLab, SCA is part of the Ultimate tier and is implemented with Gemnasium, an open source scanner that GitLab acquired and now maintains.\nWhy do we need it for an application this small? Look at the build log. A Spring Boot app pulls in a long list of JARs — Spring, Jackson, Tomcat, logging, the works. Your code is a thin layer on top of someone else\u0026rsquo;s code. If one of those someones shipped a CVE, you shipped a CVE. The only way to know is to scan.\nAdding SCA to the Pipeline # Enabling Gemnasium is a one-liner. We include the GitLab template Security/Dependency-Scanning.gitlab-ci.yml, commit, and push. GitLab adds a gemnasium-maven-dependency_scanning job to the next pipeline run. It pulls the Gemnasium image, walks the Maven dependency tree, and uploads the findings as a pipeline artifact.\nBecause the template is open source, you can also copy it into your own repository if you need more control — pin versions, change rules, run it on a schedule. For most teams the include is enough.\nWhere the Findings Live # Two places. First, the raw scan output is available as a JSON artifact under Pipelines → your run → Artifacts. You can feed that into any vulnerability management system you already have. Second, GitLab itself ships a vulnerability management view under Security \u0026amp; Compliance → Vulnerability Report. Gemnasium populated it automatically, sorted by severity. The full management workflow (triage, dismiss, link to issues) is an Ultimate feature and gets its own session later in the series.\nThe first scan on our toy project surfaced 28 critical and 61 high vulnerabilities. From a few lines of demo code. That is the reality of modern dependencies.\nDo You Have to Fix All of Them? # Generally yes — but be pragmatic. Patrick\u0026rsquo;s recommendation, which matches mine: do not start by deeply analyzing each CVE to decide whether it actually affects your code path. That work eats more time than just upgrading. Bump every dependency to a fixed version first. Only for the ones you cannot upgrade — no patched version exists, or the upgrade breaks you — do the deeper analysis. Then decide on compensating controls or document the accepted risk.\nThe point of SCA in CI is to make this a routine, not a project. Every commit gets scanned. New CVEs get caught the next time the pipeline runs. The cost of staying current is low. The cost of getting behind is a panic upgrade under audit pressure.\nKey Takeaways # Most of your code is not yours. A small Spring Boot demo pulls dozens of JARs. SCA is non-optional for any real application.\nGitLab makes SCA a one-liner. include the Security/Dependency-Scanning.gitlab-ci.yml template. The Gemnasium job appears in your next run.\nFindings live in two places. A JSON artifact for your own tooling, and the built-in vulnerability report under Security \u0026amp; Compliance for the GitLab-native workflow.\nThe template is open source. Copy it into your repo when you need to pin, schedule, or customize. The default include is enough for most teams.\nUpgrade first, analyze second. Do not spend hours proving a CVE does not affect you. Bump to a fixed version. Save the deep analysis for the dependencies you genuinely cannot move.\nSCA is Ultimate-tier on GitLab. The scanner runs everywhere, but the integrated vulnerability management UI is paid. Know what you are buying before you wire your reporting around it.\n","date":"17 August 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-sca/","section":"Blogs","summary":"Your code is the small part. The libraries you pull in are the big part — and that is where most of your CVEs live. In Part 3 of the GitLab DevSecOps series, Patrick Steger and I bring up a tiny Spring Boot demo, wire it into a GitLab pipeline, and then add Software Composition Analysis with a single include line.\n","title":"GitLab DevSecOps Part 3: Software Composition Analysis with Gemnasium","type":"blogs"},{"content":"","date":"10 August 2022","externalUrl":null,"permalink":"/en/tags/.net-core/","section":"Tags","summary":"","title":".NET Core","type":"tags"},{"content":"Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.\nThe Problem: Security Found Too Late # Patrick opens the session with a familiar story. He had to do a security review of an application, found issues, and got blamed for blocking the go-live. The point is not that the review was wrong. The point is that nobody checked security earlier in the process. The team had no idea how. That is exactly the gap a DevSecOps pipeline closes. You shift security testing left so that issues surface when they are still cheap to fix, and you automate the checks so that no developer has to remember to run them.\nWhy Products Need a Pipeline # We build products, not projects, and products evolve continuously. The DevOps infinity symbol captures this: plan, code, build, test, deploy, release, operate, monitor, repeat. To support that loop, you need a CI/CD pipeline. And to talk about CI/CD without confusing each other, we have to be precise about three terms: continuous integration, continuous delivery, and continuous deployment.\nContinuous Integration # Continuous integration starts the moment a developer commits code. The CI server picks it up, builds it, runs static code analysis, runs static security analysis, and executes the unit tests and some of the integration tests. The output is a deployable artifact. Crucially, security checks are already part of this stage. You do not wait for a separate security gate at the end. You do them on every commit.\nThe other thing that matters here is feedback time. The developer should not wait hours or days. We are talking minutes. If the loop is slow, the developer has already moved on by the time the result comes back, and the cost of context switching wipes out everything else.\nContinuous Delivery # The deployable artifact from CI is automatically deployed to a staging environment. There you run additional automated tests, including penetration tests if you want them. The deployment is automated; the decision to release is not. Continuous delivery gives you a button. Press it when the business is ready.\nContinuous Deployment # Continuous deployment goes one step further. The artifact that passed CI and was deployed to staging is also deployed to production automatically, with another set of automated tests catching anything that slipped through. There is no manual gate. If you want a manual security checkpoint, that is fine — but then you are doing continuous delivery, not continuous deployment. Be honest about which one you actually run, because the trade-offs are different.\nRelease on Demand # DevOps separates deployment from release. Deployment is putting the compiled code into production, behind a feature toggle. Release is enabling that toggle. With release on demand you decouple \u0026ldquo;the code is in production\u0026rdquo; from \u0026ldquo;the customer can see the new feature.\u0026rdquo; That is what makes continuous deployment safe even for high-impact changes.\nThe Pipeline We Will Build with GitLab # There are many platforms that promise to cover the whole continuous delivery pipeline — GitLab, GitHub, Azure DevOps, and others. In this series we focus on GitLab. GitLab promises to cover everything, but in reality, your real-world pipeline will look more focused. For this series we leave out continuous exploration and release on demand, and we do continuous delivery (not full continuous deployment). The artifact gets automatically deployed to staging.\nThe pipeline we will build covers, on the CI side, static application security testing, secret detection, software composition analysis, and container scanning. On the CD side we add dynamic application security testing. Each topic gets its own session.\nKey Takeaways # Shift security left or pay for it later. The further to the right a security issue is found, the more expensive it is to fix. Build the checks into CI from day one.\nBe precise about CI, CD, and continuous deployment. Continuous integration ends with a tested artifact. Continuous delivery deploys to staging. Continuous deployment deploys to production. Mixing them up leads to mismatched expectations.\nFeedback in minutes, not hours. Developers context-switch fast. If the pipeline takes hours, the feedback lands on a developer who has already moved on, and the value of catching issues early is gone.\nSeparate deployment from release. Feature toggles let you ship code to production without exposing it to users. This is what makes aggressive deployment safe.\nVendor promises rarely match reality. GitLab claims to cover the entire pipeline; your real pipeline will be more focused and may need third-party pieces. Plan for that, do not fight it.\nA DevSecOps pipeline is a series of small, automated decisions. SAST, secret detection, SCA, container scanning, DAST — none of them are exotic. The discipline is wiring them into every commit so they run without anyone remembering to ask.\n","date":"10 August 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-introduction/","section":"Blogs","summary":"Why does security still get bolted on at the end of the development process, and how do we move it earlier without slowing teams down? In Part 1 of our GitLab DevSecOps series, Patrick Steger and I set the stage: what GitLab is, what shifting security left really means, and which CI/CD concepts you have to understand before you can build a DevSecOps pipeline that actually works.\n","title":"GitLab DevSecOps Part 1: What Is GitLab and Why Shift Security Left?","type":"blogs"},{"content":"Before we can shift any security checks left, we need a project, a repository, and a pipeline that actually builds something. In Part 2 of our GitLab DevSecOps series, Patrick Steger and I log into GitLab, create a new .NET Core project from a template, and look at the .gitlab-ci.yml file that GitLab generates for us — including the build and test jobs that will become the foundation for everything we add later.\nLogging In and Finding Your Way Around # After you log in to GitLab, the first thing you see is your project list — every repository you own or collaborate on, with filters and search to keep things manageable. The left navigation gives you projects, groups, milestones, snippets, activity, environments, operations, and security. We will come back to most of these in later sessions. For this introduction, we head straight to \u0026ldquo;New project.\u0026rdquo;\nCreating a Project From a Template # GitLab gives you several ways to start a project: a blank repository, a template, an import from another platform, or a CI/CD setup that runs against an external repo. We pick the template option because it gives us code, structure, and a starting pipeline in one click.\nThe template list covers the usual languages. We pick .NET Core, name the project myDotNetCore, choose the project URL, and set visibility to private. Public would also work — for a demo it does not matter — but private is the realistic default for anything you would build at work.\nA few seconds later GitLab has generated the project. You land in the repository view with a README, the .NET hello-world Program.cs, the .csproj, and — the file that matters most for us — .gitlab-ci.yml.\nWhat\u0026rsquo;s Inside .gitlab-ci.yml # The auto-generated .gitlab-ci.yml defines the whole CI pipeline for this project. Two stages, build and test, each with one job of the same name. Both jobs already contain everything needed to compile and test a .NET project. This is the spine we will hang every security check on later in the series — SAST, secret detection, SCA, container scanning. The fact that GitLab gives you a working pipeline on day one is a real productivity boost.\nRunning the Pipeline # To see the file in action, we go to CI/CD → Pipelines. There is also an inline editor here if you want to edit .gitlab-ci.yml from the UI. Right now there are no pipelines, so we click Run pipeline. The build job kicks off first, finishes successfully, and the test job follows. Click into a running job and you get a live log — useful for debugging, useful for understanding what is actually happening on the runner.\nWhen both jobs go green, the pipeline is done.\nWhat Just Happened: Runners and Docker Images # Going back to .gitlab-ci.yml, the online version of GitLab provides shared runners that execute your CI/CD jobs. These runners use Docker images, and the image is declared in the YAML file. By default, each job runs in its own fresh Docker image. That is a clean isolation model, but it also means the build job and the test job each spin up an environment, fetch the source, and do part of the same work.\nDrilling into the build job log, you see the GitLab Runner starting up, the Docker executor preparing the machine, the image being pulled, the environment being prepared, the sources being cloned from Git, and finally the dotnet build command executing. Artifacts get uploaded at the end. The test job repeats most of those steps and then runs dotnet test. Because there are no tests in the hello-world project, it succeeds without doing much.\nTwo Things Worth Calling Out # There are two details from this run that you want to internalise before you grow the pipeline.\nFirst, pin your image versions. The default template uses the latest tag for the Docker image. That is convenient until the image moves under you and your build breaks for a reason that has nothing to do with your code. Always pin a specific version so you control your build environment.\nSecond, reuse artifacts between jobs. Right now the build job compiles, the test job effectively compiles again before testing. That doubles the work for no reason. As your pipeline grows, pass the build output as an artifact into the test job so the test stage just runs the tests. It is one of the easiest optimisations to make.\nKey Takeaways # Start from a template, not a blank repo. GitLab generates the source files, a working .gitlab-ci.yml, and a runnable pipeline in one click. You spend your time on what makes your project unique, not on boilerplate.\n.gitlab-ci.yml is the heart of GitLab CI. Stages, jobs, scripts, and images are all declared here. Once you understand the shape of this file, the rest of GitLab CI follows.\nPipelines run on runners, runners use Docker images. The runner is the executor; the image is the environment. GitLab\u0026rsquo;s shared runners cover most early needs, but knowing how it works matters when you self-host later.\nPin your Docker image versions. Using latest makes builds non-deterministic. A pinned version gives you a reproducible build environment that only changes when you decide it changes.\nReuse build artifacts in downstream jobs. Each job runs in its own container. Without artifact passing, you compile twice — once in build, once again in test. Pass the artifact and the pipeline gets noticeably faster.\nThe two-stage build/test pipeline is the foundation, not the goal. Everything we add over the next sessions — SAST, secret detection, SCA, container scanning, DAST — plugs into this same structure. Get comfortable with it now and the rest of the series will feel like extension, not reinvention.\n","date":"10 August 2022","externalUrl":null,"permalink":"/en/blogs/gitlab-devsecops-creating-a-project/","section":"Blogs","summary":"Before we can shift any security checks left, we need a project, a repository, and a pipeline that actually builds something. In Part 2 of our GitLab DevSecOps series, Patrick Steger and I log into GitLab, create a new .NET Core project from a template, and look at the .gitlab-ci.yml file that GitLab generates for us — including the build and test jobs that will become the foundation for everything we add later.\n","title":"GitLab DevSecOps Part 2: Creating a Simple Project and Your First Pipeline","type":"blogs"},{"content":"Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.\nDas Problem: Security wird zu spät gefunden # Patrick beginnt die Session mit einer bekannten Geschichte. Er hat ein Security Review für eine Anwendung gemacht, Probleme gefunden — und wurde dafür verantwortlich gemacht, dass das Go-live nicht stattfinden konnte. Es geht hier nicht darum, dass das Review falsch war. Es geht darum, dass niemand vorher Security geprüft hat. Das Team wusste schlicht nicht, wie. Genau diese Lücke schliesst eine DevSecOps-Pipeline. Du verschiebst Security-Tests nach links, sodass Probleme dann auftauchen, wenn sie noch günstig zu beheben sind, und du automatisierst die Checks, sodass kein Entwickler daran denken muss.\nWarum Produkte eine Pipeline brauchen # Wir bauen Produkte, keine Projekte, und Produkte entwickeln sich kontinuierlich weiter. Das DevOps-Infinity-Symbol bringt das auf den Punkt: plan, code, build, test, deploy, release, operate, monitor — und wieder von vorn. Um diesen Loop zu unterstützen, brauchst du eine CI/CD-Pipeline. Und um über CI/CD zu reden, ohne aneinander vorbeizureden, müssen wir drei Begriffe sauber trennen: Continuous Integration, Continuous Delivery und Continuous Deployment.\nContinuous Integration # Continuous Integration startet in dem Moment, in dem ein Entwickler Code committet. Der CI-Server holt sich den Code, baut ihn, führt statische Code-Analyse durch, statische Security-Analyse, Unit Tests und einen Teil der Integrationstests. Output ist ein deploybares Artefakt. Wichtig: Security-Checks sind bereits Teil dieses Schritts. Du wartest nicht auf ein separates Security-Gate am Ende. Du machst sie bei jedem Commit.\nWas hier ebenfalls entscheidend ist: die Feedback-Zeit. Der Entwickler darf nicht Stunden oder Tage warten. Wir sprechen von Minuten. Ist der Loop langsam, hat der Entwickler längst etwas anderes angefangen, wenn das Ergebnis kommt — und der Context-Switch frisst den Vorteil sofort wieder auf.\nContinuous Delivery # Das deploybare Artefakt aus der CI wird automatisch in eine Staging-Umgebung deployed. Dort laufen weitere automatisierte Tests, bei Bedarf auch Penetration Tests. Das Deployment ist automatisiert; der Release ist es nicht. Continuous Delivery gibt dir einen Knopf — drück ihn, wenn das Business bereit ist.\nContinuous Deployment # Continuous Deployment geht einen Schritt weiter. Das Artefakt, das CI bestanden hat und auf Staging deployed wurde, wird auch automatisch in Produktion deployed — mit einem weiteren Set automatisierter Tests, das Probleme abfängt, die durchgerutscht sind. Es gibt kein manuelles Gate. Wenn du einen manuellen Security-Checkpoint möchtest, ist das in Ordnung — aber dann machst du Continuous Delivery, nicht Continuous Deployment. Sei ehrlich, was du tatsächlich umsetzt, denn die Trade-offs sind unterschiedlich.\nRelease on Demand # DevOps trennt Deployment von Release. Deployment ist das Ausrollen des kompilierten Codes nach Produktion, hinter einem Feature Toggle. Release ist das Aktivieren dieses Toggles. Mit Release on Demand entkoppelst du \u0026ldquo;der Code ist in Produktion\u0026rdquo; von \u0026ldquo;der Kunde sieht das neue Feature\u0026rdquo;. Das ist es, was Continuous Deployment auch bei wirkungsstarken Änderungen sicher macht.\nDie Pipeline, die wir mit GitLab bauen werden # Es gibt viele Plattformen, die versprechen, die gesamte Continuous Delivery Pipeline abzudecken — GitLab, GitHub, Azure DevOps und andere. In dieser Serie konzentrieren wir uns auf GitLab. GitLab verspricht, alles abzudecken, aber in der Realität wird deine Pipeline fokussierter aussehen. In dieser Serie lassen wir Continuous Exploration und Release on Demand weg und machen Continuous Delivery (kein vollständiges Continuous Deployment). Das Artefakt wird automatisch nach Staging deployed.\nDie Pipeline deckt auf der CI-Seite Static Application Security Testing, Secret Detection, Software Composition Analysis und Container Scanning ab. Auf der CD-Seite kommt Dynamic Application Security Testing dazu. Jedes Thema bekommt eine eigene Session.\nKey Takeaways # Security nach links verschieben oder später teuer dafür zahlen. Je weiter rechts ein Security-Problem gefunden wird, desto teurer wird die Behebung. Bau die Checks von Anfang an in die CI ein.\nCI, CD und Continuous Deployment sauber trennen. Continuous Integration endet mit einem getesteten Artefakt. Continuous Delivery deployed nach Staging. Continuous Deployment deployed nach Produktion. Vermischt man die Begriffe, vermischt man auch die Erwartungen.\nFeedback in Minuten, nicht in Stunden. Entwickler wechseln schnell den Kontext. Dauert die Pipeline Stunden, kommt das Feedback bei jemandem an, der längst woanders ist — der Vorteil des frühen Findens ist weg.\nDeployment vom Release trennen. Feature Toggles erlauben es, Code in Produktion zu schicken, ohne ihn für Nutzer sichtbar zu machen. Das macht aggressives Deployment sicher.\nHersteller-Versprechen entsprechen selten der Realität. GitLab behauptet, die gesamte Pipeline abzudecken; deine echte Pipeline wird fokussierter sein und braucht möglicherweise Drittanbieter-Tools. Plane das ein, statt dagegen zu kämpfen.\nEine DevSecOps-Pipeline ist eine Reihe kleiner, automatisierter Entscheidungen. SAST, Secret Detection, SCA, Container Scanning, DAST — keines davon ist exotisch. Die Disziplin liegt darin, sie so in jeden Commit zu verdrahten, dass sie laufen, ohne dass jemand daran denken muss.\n","date":"10. August 2022","externalUrl":null,"permalink":"/de/blogs/gitlab-devsecops-einfuehrung/","section":"Blogs","summary":"Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.\n","title":"GitLab DevSecOps Teil 1: Was ist GitLab und warum Security nach links verschieben?","type":"blogs"},{"content":"Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.\nAnmelden und Orientierung # Nach dem Login zeigt GitLab als Erstes deine Projektliste — alle Repositories, in denen du Owner bist oder mitarbeitest, mit Filter und Suche, damit es übersichtlich bleibt. Die linke Navigation bietet Projects, Groups, Milestones, Snippets, Activity, Environments, Operations und Security. Auf das meiste davon kommen wir in späteren Sessions zurück. Für diese Einführung gehen wir direkt auf \u0026ldquo;New project\u0026rdquo;.\nEin Projekt aus einem Template anlegen # GitLab bietet mehrere Wege, ein Projekt zu starten: ein leeres Repository, ein Template, ein Import aus einer anderen Plattform oder ein CI/CD-Setup, das gegen ein externes Repo läuft. Wir nehmen das Template, weil wir damit Code, Struktur und eine erste Pipeline mit einem Klick bekommen.\nDie Template-Liste deckt die üblichen Sprachen ab. Wir wählen .NET Core, nennen das Projekt myDotNetCore, wählen die Projekt-URL und setzen die Sichtbarkeit auf privat. Public würde auch gehen — für ein Demo ist das egal — aber privat ist der realistische Default für alles, was du beruflich bauen würdest.\nEin paar Sekunden später hat GitLab das Projekt generiert. Du landest in der Repository-Ansicht mit README, dem .NET-Hello-World-Program.cs, der .csproj — und der Datei, die für uns am meisten zählt: .gitlab-ci.yml.\nWas steht in der .gitlab-ci.yml # Die automatisch generierte .gitlab-ci.yml definiert die komplette CI-Pipeline für dieses Projekt. Zwei Stages, build und test, jede mit einem Job gleichen Namens. Beide Jobs enthalten bereits alles, was nötig ist, um ein .NET-Projekt zu kompilieren und zu testen. Das ist das Rückgrat, an das wir später jeden Security-Check hängen — SAST, Secret Detection, SCA, Container Scanning. Dass GitLab dir vom ersten Tag an eine lauffähige Pipeline gibt, ist ein echter Produktivitätsgewinn.\nDie Pipeline ausführen # Um die Datei in Aktion zu sehen, gehen wir auf CI/CD → Pipelines. Hier gibt es auch einen Inline-Editor, falls du .gitlab-ci.yml direkt aus dem UI bearbeiten möchtest. Im Moment sind keine Pipelines vorhanden, also klicken wir auf Run pipeline. Der Build-Job startet als Erstes, läuft erfolgreich durch, und der Test-Job folgt. Klickst du in einen laufenden Job rein, bekommst du ein Live-Log — nützlich zum Debuggen, nützlich, um zu verstehen, was auf dem Runner tatsächlich passiert.\nSobald beide Jobs grün sind, ist die Pipeline durch.\nWas eigentlich passiert ist: Runner und Docker Images # Zurück zur .gitlab-ci.yml: Die Online-Variante von GitLab stellt Shared Runner zur Verfügung, die deine CI/CD-Jobs ausführen. Diese Runner nutzen Docker Images, und das Image wird in der YAML deklariert. Standardmässig läuft jeder Job in einem eigenen, frischen Docker Image. Das ist eine saubere Isolation, bedeutet aber auch, dass Build- und Test-Job jeweils eine Umgebung hochfahren, den Source-Code holen und einen Teil derselben Arbeit doppelt erledigen.\nIm Build-Job-Log sieht man der Reihe nach: GitLab Runner startet, Docker Executor bereitet die Maschine vor, das Image wird gepullt, die Umgebung wird vorbereitet, die Sources werden aus Git geklont, und schliesslich läuft der dotnet build. Am Ende werden die Artifacts hochgeladen. Der Test-Job wiederholt die meisten dieser Schritte und führt dann dotnet test aus. Da im Hello-World-Projekt keine Tests existieren, läuft er ohne grosses Aufheben durch.\nZwei Dinge, die du dir merken solltest # Es gibt zwei Details aus diesem Lauf, die du verinnerlichen willst, bevor du die Pipeline ausbaust.\nErstens: Image-Versionen pinnen. Das Default-Template verwendet das Tag latest für das Docker Image. Praktisch — bis sich das Image unter dir verändert und dein Build aus einem Grund kaputtgeht, der nichts mit deinem Code zu tun hat. Pin immer eine konkrete Version, damit du die Build-Umgebung kontrollierst.\nZweitens: Artifacts zwischen Jobs wiederverwenden. Aktuell kompiliert der Build-Job, und der Test-Job kompiliert effektiv nochmal, bevor er testet. Doppelte Arbeit ohne Mehrwert. Sobald die Pipeline wächst, gib das Build-Output als Artifact an den Test-Job weiter, sodass die Test-Stage nur noch testet. Eine der einfachsten Optimierungen überhaupt.\nKey Takeaways # Aus einem Template starten, nicht aus einem leeren Repo. GitLab generiert die Quelldateien, eine funktionierende .gitlab-ci.yml und eine ausführbare Pipeline mit einem Klick. Du verbringst deine Zeit mit dem, was dein Projekt einzigartig macht, nicht mit Boilerplate.\n.gitlab-ci.yml ist das Herzstück von GitLab CI. Stages, Jobs, Scripts und Images sind alle hier deklariert. Wer die Form dieser Datei verstanden hat, hat den Rest von GitLab CI im Griff.\nPipelines laufen auf Runnern, Runner nutzen Docker Images. Der Runner ist der Executor; das Image ist die Umgebung. Die Shared Runner von GitLab decken die meisten Anfangsbedürfnisse ab — aber zu wissen, wie das funktioniert, zahlt sich aus, sobald du selbst hostest.\nDocker-Image-Versionen pinnen. latest macht Builds nicht-deterministisch. Eine gepinnte Version gibt dir eine reproduzierbare Build-Umgebung, die sich nur ändert, wenn du es entscheidest.\nBuild-Artifacts in nachgelagerten Jobs wiederverwenden. Jeder Job läuft in einem eigenen Container. Ohne Artifact-Passing kompilierst du zweimal — einmal im Build, einmal im Test. Mit Artifact wird die Pipeline spürbar schneller.\nDie zweistufige Build/Test-Pipeline ist das Fundament, nicht das Ziel. Alles, was wir in den nächsten Sessions ergänzen — SAST, Secret Detection, SCA, Container Scanning, DAST — steckt in derselben Struktur. Wer sich jetzt damit wohlfühlt, erlebt den Rest der Serie als Erweiterung, nicht als Neuerfindung.\n","date":"10. August 2022","externalUrl":null,"permalink":"/de/blogs/gitlab-devsecops-projekt-erstellen/","section":"Blogs","summary":"Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.\n","title":"GitLab DevSecOps Teil 2: Ein einfaches Projekt und die erste Pipeline erstellen","type":"blogs"},{"content":"","date":"10 August 2022","externalUrl":null,"permalink":"/en/tags/gitlab-runner/","section":"Tags","summary":"","title":"GitLab Runner","type":"tags"},{"content":"","date":"15 July 2022","externalUrl":null,"permalink":"/en/tags/epics/","section":"Tags","summary":"","title":"Epics","type":"tags"},{"content":"","date":"15 July 2022","externalUrl":null,"permalink":"/en/tags/mvp/","section":"Tags","summary":"","title":"MVP","type":"tags"},{"content":"","date":"15. July 2022","externalUrl":null,"permalink":"/de/tags/produktmanagement/","section":"Tags","summary":"","title":"Produktmanagement","type":"tags"},{"content":"Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.\nWas genau ist ein Epic? # Ein Epic ist ein grosses Arbeitspaket, das in kleinere Teile heruntergebrochen werden muss. Ein oder mehrere Teams arbeiten an einem Epic, und jedes Epic hat einen Titel, einen Owner und eine Beschreibung. Die Grösse eines Epics sollte zwischen drei und neun Monaten liegen, weil wir die Hypothese dahinter so schnell wie möglich evaluieren und Wert an den Markt liefern wollen.\nDer Schlüssel zum Epic ist das Epic Hypothesis Statement. Das ist nicht einfach eine Beschreibung dessen, was gebaut werden soll. Es ist ein strukturierter Pitch, der alles klar macht: Für welchen Kunden, der was möchte, ist unsere Lösung etwas, das einen bestimmten Wert liefert, und im Gegensatz zum Wettbewerb macht unsere Lösung es besser. Mit einer solchen Beschreibung wird klar, wofür das Epic da ist, welchen Kunden wir bedienen und warum.\nNoch wichtiger: Wir müssen messbare Geschäftsergebnisse und Leading Indicators definieren. Das sind keine nachlaufenden Indikatoren, die uns erst im Nachhinein informieren. Leading Indicators sagen uns so früh wie möglich, schon während der MVP-Entwicklung, ob unsere Hypothese wahr oder falsch ist.\nDer Lebenszyklus eines Epics # Der Lebenszyklus funktioniert so: Eine gute Idee kommt vom Business oder von Kunden. Wir erfassen sie im Epic Hypothesis Statement und legen sie auf das Product Backlog. Wenn genügend Kapazität vorhanden ist, bauen wir ein Minimum Viable Product (MVP). Das ist das Minimum, das wir bauen müssen, um die Hypothese zu beweisen oder zu widerlegen.\nDann evaluieren wir die Hypothese anhand der Leading Indicators und Geschäftsergebnisse. Wenn die Hypothese stimmt, entwickeln wir weitere Features und re-evaluieren. Wenn die Hypothese widerlegt wird, entscheiden wir: Machen wir einen Pivot mit einem neuen, angepassten Epic, oder hören wir ganz auf? Dieses Modell wird auch von vielen erfolgreichen Startups verwendet.\nEin konkretes Beispiel: Swiss Dentist # Hier ein fiktives Beispiel. \u0026ldquo;Swiss Dentist\u0026rdquo; ist ein Unternehmen mit Praxen in allen grossen Schweizer Städten. Der CEO, Dr. Hans Muster, hat eine Idee: eine mobile App, über die Kunden Zahnarzttermine vereinbaren und verwalten können.\nDas Epic Hypothesis Statement sieht so aus:\nEpic Name: Mobile App für Zahnarzttermine Epic Owner: Dr. Hans Muster Beschreibung: Für Swiss-Dentist-Kunden, die einen Zahnarzttermin vereinbaren möchten, ist die Swiss Dentist App eine mobile Anwendung, die das Buchen, Umbuchen und die Standortsuche ermöglicht. Im Gegensatz zu AAA-Dentist (dem Wettbewerber) hält unsere Lösung die Kunden durch automatische Benachrichtigungen auf dem Laufenden.\nDie Geschäftsergebnisse: Die Mehrheit der Termine wird über die App gebucht, das Callcenter-Volumen sinkt und die Kundenzufriedenheit steigt. Die Leading Indicators: weniger Callcenter-Aktivität bei der Terminbuchung und eine Zunahme der Gesamttermine durch automatische Benachrichtigungen.\nDie Kraft des Pivots # Jetzt wird es spannend. Als MVP wählten wir einen Papier-Prototypen. Wir gingen zu echten Kunden und fragten: Würden Sie diese App herunterladen und nutzen? Die Mehrheit sagte: \u0026ldquo;Nicht schon wieder eine App! Ich habe zu viele davon. Aber wenn es eine Webanwendung wäre, würde ich sie gerne nutzen.\u0026rdquo;\nDie Hypothese wurde widerlegt. Aber wir haben keine Monate an Entwicklungszeit verloren. Wir machten einen Pivot, erstellten ein neues Epic für eine Webanwendung und durchliefen den Zyklus erneut. Nach Bau und Rollout des Web-MVPs zeigten die Daten klare Verbesserungen: Das Callcenter-Volumen sank, die über das Web gebuchten Termine stiegen, und die Gesamtanzahl der Termine wuchs. All das war schon früh, während der MVP-Phase, sichtbar.\nDas ist der grosse Vorteil von Epics: Man kann eine Idee sehr früh evaluieren und fundierte Entscheidungen treffen, bevor man stark investiert.\nProjekt vs. Epic # Der Vergleich ist deutlich:\nScope: Projekte haben einen fixen Scope mit einer Liste von Deliverables. Epics haben einen variablen Scope, definiert durch Geschäftsergebnisse und Leading Indicators. Messung: Projekte messen Output (gelieferte Features). Epics messen Outcome (Hypothese bewiesen oder widerlegt). Zeitrahmen: Projekte haben fixe Start- und Enddaten. Epics laufen, bis die Hypothese validiert und die Geschäftsergebnisse erreicht sind. Umsetzung: Projekte nutzen typischerweise Waterfall oder \u0026ldquo;Water-Scrum-Fall.\u0026rdquo; Epics nutzen agile Methoden. Teams: Projekte haben temporäre, zusammengestellte Teams. Epics haben stabile, crossfunktionale Teams, die am Backlog arbeiten. Budget: Projekte haben fixe Budgets. Epics nutzen Finanzierung über Value Streams. Betrieb: Projekte werfen Ergebnisse über die Mauer zum Betrieb. Epics umfassen den gesamten Betriebszyklus. Warum wir Epics nutzen sollten # Was in Organisationen üblicherweise passiert: Wir haben viele tolle Ideen und wollen alle umsetzen. Aber wir vergessen, dass wir die Entwicklungsteams damit komplett überlasten. Manche Ideen sind grossartig, andere sollten nie entwickelt werden. Das Ergebnis: Technical Debt häuft sich an, die Qualität sinkt, und die wirklich guten Ideen bekommen nicht die Aufmerksamkeit, die sie verdienen.\nMit Epics bringen wir Disziplin ein. Wir erstellen das Hypothesis Statement, definieren Geschäftsergebnisse, identifizieren Leading Indicators, bauen ein MVP und evaluieren schnell. Wenn die Hypothese scheitert, machen wir einen Pivot oder stoppen. Wenn sie bestätigt wird, entwickeln wir weiter und re-evaluieren. So können sich die Entwicklungsteams auf die richtigen Features konzentrieren und das Richtige auf die richtige Art bauen.\nKernaussagen # Epics sind hypothesengetrieben. Jedes Epic beginnt mit einem klaren Hypothesis Statement, das Kunden, Lösung, Wert und Wettbewerbsvorteil definiert. Leading Indicators sind essenziell. Sie ermöglichen es, eine Hypothese so früh wie möglich zu validieren oder zu widerlegen, nicht erst nach Monaten der Entwicklung. Zuerst ein MVP bauen. Das Minimum Viable Product ist der schnellste Weg zu lernen, ob eine Idee Potenzial hat. Pivot oder Stopp ohne schlechtes Gewissen. Eine früh widerlegte Hypothese spart Zeit, Geld und Teamkapazität für die Ideen, die wirklich zählen. Epics schlagen Projekte. Durch den Fokus auf Outcomes statt Outputs verhindern Epics die Überlastung von Teams und stellen sicher, dass das Richtige richtig gebaut wird. ","date":"15. July 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-ein-epic/","section":"Blogs","summary":"Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.\n","title":"Was ist ein Epic?","type":"blogs"},{"content":"How do you make sure your organization is not overloaded with too many projects, too many ideas, and too little focus? And how do you ensure you are building the right thing? This is exactly what epics are for. In this video, I walk through the concept of epics, show you a concrete example, and explain why epics are far more effective than traditional projects.\nWhat Exactly is an Epic? # An epic is a large body of work that needs to be broken down into smaller pieces for implementation. One or many teams work on an epic, and every epic has a title, an owner, and a description. The size of an epic should be bigger than three months but smaller than nine months, because we want to evaluate the hypothesis behind it as fast as possible and bring value to the market quickly.\nThe key to an epic is the epic hypothesis statement. This is not just a description of what to build. It is a structured pitch that makes everything clear: for which customer, who wants to do what, our solution is something that provides a certain kind of value, and unlike any competition, our solution does it better. With such a description, it becomes very clear what the epic is for, what customer we are serving, and why.\nEven more important: we need to define measurable business outcomes and leading indicators. These are not lagging indicators that tell us after the fact. Leading indicators tell us as early as possible, even during MVP development, whether our hypothesis is true or false.\nThe Life Cycle of an Epic # The life cycle works like this: a bright idea comes from the business or from customers. We capture it using the epic hypothesis statement and put it on the product backlog. When there is enough capacity, we build a minimum viable product (MVP), which is the minimum we need to build to prove or disprove the hypothesis.\nThen we evaluate the hypothesis based on leading indicators and business outcomes. If the hypothesis is true, we continue developing more features and re-evaluate. If the hypothesis is disproven, we decide: do we pivot with a new adapted epic, or do we stop entirely? This model is also used by many successful startups.\nA Concrete Example: Swiss Dentist # Let me walk through a fictional example. \u0026ldquo;Swiss Dentist\u0026rdquo; is a company with offices in all major Swiss cities. The CEO, Dr. Hans Muster, has a bright idea: a mobile app for customers to schedule and manage their dentist appointments.\nThe epic hypothesis statement looks like this:\nEpic Name: Mobile App for Dentist Appointments Epic Owner: Dr. Hans Muster Description: For Swiss Dentist customers who want to schedule a dentist appointment, the Swiss Dentist App is a mobile application that provides the ability to schedule appointments, reschedule appointments, and search for locations. Unlike AAA-Dentist (the competitor), our solution keeps customers informed with automatic notifications.\nThe business outcomes: majority of appointments scheduled via the app, decreasing call centre volumes, and better customer experience. The leading indicators: less call centre activity regarding scheduling, and an increase in overall appointments due to automatic notifications.\nThe Power of the Pivot # Here is where it gets interesting. For the MVP, we chose a paper prototype. We went to real customers and asked: would you download and use this app? The majority said: \u0026ldquo;Not another mobile app! I have too many already. But if it were a web application, I would happily use it.\u0026rdquo;\nThe hypothesis was disproven. But we did not lose months of development. We pivoted, created a new epic for a web application, and went through the cycle again. After building and rolling out the web MVP, the data showed clear improvement: call centre volumes decreased, web-scheduled appointments increased, and overall appointments grew. All of this was visible early, during the MVP stage.\nThis is the big advantage of using epics: you can evaluate an idea very early and make informed decisions before investing heavily.\nProject vs. Epic # The comparison is striking:\nScope: Projects have fixed scope with a list of deliverables. Epics have variable scope defined by business outcomes and leading indicators. Measurement: Projects measure output (features delivered). Epics measure outcome (hypothesis proven or disproven). Time Frame: Projects have fixed start and end dates. Epics run until the hypothesis is validated and business outcomes are reached. Implementation: Projects typically use waterfall or \u0026ldquo;water-scrum-fall.\u0026rdquo; Epics use agile methodologies. Teams: Projects use temporary, staffed teams. Epics use stable, cross-functional teams working on a backlog. Budget: Projects have fixed budgets. Epics use funding across value streams. Operations: Projects throw results over the wall to operations. Epics include the whole operation lifecycle. Why We Should Use Epics # Usually what happens in organizations is this: we have many bright ideas and we want to develop all of them. But we forget that we are completely overwhelming and overloading our development teams. Some ideas are great, but others should never be developed. The result: technical debt piles up, quality decreases, and the really good ideas do not get the attention they deserve.\nWith epics, we apply discipline. We create the hypothesis statement, define business outcomes, identify leading indicators, build an MVP, and evaluate quickly. If the hypothesis fails, we pivot or stop. If it succeeds, we continue and re-evaluate. This ensures that development teams can concentrate on the right features and build the right thing in the right way.\nKey Takeaways # Epics are hypothesis-driven. Every epic starts with a clear hypothesis statement that defines the customer, the solution, the value, and the competitive advantage. Leading indicators are essential. They allow you to validate or invalidate a hypothesis as early as possible, not after months of development. Build an MVP first. The minimum viable product is your fastest path to learning whether an idea has merit. Pivot or stop without guilt. Disproving a hypothesis early saves time, money, and team capacity for the ideas that truly matter. Epics beat projects. By focusing on outcomes instead of outputs, epics prevent team overload and ensure you build the right thing right. ","date":"15 July 2022","externalUrl":null,"permalink":"/en/blogs/what-is-an-epic/","section":"Blogs","summary":"How do you make sure your organization is not overloaded with too many projects, too many ideas, and too little focus? And how do you ensure you are building the right thing? This is exactly what epics are for. In this video, I walk through the concept of epics, show you a concrete example, and explain why epics are far more effective than traditional projects.\n","title":"What is an Epic?","type":"blogs"},{"content":"","date":"28 June 2022","externalUrl":null,"permalink":"/en/tags/backlog-management/","section":"Tags","summary":"","title":"Backlog Management","type":"tags"},{"content":"","date":"28 June 2022","externalUrl":null,"permalink":"/en/tags/product-backlog/","section":"Tags","summary":"","title":"Product Backlog","type":"tags"},{"content":"","date":"28 June 2022","externalUrl":null,"permalink":"/en/tags/product-owner/","section":"Tags","summary":"","title":"Product Owner","type":"tags"},{"content":"","date":"28 June 2022","externalUrl":null,"permalink":"/en/tags/user-stories/","section":"Tags","summary":"","title":"User Stories","type":"tags"},{"content":"In meinem letzten Video haben wir uns angeschaut, was ein Backlog ist. Dabei haben wir gelernt, dass ein Backlog aus Product Backlog Items besteht, kurz PBI. In diesem Video gehen wir eine Ebene tiefer und schauen uns an, was genau ein PBI ist, wie es sich über die Zeit entwickelt und wie es mit dem Product Backlog, dem Sprint Backlog und dem Product Owner zusammenhängt.\nWas ist ein Product Backlog Item? # Ein Product Backlog Item ist ein einzelnes Arbeitselement auf dem Product Backlog. Ein solches PBI kann verschiedene Formen annehmen: ein Epic, ein Feature, eine User Story oder ein Task. Jeder dieser Typen dient einem anderen Zweck und operiert auf einer anderen Granularitätsebene. In meinen nachfolgenden Videos gehe ich auf jeden dieser Typen im Detail ein.\nDer Lebenszyklus eines PBI # Jedes Product Backlog Item durchläuft einen Lebenszyklus. Er beginnt, wenn Stakeholder, wie das Business, Kunden oder der Product Owner, neue Ideen haben. Das neue PBI wird dann am Ende des Backlogs erstellt. Danach nimmt sich der Product Owner das PBI und ordnet es gemäss Business Value, Risiken und anderen Kriterien ein. Gemeinsam mit dem Team wird das PBI Schritt für Schritt verfeinert, bis es bereit für die Implementierung ist. Nach der Implementierung wird es Teil des inkrementellen Produkts.\n\u0026ldquo;Ein Product Backlog Item beginnt als einfacher Zwei-Wort-Titel und entwickelt sich über Wochen und Monate durch Diskussionen, Schätzungen und Akzeptanzkriterien, bis es bereit zur Implementierung ist.\u0026rdquo;\nWie der Product Owner das Backlog ordnet # Der Product Owner ordnet PBIs nach verschiedenen Kriterien: Geschäftsrisiko, technisches Risiko, Business Value, Kundenzufriedenheit, Zeitkritikalität, Implementierungsstrategie, Abhängigkeiten, Infrastrukturarbeiten und Abbau von technischen Schulden.\nWas ich viel zu oft sehe, sind Product Owner, die nur Features, Features, Features wollen und dabei technische Schulden, Infrastrukturarbeiten und technische Risiken komplett ignorieren. Das ist ein gefährliches Muster. Man sollte immer ein gesundes Gleichgewicht zwischen technischer Arbeit und fachlicher Arbeit halten. Wenn man die technische Seite vernachlässigt, wird das Produkt irgendwann in einen Zustand geraten, in dem man nur noch Bugs fixt und keine neuen Features mehr liefern kann.\nWie sich ein PBI über die Zeit entwickelt # Hier ein grobes Beispiel, wie sich ein PBI entwickelt, während es im Product Backlog aufsteigt:\nEintrag: Ein einfacher Zwei-Wort-Titel Zwei Monate später: Eine Diskussion, zusammengefasst in drei Sätzen Eine Woche später: Das Team gibt eine erste Schätzung ab Zwei Wochen später: Drei Akzeptanzkriterien werden hinzugefügt Nochmal eine Woche später: Ein UI-Sketch wird ergänzt Am nächsten Tag: Das Team schätzt das PBI neu Beachten Sie, dass ich an keiner Stelle erwähnt habe, ob dieses PBI ein Epic, ein Feature, eine User Story oder ein Task ist. Diese Klassifizierung trifft das Team basierend auf den Schätzungen.\nDas mentale Modell: PBIs und das Backlog # Hier ist ein mentales Modell, das die verschiedenen Konzepte verbindet:\nEin Epic wird durch ein oder mehrere Features realisiert Ein Feature wird durch eine oder mehrere User Stories realisiert Eine User Story wird durch einen oder mehrere Tasks implementiert Epics, Features und User Stories gehören zum Product Backlog Das Sprint Backlog ist eine Teilmenge des Product Backlogs und enthält die User Stories, die während eines Sprints implementiert werden Das Product Backlog gehört dem Product Owner Das Sprint Backlog gehört dem Entwicklungsteam \u0026ldquo;Ein Bug ist nur eine spezielle User Story. Features werden gefixt, indem ein Bug behoben wird, und der Bug wird durch die Implementierung von Tasks gefixt.\u0026rdquo;\nEinen PBI-Typ habe ich in der Visualisierung bewusst weggelassen, um es einfach zu halten: den Bug. Bugs treten auf, wenn ein Feature nicht wie erwartet funktioniert. Ein Bug ist im Grunde eine spezielle User Story. Features werden durch das Beheben von Bugs gefixt, und Bugs werden durch die Implementierung von Tasks behoben.\nKernaussagen # Ein PBI ist eine einzelne Arbeitseinheit auf dem Product Backlog. Es kann ein Epic, Feature, eine User Story oder ein Task sein.\nPBIs entwickeln sich über die Zeit durch Refinement, von vagen Ideen hin zu implementierungsbereiten Items.\nDer Product Owner ordnet das Backlog nach Risiko, Business Value, Kundenzufriedenheit und anderen Kriterien.\nTechnische und fachliche Arbeit im Gleichgewicht halten. Technische Schulden, Infrastruktur und Risiken zu ignorieren, wird das Produkt langfristig ausbremsen.\nDas mentale Modell ist einfach. Epics werden in Features aufgeteilt, Features in User Stories und User Stories in Tasks. Das Verständnis dieser Beziehungen macht das Backlog Management unkompliziert.\n","date":"28. June 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-ein-product-backlog-item-pbi/","section":"Blogs","summary":"In meinem letzten Video haben wir uns angeschaut, was ein Backlog ist. Dabei haben wir gelernt, dass ein Backlog aus Product Backlog Items besteht, kurz PBI. In diesem Video gehen wir eine Ebene tiefer und schauen uns an, was genau ein PBI ist, wie es sich über die Zeit entwickelt und wie es mit dem Product Backlog, dem Sprint Backlog und dem Product Owner zusammenhängt.\n","title":"Was ist ein Product Backlog Item (PBI)?","type":"blogs"},{"content":"In my previous video, we explored what a backlog is. We learned that a backlog consists of Product Backlog Items, short PBI. In this video, we go one level deeper and look at what exactly a PBI is, how it evolves over time, and how it relates to the product backlog, the sprint backlog, and the product owner.\nWhat is a Product Backlog Item? # A Product Backlog Item is a single element of work that exists on the product backlog. Such a PBI can take different forms: an epic, a feature, a user story, or a task. Each of these types serves a different purpose and operates at a different level of granularity. In my follow-up videos, I go through each one of these types in detail.\nThe Lifecycle of a PBI # Every Product Backlog Item follows a lifecycle. It starts when stakeholders, such as the business, clients, or the product owner, have new ideas. The new PBI is then created at the bottom of the backlog. After that, the product owner picks it up and orders it according to business value, risks, and other criteria. Together with the team, the PBI is refined step by step until it is ready for implementation. Once implemented, it becomes part of the incremental product.\n\u0026ldquo;A Product Backlog Item starts as a simple two-word title and evolves over weeks and months through discussions, estimations, and acceptance criteria until it is ready for implementation.\u0026rdquo;\nHow the Product Owner Orders the Backlog # The product owner orders PBIs according to several criteria: business risk, technical risk, business value, customer satisfaction, time criticality, implementation strategy, dependencies, infrastructure work, and reduction of technical debt.\nOne thing I see far too often is product owners who only want features, features, features, and completely ignore technical debt, infrastructure work, and technical risks. This is a dangerous pattern. You should always maintain a healthy balance between technical work and business work. If you neglect the technical side, your product will eventually reach a state where you spend all your time bug fixing and can no longer deliver new features.\nHow a PBI Evolves Over Time # Let me give you a rough example of how a PBI evolves as it moves up in the product backlog:\nEntry: A simple two-word title Two months later: A discussion summarized in three sentences One week later: The team provides a first estimation Two weeks later: Three acceptance criteria are added Another week later: A user interface sketch is added Next day: The team re-estimates the PBI Notice that at no point have I mentioned whether this PBI is an epic, a feature, a user story, or a task. That classification is something the team decides based on the estimations.\nThe Mental Model: Connecting PBIs to the Backlog # Here is a mental model that connects the different concepts:\nAn epic is realized by one or many features A feature is realized by one or many user stories A user story is implemented by one or many tasks Epics, features, and user stories belong to the product backlog The sprint backlog is a subset of the product backlog and contains the user stories to be implemented during a sprint The product backlog is owned by the product owner The sprint backlog is owned by the development team \u0026ldquo;A bug is only a special user story. Features are fixed by fixing a bug, and the bug is fixed by implementing tasks.\u0026rdquo;\nThere is one PBI type I left out of this visualization to keep it simple: the bug. Bugs occur when a feature is not working as expected. A bug is essentially a special user story. Features are fixed by fixing bugs, and bugs are fixed by implementing tasks.\nKey Takeaways # A PBI is a single unit of work on the product backlog. It can be an epic, feature, user story, or task.\nPBIs evolve over time through refinement, moving from vague ideas to implementation-ready items.\nThe product owner orders the backlog based on risk, business value, customer satisfaction, and other criteria.\nBalance technical and business work. Ignoring technical debt, infrastructure, and risks will slow down your product in the long run.\nThe mental model is simple. Epics break into features, features into user stories, and user stories into tasks. Understanding these relationships makes backlog management straightforward.\n","date":"28 June 2022","externalUrl":null,"permalink":"/en/blogs/what-is-a-product-backlog-item-pbi/","section":"Blogs","summary":"In my previous video, we explored what a backlog is. We learned that a backlog consists of Product Backlog Items, short PBI. In this video, we go one level deeper and look at what exactly a PBI is, how it evolves over time, and how it relates to the product backlog, the sprint backlog, and the product owner.\n","title":"What is a Product Backlog Item (PBI)?","type":"blogs"},{"content":"Hast du dich jemals gefragt, was \u0026ldquo;DevOps Engineers\u0026rdquo; eigentlich tun? Was bedeutet \u0026ldquo;DevOps\u0026rdquo; überhaupt? Dieser Blogbeitrag soll das Konzept von DevOps erklären und den Wert aufzeigen, den es einer Organisation bringt.\nWarum ist DevOps wichtig? # Stell dir folgende Situation vor: Ein Executive Committee trifft sich zum Quartalstreffen und der technische Leiter hört Folgendes: \u0026ldquo;Unser Plan ist es, die Plattform zu skalieren, den Umsatz in den nächsten 6 Monaten um 25% zu steigern und uns als führender Anbieter in unserem Marktsegment zu positionieren.\u0026rdquo;\nIn vielen Fällen könnte eine solche Aussage zu Angst, Panik und Stress führen. Aber mit DevOps kann ein Unternehmen Entwicklungsprozesse von der Ideenphase über die Entwicklungszyklen bis hin zur Produktion optimieren und automatisieren. Das schafft viele greifbare Vorteile:\ngesteigerte Effizienz geringere Kosten schnellere Feedback-Zyklen höhere Durchsatzgeschwindigkeit und kürzere Time-to-Market Dadurch wird das Unternehmen spürbar innovativer und kann schneller auf Kundenanfragen reagieren.\nWas ist DevOps überhaupt? # Ursprünglich wurde \u0026ldquo;DevOps\u0026rdquo; als Bezeichnung für eine Entwicklungsmethodik geprägt, die Softwareentwicklung und Softwarebetrieb verbindet und folgende Prinzipien mit sich bringt:\nganzheitlicher Systemansatz keine Silos zwischen Disziplinen kurze und schnelle Feedback-Schleifen kollektives Code-Ownership Die Anwendung dieser Prinzipien ist offen für Interpretation, was zu einer Vielzahl von Methoden und Tools geführt hat, die alle behaupten, das \u0026ldquo;DevOps-Rätsel\u0026rdquo; zu lösen. Ausserdem hat die allgemeine Anwendbarkeit dieser Prinzipien in anderen Bereichen zu einer Fülle neuer Akronyme wie DevSecFinHugOps geführt.\nDevOps ist keine Jobbeschreibung und keine Disziplin. DevOps ist ein Mindset, eine Kultur und eine Reihe von technischen Praktiken. Daher die Anführungszeichen um \u0026ldquo;DevOps Engineers\u0026rdquo; in diesem Artikel.\nIm Rahmen dieser neuen Philosophie sind kulturelle Transformation und Veränderungen in der Arbeitsweise von zentraler Bedeutung. Es geht nicht mehr um \u0026ldquo;die\u0026rdquo; (Entwicklung und Betrieb), sondern um \u0026ldquo;uns\u0026rdquo; (alle am Wertstrom Beteiligten). Teamarbeit ist das Fundament von DevOps. Gegenseitiges Vertrauen, Empowerment, Verantwortung, kontinuierliche Verbesserung, datenbasierte Entscheidungsfindung und Kundenempathie sind die DevOps-Werte.\nFür Zühlke bedeutet DevOps: Alle Menschen, Prozesse und Technologien zusammenbringen, um unseren Kunden kontinuierlich Mehrwert zu liefern!\nWas ist das Ziel von DevOps? # DevOps bietet Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen Beteiligten, die für Planung, Entwicklung, Test, Deployment, Release und Wartung eines Produkts benötigt werden. Es ermöglicht einer Organisation im Wesentlichen:\nschnellere Time-to-Market fundiertes Experimentieren kleine und häufige Software-Releases kürzere Fehlerbehebungszeiten verbesserte mittlere Wiederherstellungszeit Wer ist DevOps? # In Bezug auf die Menschen sind es alle, die zum Wertstrom beitragen. Die DevOps-Praxis arbeitet nicht in einem Silo, sondern fungiert als Enabler für die Zusammenarbeit über viele Disziplinen hinweg.\nWelche Skills haben DevOps Engineers? # Die grundlegende Fähigkeit ist es, DevOps zu verstehen. Ein \u0026ldquo;DevOps Engineer\u0026rdquo; muss ein DevOps-Mindset haben und die DevOps-Kultur vollständig leben können.\nVorerfahrung als Software Developer oder System Administrator ist natürlich von Vorteil. Wer programmieren kann, beherrscht die Automatisierungsaspekte von DevOps leichter. Andererseits ist auch ein System-Engineering-Hintergrund nützlich, da er Vertrautheit mit Infrastruktur mitbringt, etwas, das von Softwareentwicklern oft übersehen wird.\nAllerdings ist vorherige technische Erfahrung nicht der einzige Weg in DevOps. Es gibt viele andere Möglichkeiten wie:\nBootcamps Selbststudium Wechsel aus anderen Rollen Mentoring oder Einstieg bei aufgeschlossenen Organisationen (die alternative Ausbildungswege unterstützen) Bei Zühlke dreht sich die Arbeit als \u0026ldquo;DevOps Engineer\u0026rdquo; nicht nur um Technologie, Automatisierung und Tools. Es gibt auch andere Fähigkeiten, die sehr geschätzt werden:\nCode-Verständnis über mehrere Programmiersprachen hinweg Gutes Zuhören: Du musst auf die Wünsche und Anforderungen deines Entwicklungsteams eingehen. Geduld und Ausdauer: Wir sind ein Team, und wir wollen alles stabil, performant und am liebsten schon gestern fertig. Wie man ein erfolgreicher DevOps Engineer wird\nAber was machen \u0026ldquo;DevOps Engineers\u0026rdquo; den ganzen Tag wirklich? # \u0026ldquo;DevOps Engineers\u0026rdquo; stellen sicher, dass die Arbeit reibungslos durch den gesamten Wertstrom fliesst und geben Unternehmen damit einen Wettbewerbsvorteil. Dafür ist Kontext entscheidend, denn ihre Arbeit schafft je nach Betriebsumgebung unterschiedlichen Mehrwert. Typische Arbeitsbereiche sind:\nTeilnahme an Discoveries: Eine Projektphase, in der Zühlke seinen Kunden hilft, das Richtige zu bauen. Aufbau von Minimum Viable Products Durchführung von Architektur-Assessments Cloud-Native-Projekte On-Premises-Projekte Jeden Aspekt von DevOps bei Zühlke aufzulisten, würde den Rahmen dieses Blogbeitrags sprengen. Hier sind jedoch einige Beispiele typischer Aufgaben:\nEine Continuous-Delivery-Pipeline aufbauen, damit das Team kontinuierlich Mehrwert liefern und Feedback erhalten kann. Prozesse definieren, um zu einem gemeinsamen Systemansatz zu gelangen. Automatisierung über repetitive, manuelle Aufgaben stellen: In einem hoch oder vollständig automatisierten System kann jedes Teammitglied komplexe und spezialisierte Operationen durchführen. Konsistenz über die Entwicklerumgebung, die Testumgebungen und die Produktionsumgebung hinweg sicherstellen. Geschäftsanforderungen und Initiativen unterstützen, um Innovation und Geschäftsentwicklung zu ermöglichen. Fazit # Im Allgemeinen ist DevOps ein gemeinsamer Ansatz über ein gesamtes Entwicklungsteam hinweg und beruht oft auf einer gemeinsamen Vereinbarung, wie der Entwicklungsprozess angegangen werden soll. Wenn eine Organisation DevOps als Herzstück ihrer Geschäftsstrategie annimmt, ermöglicht das eine schnellere und sicherere Produktion sowie die Fähigkeit, Ziele konsistenter zu erreichen. Es erlaubt den Geschäftseinheiten auch, neue Ideen zu erkunden und letztlich zu innovieren.\nMehr über unsere DevOps Job World erfahren\nOriginalbeitrag: Zühlke | Medium\n","date":"17. June 2022","externalUrl":null,"permalink":"/de/blogs/devops-erklaert-was-machen-devops-engineers-bei-zuehlke/","section":"Blogs","summary":"Hast du dich jemals gefragt, was “DevOps Engineers” eigentlich tun? Was bedeutet “DevOps” überhaupt? Dieser Blogbeitrag soll das Konzept von DevOps erklären und den Wert aufzeigen, den es einer Organisation bringt.\n","title":"DevOps erklärt: Was machen \"DevOps Engineers\" eigentlich bei Zühlke?","type":"blogs"},{"content":"Have you ever wondered what “DevOps Engineers” actually do? What does “DevOps” even mean actually? This blog post aims to explain the concept of DevOps and the value that it\nbrings to an organisation.\nWhy is DevOps important? # Picture the scene: An executive committee meets for a quarterly meeting and the technical lead overhears this: “Our plan is to scale the platform, drive 25% increased revenue in the next 6 months and to position ourselves as the go-to provider in our market sector”.\nIn a lot of cases, a statement like that could lead to fear, panic and stress. But with DevOps, a company can optimise and automate development processes from the ideas stage through the development cycles and onwards through to production. This creates a lot of tangible benefits:\nincreased efficiency lower costs increased feedback cycles increased throughput speed and time-to-market. As a result, the company becomes perceptibly more innovative and can react more quickly to customer requests.\nWhat is DevOps anyway? # Originally “DevOps” was coined as a label for a development methodology that bridged software development and software operations, and brought with it the following set of principles:\nholistic system approach no silos between disciplines short and fast feedback loops collective code ownership. The application of these principles is open to interpretation, leading to a variety of methodologies and tools all claiming to \u0026ldquo;solve the DevOps\u0026rdquo; enigma. Also, the general applicability of these principles in other areas has resulted in a plethora of new acronyms such as DevSecFinHugOps.\nDevOps is not a job description, or a discipline. DevOps is a mindset, a culture, and a set of technical practices, hence the quotation marks around “DevOps Engineers\u0026quot; in this article.\nAs part of this new philosophy, cultural transformation and changes in how we work are of central significance. It’s no longer about “them” (development and operation), but about “us” (everyone involved in the value stream). Teamwork is the foundation of DevOps. Mutual trust, empowerment, responsibility, continuous improvement, data-based decision-making and customer empathy are the DevOps values.\nFor Zühlke, DevOps means: Bringing all the people, processes, and technology together to continuously deliver value to our customers!\nWhat is the goal of DevOps? # DevOps provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a product. It essentially empowers an organisation with:\nfaster time to market Informed experimentation small and frequent software releases shorter fix lead times Improve the meantime for recovery Who is DevOps? # In people terms, this is everyone that contributes to the value stream. The DevOps practice does not operate in a silo, but rather functions as the enabler of collaboration across many disciplines.\nWhat skills do DevOps Engineers have? # The fundamental skill is to understand DevOps. A \u0026ldquo;DevOps Engineer\u0026rdquo; must have a DevOps mindset and be able to completely embrace the DevOps culture.\nPrior experience as a Software Developer or System Administrator is clearly advantageous. If you know how to code, you can easily master the automation aspects of DevOps. On the other hand, a System Engineering background is also useful as it brings a familiarity with infrastructure, something often overlooked by software programmers.\nHaving said all of that, prior technical experience is not the only way into DevOps. There are many other possibilities such as\nbootcamps self-learning transitioning from other roles mentoring or joining open-minded organisations (that support alternative education paths). At Zühlke, when working as a \u0026ldquo;DevOps Engineer\u0026rdquo;, your work not only revolves around technology, automation and tools, there are also other skills that are highly valued:\nCode comprehension across multiple programming languages. Good listening skills: You will have to respond to the whims and wishes of your development team. Patience and perseverance: We are one team, and we want everything stable, well performing, and ready yesterday. How to become a successful DevOps Engineer\nBut what do \u0026ldquo;DevOps Engineers\u0026rdquo; really do all day long? # “DevOps Engineers” ensure work flows smoothly through the entire value stream, giving businesses a competitive advantage. For this to happen, context is key because their work yields different value depending on operating environment. Some typical work areas include:\nParticipating in discoveries: A project phase where Zühlke helps its clients to define the right thing to build. Building minimum viable products. Conducting architectural assessments. Cloud Native projects. On-premises projects. Listing every aspect of DevOps at Zühlke is beyond the scope of this blog post. Nevertheless, here are some examples of typical tasks:\nBuild a continuous delivery pipeline so that the team can continuously deliver value and receive feedback. Define processes to arrive at a common system approach. Prioritise automation over repetitive, manual tasks: In a highly or fully automated system, any team member can perform complex and specialised operations. Keep consistency across the developer’s environment, the test environments, and the production environment. Support business needs and initiatives to enable innovation and business development. Conclusion # In general DevOps is a shared approach across an entire development team, and often comes down to a shared agreement on how to tackle the development process. When an organisation embraces DevOps at the heart of its business development strategy, it empowers faster and safer production, and the ability to reach goals more consistently. It also allows business units to explore new ideas, and ultimately to innovate.\nLearn more about our DevOps Job World\nOriginal Post: Zühlke | Medium\n","date":"17 June 2022","externalUrl":null,"permalink":"/en/blogs/devops-explained-what-do-devops-engineers-actually-do-at-zuehlke/","section":"Blogs","summary":"Have you ever wondered what “DevOps Engineers” actually do? What does “DevOps” even mean actually? This blog post aims to explain the concept of DevOps and the value that it\n","title":"DevOps Explained: What do \u0026quot;DevOps Engineers\u0026quot; actually do at Zühlke?","type":"blogs"},{"content":"","date":"17 June 2022","externalUrl":null,"permalink":"/en/tags/job-description/","section":"Tags","summary":"","title":"Job Description","type":"tags"},{"content":"","date":"17. June 2022","externalUrl":null,"permalink":"/de/tags/jobbeschreibung/","section":"Tags","summary":"","title":"Jobbeschreibung","type":"tags"},{"content":"","date":"17 June 2022","externalUrl":null,"permalink":"/en/tags/platform/","section":"Tags","summary":"","title":"Platform","type":"tags"},{"content":"","date":"17. June 2022","externalUrl":null,"permalink":"/de/tags/plattform/","section":"Tags","summary":"","title":"Plattform","type":"tags"},{"content":"","date":"17 June 2022","externalUrl":null,"permalink":"/en/tags/skills/","section":"Tags","summary":"","title":"Skills","type":"tags"},{"content":"","date":"15 June 2022","externalUrl":null,"permalink":"/en/tags/continuous-exploration/","section":"Tags","summary":"","title":"Continuous Exploration","type":"tags"},{"content":"","date":"15 June 2022","externalUrl":null,"permalink":"/en/tags/devops-health-radar/","section":"Tags","summary":"","title":"DevOps Health Radar","type":"tags"},{"content":"","date":"15 June 2022","externalUrl":null,"permalink":"/en/tags/release-on-demand/","section":"Tags","summary":"","title":"Release on Demand","type":"tags"},{"content":"Over the past few years I have published a deep-dive on every single activity in the SAFe DevOps Health Radar. This post is the round-the-radar tour: a single page that walks you through all four aspects and all sixteen stages, with the original video for each and a link to the full article. Use it as a map — to find your starting point, to share with your team, or to assess where you are today and where you want to go next.\nPlease note that everything here is based on the Scaled Agile Framework, which is a toolbox. Take what fits your needs and what solves your problems.\nWhat is the SAFe DevOps Health Radar? # The SAFe DevOps Health Radar is both an assessment and a process. As an assessment it lets you score your team or value stream from Sit to Fly across sixteen activities and visualise the result as a spider diagram. As a process it describes the full continuous delivery pipeline that turns an idea from the customer into validated value back to the customer.\nThe radar is structured around four aspects: Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand. Each aspect contains four activities. Together they form the loop that lets you build the right thing, build it right, and learn from what you released. Read the full overview\nContinuous Exploration # The first aspect is where bright ideas from the customer and the business become validated epics with a clear hypothesis, a real customer need behind them, a minimal architecture to prove them, and a prioritised set of features ready for development. The goal of this aspect is alignment between stakeholders so that we build the right thing.\nRead the full overview\nHypothesize # Take an idea, turn it into an epic with an Epic Hypothesis Statement, define the MVP, and identify the leading indicators that will tell you whether the hypothesis holds. Read more\nCollaborate and Research # Conduct market and customer research, interview real users, and verify that you are solving the actual underlying problem instead of building what someone happened to ask for. Read more\nArchitect # Define the minimal architecture needed to prove the hypothesis. Not the final architecture — the simplest one that lets you validate. Architect for operability from the start. Read more\nSynthesize # Pull it all together: a vision, a roadmap, and a clear set of prioritised features (plus enabler features for the architectural runway) ready for the program backlog. Read more\nContinuous Integration # The second aspect takes prioritised features from the backlog, breaks them into user stories, develops them, and produces verified deployable artifacts in a staging environment. This is where built-in quality, fast feedback loops, and small batch sizes become real engineering practice. Read the full overview\nDevelop # Break features into user stories, implement them, commit code to version control, and pair, peer-review, and test as you go so quality is built in, not bolted on later. Read more\nBuild # Continuously integrate every commit, run unit tests, run static code and security analysis, and produce a deployable artifact. Use gated commits to keep the trunk green. Read more\nTest End-to-End # Run automated functional and non-functional tests across the full system to verify the artifact behaves as expected before it leaves the integration environment. Read more\nStage # Deploy the verified artifact to a production-like staging environment for the final round of validation before it is allowed into production. Read more\nContinuous Deployment # The third aspect takes verified artifacts from staging and brings them into production continuously, with the feature toggle off. This is where deployment is separated from release: the change is in production, ready, but invisible to users until the business decides the time is right.\nRead the full overview\nVerify # Once the artifact is in production, run a subset of the integration tests against it. If anything fails, roll back immediately to the latest stable version. Read more\nDeploy # Bring the compiled code into production with the feature toggle off. This enables dark launches, where new functionality is live but not yet visible. Read more\nMonitor # Use the logging and telemetry built in during Architect and Develop to observe application health, system performance, user behaviour, incidents, and business value in real time. Read more\nRespond # Set carefully designed thresholds on top of monitoring, rehearse disaster recovery, collaborate across teams when something happens, and fix forward or roll back fast. Read more\nRelease on Demand # The fourth aspect is what happens after the business says \u0026ldquo;the time is right\u0026rdquo; and the feature toggle goes on. It is also where the loop closes: we stabilise, we measure, we learn, and we feed everything back into the next round of Continuous Exploration.\nRead the full overview\nRelease # Switch the feature toggle on so users can actually access the new functionality. Use techniques like canary releases, blue-green deployments, and progressive rollouts to keep risk low. Read more\nStabilize # Ensure business continuity with disaster recovery, security monitoring (SIEM), continuous monitoring of non-functional requirements, and SLIs, SLOs, and SLAs. SRE plays a key role at high availability targets. Read more\nMeasure # Collect both qualitative and quantitative feedback to validate the epic and feature benefit hypotheses. Watch out for vanity metrics and focus on leading indicators that reflect real value. Read more\nLearn # Make the pivot-or-persevere decision based on data, ignore sunk costs, run value stream mapping every quarter, and feed retrospectives and post-mortems back into the pipeline for relentless improvement. Read more\nHow to use this tour # If you have never seen the radar before, start at the top with the overview post and work your way down. If you already know the radar and want to assess your team, walk the four aspects in order, score yourself on each of the sixteen stages from Sit to Fly, and add a second column for where you want to be in twelve months. The gap is your transformation backlog.\nIn many cases you do not need to be a Fly in every activity. A three or even a two is perfectly acceptable, depending on your context. The point is not to maximise every score — it is to identify the bottlenecks that hold back your flow of value and to invest deliberately in closing the gaps that matter.\nKey Takeaways # The radar is both an assessment and a process. Use it to score your current state and to understand the full continuous delivery pipeline from idea to learning. Sixteen stages, four aspects. Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand each contain four activities that build on the previous one. Separate deployment from release. This single principle — feature toggles, dark launches, release on demand — is what makes high frequency, low risk delivery possible. Architect for operability early. Logging, telemetry, feature toggles, and recovery mechanisms must be built in from the start; they are what make Monitor, Respond, and Stabilize work. Close the loop with Measure and Learn. A change that goes to production without validated learning is just shipped code; the radar is designed so insights flow back into the next hypothesis. You do not need to be a Fly everywhere. Pick the gaps that matter for your value stream, and use the radar to align the conversation between business, engineering, and operations. ","date":"15 June 2022","externalUrl":null,"permalink":"/en/blogs/devops-health-radar-tour/","section":"Blogs","summary":"Over the past few years I have published a deep-dive on every single activity in the SAFe DevOps Health Radar. This post is the round-the-radar tour: a single page that walks you through all four aspects and all sixteen stages, with the original video for each and a link to the full article. Use it as a map — to find your starting point, to share with your team, or to assess where you are today and where you want to go next.\n","title":"Tour Around the SAFe DevOps Health Radar: All 16 Stages with Videos","type":"blogs"},{"content":"","date":"6 June 2022","externalUrl":null,"permalink":"/en/tags/sprint-backlog/","section":"Tags","summary":"","title":"Sprint Backlog","type":"tags"},{"content":"Was ist ein Backlog und warum ist Backlog Management so wichtig in der agilen Softwareentwicklung? In diesem Video erkläre ich das Konzept eines Backlogs, den Unterschied zwischen Product Backlog und Sprint Backlog und zeige, wie Tools wie Jira das Backlog Management in der Praxis unterstützen.\nDas Backlog in seiner einfachsten Form # Ein Backlog in seiner einfachsten Form ist nichts anderes als eine geordnete Liste offener Arbeit. Oben befinden sich die am besten verfeinerten Items, unten die noch undefinierten. Es gibt zwei Haupttypen von Backlogs: das Product Backlog und das Sprint Backlog. Bei skalierter Agilität gibt es zusätzlich das Portfolio Backlog, das ich in einem separaten Video behandle.\nDas Product Backlog # Das Product Backlog ist eine geordnete Liste offener Arbeit für ein bestimmtes Produkt. Oben stehen die verfeinerten Items, unten die weniger oder noch gar nicht verfeinerten. Es besteht aus Product Backlog Items, die alle geordnet sind. Die Items ganz oben sind geschätzt.\nDer Product Owner kümmert sich gemeinsam mit dem Team um das Product Backlog. Ein Product Backlog ist immer transparent und öffentlich zugänglich. Der Product Owner priorisiert die Product Backlog Items und hat das letzte Wort bei der Priorisierung. Weil sich ein Produkt weiterentwickelt, ist ein Product Backlog nie vollständig. Es entwickelt sich über die Zeit.\n\u0026ldquo;Ein Product Backlog ist nie vollständig. Es entwickelt sich über die Zeit, genau wie das Produkt, das es repräsentiert.\u0026rdquo;\nDas Sprint Backlog # Ein Sprint Backlog ist eine Auswahl von Product Backlog Items, die in einen Sprint aufgenommen werden. Es ist nichts anderes als der Plan des Entwicklungsteams, diese Product Backlog Items umzusetzen. Das Sprint Backlog gehört vollständig dem Entwicklungsteam. Nur das Entwicklungsteam kann das Sprint Backlog während eines Sprints ändern.\nIch höre schon die Beschwerden der Product Owner da draussen, die im Grunde nur verkleidete Projektmanager sind. Ja, wenn man wirklich agil sein will, muss das Entwicklungsteam das Sprint Backlog besitzen. Nur sie können es ändern, gemeinsam mit dem Product Owner wenn nötig, aber es bleibt der Plan des Entwicklungsteams.\nIn seiner einfachsten Form hat ein Sprint Backlog drei Spalten: \u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;Doing\u0026rdquo; und \u0026ldquo;Done\u0026rdquo;. Man kann es so kompliziert machen, wie man möchte, aber das ist die Kernstruktur.\nTools für Backlog Management # Es gibt viele Tools für Backlog Management. Wenn man sich die Periodic Table of DevOps Tools anschaut, findet man dort die relevanten Tools für das Backlog Management einzelner Teams. Jira ist eines der am häufigsten verwendeten. In Jira sieht man das Product Backlog unten und das Sprint Backlog oben, mit Items, die aus dem Product Backlog in den Sprint zugewiesen wurden. Sobald man einen Sprint startet, arbeitet man am Sprint Backlog mit seinen Spalten \u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;In Progress\u0026rdquo; und \u0026ldquo;Done\u0026rdquo;.\nKernaussagen # Ein Backlog ist eine geordnete Liste offener Arbeit. Verfeinerte Items stehen oben, undefinierte unten.\nProduct Backlog vs. Sprint Backlog. Das Product Backlog umfasst alle offene Arbeit für ein Produkt. Das Sprint Backlog ist eine Auswahl für den aktuellen Sprint.\nDer Product Owner priorisiert das Product Backlog und hat das letzte Wort. Das Entwicklungsteam besitzt das Sprint Backlog.\nEin Product Backlog ist nie vollständig. Es entwickelt sich kontinuierlich weiter, so wie das Produkt selbst.\nEinfach halten. Ein Sprint Backlog mit drei Spalten (\u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;Doing\u0026rdquo;, \u0026ldquo;Done\u0026rdquo;) reicht für den Anfang vollkommen aus.\n","date":"6. June 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-ein-backlog/","section":"Blogs","summary":"Was ist ein Backlog und warum ist Backlog Management so wichtig in der agilen Softwareentwicklung? In diesem Video erkläre ich das Konzept eines Backlogs, den Unterschied zwischen Product Backlog und Sprint Backlog und zeige, wie Tools wie Jira das Backlog Management in der Praxis unterstützen.\n","title":"Was ist ein Backlog?","type":"blogs"},{"content":"What is a backlog, and why is backlog management so important in agile software development? In this video, I break down the concept of a backlog, explain the difference between a product backlog and a sprint backlog, and show how tools like Jira support backlog management in practice.\nThe Backlog in its Simplest Form # A backlog in its simplest form is just an ordered list of open work. On top, we have the most refined items. On the bottom, we have the undefined items. There are two main types of backlogs: the product backlog and the sprint backlog. If you are doing scaled agility, there is also the portfolio backlog, which I cover in a separate video.\nThe Product Backlog # The product backlog is an ordered list of open work for a specific product. On top, we have the refined items. On the bottom, we have the less refined or not yet refined items. It consists of product backlog items, all of which are ordered. The items at the top are estimated.\nThe product owner takes care of the product backlog together with the team. A product backlog is always transparent and publicly available. The product owner prioritizes the product backlog items and has the final say about the priority. Because a product evolves, a product backlog is never complete. It evolves over time.\n\u0026ldquo;A product backlog is never complete. It evolves over time, just like the product it represents.\u0026rdquo;\nThe Sprint Backlog # A sprint backlog is a selection of product backlog items that go into a sprint. It is nothing more than a plan of the development team to deliver these product backlog items. The sprint backlog is completely owned by the development team. Only the development team can change the sprint backlog during a sprint.\nI can already hear the complaints from the product owners out there who are basically project managers in disguise. Yes, if you want to be truly agile, the development team needs to own the sprint backlog. Only they can change it, together with the product owner if needed, but it remains a plan of the development team.\nIn its simplest form, a sprint backlog has three columns: \u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;Doing\u0026rdquo;, and \u0026ldquo;Done\u0026rdquo;. You can make it as complicated as you like, but in the end, that is the core structure.\nTools for Backlog Management # There are many tools out there for backlog management. When looking at the periodic table of DevOps tools, you find the relevant tools for single-team backlog management. Jira is one of the most commonly used ones. In Jira, you can see the product backlog at the bottom and the sprint backlog at the top, with items assigned from the product backlog into the sprint. Once you start a sprint, you work on the sprint backlog with its \u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;In Progress\u0026rdquo;, and \u0026ldquo;Done\u0026rdquo; columns.\nKey Takeaways # A backlog is an ordered list of open work. Refined items sit on top, undefined items at the bottom.\nProduct backlog vs. sprint backlog. The product backlog covers all open work for a product. The sprint backlog is a subset selected for the current sprint.\nThe product owner prioritizes the product backlog and has the final say. The development team owns the sprint backlog.\nA product backlog is never complete. It evolves continuously as the product evolves.\nKeep it simple. A sprint backlog with three columns (\u0026ldquo;To Do\u0026rdquo;, \u0026ldquo;Doing\u0026rdquo;, \u0026ldquo;Done\u0026rdquo;) is all you need to get started.\n","date":"6 June 2022","externalUrl":null,"permalink":"/en/blogs/what-is-a-backlog/","section":"Blogs","summary":"What is a backlog, and why is backlog management so important in agile software development? In this video, I break down the concept of a backlog, explain the difference between a product backlog and a sprint backlog, and show how tools like Jira support backlog management in practice.\n","title":"What is a Backlog?","type":"blogs"},{"content":"","date":"11 May 2022","externalUrl":null,"permalink":"/en/tags/feature-toggles/","section":"Tags","summary":"","title":"Feature Toggles","type":"tags"},{"content":"Release on Demand ist der letzte Schritt in der SAFe for DevOps Continuous Delivery Pipeline, und es ist der Schritt, der alles zusammenführt. In diesem Video erkläre ich, wie Release on Demand funktioniert, warum die Trennung von Deployment und Release so wirkungsvoll ist und wie die gesamte Pipeline Organisationen befähigt, das Richtige richtig zu bauen.\nDie Continuous Delivery Pipeline # Bevor wir zu Release on Demand kommen, möchte ich den Kontext setzen. Die Continuous Delivery Pipeline besteht aus vier grossen Phasen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand.\nAlles beginnt mit guten Ideen vom Business oder vom Kunden. Wir extrahieren die Hypothese hinter jeder Idee und erfassen sie in einem Epic Hypothesis Statement. In der Continuous Exploration arbeiten wir zusammen, um das echte Kundenbedürfnis zu identifizieren, die minimale Architektur zu entwerfen und das Epic in Features für das Backlog herunterzubrechen.\nIn der Continuous Integration werden Features in User Stories zerlegt, entwickelt, in die Versionskontrolle committed, gebaut, mit statischer Analyse und Unit Tests getestet. Das resultierende deploybare Artefakt wird End-to-End getestet und in eine Staging-Umgebung für die finale Validierung deployed.\nIm Continuous Deployment deployen wir unsere Änderungen kontinuierlich in die Produktion, mit dem Feature Toggle ausgeschaltet. Wir überprüfen, dass alles funktioniert, und bauen Monitoring und Alerting auf, um auf alles reagieren zu können.\nWas Release on Demand besonders macht # Hier wird es spannend. Zu diesem Zeitpunkt haben wir neue Funktionalität kontinuierlich in die Produktion deployed, aber mit dem Feature Toggle ausgeschaltet. Kein Kunde sieht sie noch. Jetzt liegt es am Business zu entscheiden, wann der richtige Zeitpunkt ist, die neue Funktionalität freizugeben.\nNeue Funktionalität freizugeben ist eine Geschäftsentscheidung. Das Business entscheidet, wann, für welche Nutzer und für wie viele Nutzer released wird.\nDas ist das grundlegende Prinzip: Deployment und Release sind getrennte Aktivitäten. Deployment bringt kompilierten Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Diese Trennung macht Release on Demand möglich.\nDie vier Aktivitäten von Release on Demand # Release on Demand besteht aus vier Aktivitäten:\nRelease: Wenn das Business sagt, der Zeitpunkt ist richtig, schalten wir den Feature Toggle ein. Das kann innerhalb von Sekunden geschehen. Die neue Funktionalität wird für eine Teilmenge der Nutzer oder für alle Nutzer verfügbar.\nStabilize: Nach dem Release überwachen wir das System genau und reagieren auf alle Alerts. Wir betreiben und stabilisieren die Produktionsumgebung, um sicherzustellen, dass wir unsere SLAs erfüllen.\nMeasure: Wir gehen zurück zur Hypothese, die wir in der Explorationsphase identifiziert haben. Wir hatten auch Leading Indicators definiert, die uns zeigen, ob die Hypothese wahr oder falsch ist. Jetzt messen wir den tatsächlichen Geschäftswert und alle Daten, die zeigen, ob unsere Hypothese standhält.\nLearn: Mit den Messdaten entscheiden wir, ob wir mehr oder weniger in dieses Epic investieren. Sollen wir weitermachen? Sollen wir stoppen? Sollen wir mehr Features umsetzen oder aufhören? Diese Informationen fliessen zurück in die Continuous Exploration, wo wir neue Hypothesen oder neue Features basierend auf dem Gelernten erstellen.\nWie schnell kann dieser Zyklus sein? # Diese Frage bekomme ich oft gestellt: Wie gross ist die Lead Time für den gesamten Zyklus? Die Antwort hängt von der Grösse der Idee ab.\nEin konkretes Beispiel: Stellen wir uns vor, wir haben eine Website, und Kunden geben das Feedback, dass der Workflow zu lang ist. Sie wünschen sich einen schnelleren Workflow. Wir erstellen eine Hypothese, identifizieren das Kundenbedürfnis, entwerfen die minimale Architektur, brechen es in Features und User Stories herunter, entwickeln den Code, committen, bauen, testen, deployen in die Staging-Umgebung und deployen kontinuierlich in die Produktion mit dem Feature Toggle ausgeschaltet.\nBis zu diesem Punkt wurde keine neue Funktionalität an Kunden geliefert. Wir sind nur durch die Pipeline gegangen. Dieser gesamte Zyklus von der Exploration bis zum Deployment kann an einem einzigen Tag geschafft werden, wenn man sehr schnell ist. Üblicherweise dauert es aber einen Sprint (zwei Wochen) oder zwei Sprints (etwa vier Wochen).\nNun ist die Funktionalität bereits in der Produktion. Wenn das Business \u0026ldquo;los\u0026rdquo; sagt, schalten wir den Feature Toggle ein. Das dauert Sekunden. Die Lead Time für kleine Ideen kann also nur eine Stunde betragen. Für grössere Ideen vielleicht einen Tag. Für noch grössere einen Zwei-Wochen-Sprint. Und für Ideen mit mehreren Features kann man inkrementell deployen und Features einzeln mit Feature Toggles aktivieren.\nDer Geschäftswert von Release on Demand # Das Ergebnis von Release on Demand ist klar: Sie haben Funktionalität released und Geschäftswert an Ihre Kunden geliefert. Was Sie sicherstellen müssen, ist, dass Ihre Produktionsumgebung stabil, zuverlässig, verfügbar, wartbar und sicher bleibt. Sie müssen Ihre SLOs und SLAs erfüllen.\nWährend Release on Demand sammeln Sie sowohl qualitatives als auch quantitatives Feedback von Kunden und von Ihrem Monitoring-System. Dieses Feedback sagt Ihnen, ob die Hypothese hinter der Idee gültig ist. Es befähigt Sie, fundierte Entscheidungen zu treffen, ob Sie mehr oder weniger in Epics und Features investieren.\nDurch das Deployment kleiner Mengen neuer Funktionalität mit ausgeschaltetem Feature Toggle bleibt das Risiko gering. Und das Business bekommt die Möglichkeit zu entscheiden, wann der Zeitpunkt richtig ist, um den Impact neuer Funktionalität und den Wert für Nutzer zu maximieren.\nKernaussagen # Deployment und Release trennen. Deployment bringt Code in die Produktion mit ausgeschaltetem Feature Toggle. Release schaltet den Toggle ein. Diese Trennung gibt dem Business die Kontrolle über den Zeitpunkt. Release ist eine Geschäftsentscheidung. Das Business entscheidet wann, für wen und wie breit neue Funktionalität released wird. Feature Toggles sind der Enabler. Sie ermöglichen Canary Releases, Dark Launches und inkrementelle Rollouts bei niedrigem Risiko. Hypothesen messen. Leading Indicators nutzen, um die ursprüngliche Hypothese basierend auf echten Kundendaten zu validieren oder zu widerlegen, nicht auf Annahmen. Die gesamte Pipeline ist ein Lernkreislauf. Von der Hypothese über Release, Messung bis zum Lernen: alles fliesst zurück in die Exploration und befähigt, das Richtige richtig zu bauen. Lead Time hängt vom Umfang ab. Kleine Änderungen können in einer Stunde durch die Pipeline fliessen. Grössere Features brauchen einen Sprint. Die Pipeline unterstützt beides. ","date":"11. May 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-release-on-demand/","section":"Blogs","summary":"Release on Demand ist der letzte Schritt in der SAFe for DevOps Continuous Delivery Pipeline, und es ist der Schritt, der alles zusammenführt. In diesem Video erkläre ich, wie Release on Demand funktioniert, warum die Trennung von Deployment und Release so wirkungsvoll ist und wie die gesamte Pipeline Organisationen befähigt, das Richtige richtig zu bauen.\n","title":"Was ist Release on Demand?","type":"blogs"},{"content":"Release on Demand is the final step in the SAFe for DevOps continuous delivery pipeline, and it is the step that ties everything together. In this video, I walk through how Release on Demand works, why separating deployment from release is so powerful, and how the whole pipeline enables organizations to build the right thing right.\nThe Continuous Delivery Pipeline # Before we get to Release on Demand, let me set the stage. The continuous delivery pipeline consists of four major phases: Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand.\nIt all starts with bright ideas from the business or the customer. We extract the hypothesis behind each idea and capture it in an epic hypothesis statement. In Continuous Exploration, we collaborate and research to identify the real customer need, architect the minimal amount needed to prove the hypothesis, and then break down the epic into features for the backlog.\nIn Continuous Integration, features are broken into user stories, developed, committed to version control, built, tested with static analysis and unit testing, and the resulting deployable artifact is tested end-to-end and deployed to a staging environment for final validation.\nIn Continuous Deployment, we continuously deploy our changes into production with the feature toggle off. We verify that everything works, and we build up monitoring and alerting to respond to anything that happens.\nWhat Makes Release on Demand Special # Here is where it gets interesting. At this point, we have continuously deployed new functionality into production, but with the feature toggle off. No customer sees it yet. Now it is up to the business to decide when the time is right to release the new functionality.\nReleasing new functionality is a business decision. The business decides when to release, to which users, and how many users.\nThis is the fundamental principle: deployment and release are separate activities. Deployment is bringing compiled code into production with the feature toggle off. Release is switching the feature toggle on. This separation is what makes Release on Demand possible.\nThe Four Activities of Release on Demand # Release on Demand consists of four activities:\nRelease: When the business says the time is right, we switch on the feature toggle. This can happen within seconds. The new functionality becomes available to a subset of users or to all users.\nStabilize: After release, we closely monitor the system and respond to any alerts. We operate and stabilize the production environment to ensure we meet our SLAs.\nMeasure: We go back to the hypothesis that we identified in the exploration phase. We also identified leading indicators that tell us whether the hypothesis is true or false. Now we measure the actual business value and all the data that shows whether our hypothesis holds up.\nLearn: With the measurement data, we decide whether to invest more or less in this epic. Should we continue? Should we stop? Should we implement more features, or should we halt? This information flows back into Continuous Exploration, where we might create new hypotheses or new features based on what we have learned.\nHow Fast Can This Cycle Be? # I get asked this question often: what is the lead time for the whole cycle? The answer depends on the size of the idea.\nLet me walk through a concrete example. Imagine we have a website, and customers give feedback that the workflow is too long. They want a faster workflow. We create a hypothesis, identify the customer need, architect the minimal amount needed, break it into features and user stories, develop the code, commit it, build it, test it, deploy it to staging, and continuously deploy it to production with the feature toggle off.\nUntil this point, no new functionality has been delivered to any customer. We have just gone through the pipeline. This whole cycle from exploration through deployment can be done in a maximum of a day if you are very fast, but usually it takes one sprint (two weeks) or two sprints (about four weeks).\nNow the functionality is already in production. When the business says \u0026ldquo;go,\u0026rdquo; we switch on the feature toggle. This takes seconds. So the lead time for small ideas can be as short as an hour. For bigger ideas, perhaps a day. For larger ones, a two-week sprint cycle. And for ideas consisting of multiple features, you can deploy incrementally and enable features one by one with feature toggles.\nThe Business Value of Release on Demand # The output of Release on Demand is clear: you have released functionality and delivered business value to your customers. What you want to ensure during this process is that your production environment remains stable, reliable, available, supportable, and secure. You need to meet your SLOs and SLAs.\nDuring Release on Demand, you gather both qualitative and quantitative feedback from customers and from your monitoring system. This feedback tells you whether the hypothesis behind the idea is valid. It enables you to make informed decisions about investing more or less in epics and features.\nBy deploying small amounts of new functionality with the feature toggle off, the risk stays small. And the business gets the opportunity to decide when to maximize the impact of new functionality and maximize value for users.\nKey Takeaways # Separate deployment from release. Deployment puts code into production with the feature toggle off. Release switches the toggle on. This separation gives the business control over timing. Releasing is a business decision. The business decides when, to whom, and how broadly new functionality is released. Feature toggles are the enabler. They allow canary releases, dark launches, and incremental rollouts while keeping risk low. Measure your hypotheses. Use leading indicators to validate or invalidate the original hypothesis based on real customer data, not assumptions. The whole pipeline is a learning loop. From hypothesis to release to measurement to learning, everything feeds back into exploration, enabling you to build the right thing right. Lead time depends on scope. Small changes can flow through in an hour. Larger features take a sprint. The pipeline supports both. ","date":"11 May 2022","externalUrl":null,"permalink":"/en/blogs/what-is-release-on-demand/","section":"Blogs","summary":"Release on Demand is the final step in the SAFe for DevOps continuous delivery pipeline, and it is the step that ties everything together. In this video, I walk through how Release on Demand works, why separating deployment from release is so powerful, and how the whole pipeline enables organizations to build the right thing right.\n","title":"What is Release on Demand?","type":"blogs"},{"content":"","date":"20 April 2022","externalUrl":null,"permalink":"/en/tags/executive-leadership/","section":"Tags","summary":"","title":"Executive Leadership","type":"tags"},{"content":"","date":"20 April 2022","externalUrl":null,"permalink":"/en/tags/lean-portfolio-management/","section":"Tags","summary":"","title":"Lean Portfolio Management","type":"tags"},{"content":"As a leading innovation company with 1600 employees in Germany, United Kingdom, Austria, Serbia, Bulgaria, Singapore, Hong Kong, Portugal, Switzerland and Vietnam, Zühlke has always some ongoing and planned strategic initiatives.\nIn 2021 the group executive decided introducing a state-of-the-art portfolio management.\nBy Ueli Kleeb and Romano Roth\nOur ambition # Zühlke Lean Portfolio Management adds better decision making and a lean approach to strategic group initiatives\nGroup executives want an open, comprehensive Portfolio, and expects:\nTransparency, fosters alignment for goals and initiatives Continuously care about strategic goals More holistic decision making due to “north star” and improved WIP (work in progress) view Professionalize portfolio management to facilitate benefits over time, including cost. Group executives and the board wants us to do change initiatives in a lean approach and expects:\nFaster learnings, results and feedback Improve effectiveness (adapt/fail fast/reduce waste) Reduce work in progress - “getting things done” Requires splitting large initiatives into MVP (minimum viable product) and succeeding iterations What we did # We decided to apply the lean portfolio management from the SAFe® framework for our portfolio of change initiatives. SAFE® has become the quasi-industry-standard for lean enterprises. Zühlke supports clients in transforming into lean enterprises and we wanted to “eat our own dogfood”. SAFE® provides valuable guidance and templates for the lean portfolio management. Where we are after our 6-month MVP # We have a vision and strategic themes on enterprise level We have epics and epic owners. An epic in our case is identical to a change initiative. We have a Confluence page with the major information, including the hypothesis and, for large initiatives, a lean business case. We have a Portfolio Kanban with the epics and an epic roadmap We have a portfolio team that includes a top executive, a portfolio manager, a LPM consultant and an enterprise architect. We are establishing operational value streams. We don’t have development value streams. Therefore, we cannot simply put epics in the backlog and enabling the value streams to pull them. We still need to decide, which epics from the backlog to implement and we can hardly do lean budgeting in change initiative portfolio (in other portfolios this is already possible see Participatory budgeting: financing in the 21st century). The epic roadmap is currently most important artifact to limit “work in progress” on group level. We used the opportunity and introduced some Zühlke specifics:\nIn addition to the «initiative» epics, we encourage putting «goal» epics into the funnel of the Portfolio Kanban. We introduced OKRs for alignment and tracking groupwide using the same tool (gtmhub). This allows us to conveniently keep track of goals and initiatives in the same tool that leadership team uses for setting and tracking their business goals. All staff can view what’s going on. Our learnings after the MVP # Positive: Strategic Themes are the “north star” for yearly goals and epics. Positive: Transparency about strategic initiatives across the entire group Positive: Support to elicit strategic goals and track implementation progress Positive Zühlke add-on: We encourage entering goals as well as epics into the Portfolio Kanban. Todo: Implement initiatives in a lean way Todo: Lacking Development Value Streams complicates coordination (e.g., ensure WIP limit) and budgeting Original Post: Zühlke\n","date":"20 April 2022","externalUrl":null,"permalink":"/en/blogs/lean-portfolio-management-at-zuehlke/","section":"Blogs","summary":"As a leading innovation company with 1600 employees in Germany, United Kingdom, Austria, Serbia, Bulgaria, Singapore, Hong Kong, Portugal, Switzerland and Vietnam, Zühlke has always some ongoing and planned strategic initiatives.\n","title":"Lean Portfolio Management at Zühlke","type":"blogs"},{"content":"Als führendes Innovationsunternehmen mit 1600 Mitarbeitenden in Deutschland, Großbritannien, Österreich, Serbien, Bulgarien, Singapur, Hongkong, Portugal, der Schweiz und Vietnam hat Zühlke stets laufende und geplante strategische Initiativen.\nIm Jahr 2021 beschloss die Geschäftsleitung, ein modernes Portfolio Management einzuführen.\nVon Ueli Kleeb und Romano Roth\nUnsere Ambition # Zühlke Lean Portfolio Management verbessert die Entscheidungsfindung und bringt einen schlanken Ansatz für strategische Gruppeninitiativen.\nDie Geschäftsleitung wünscht sich ein offenes, umfassendes Portfolio und erwartet:\nTransparenz, die die Ausrichtung von Zielen und Initiativen fördert Kontinuierliche Pflege der strategischen Ziele Ganzheitlichere Entscheidungsfindung dank eines «Nordsterns» und verbesserter WIP-Sicht (Work in Progress) Professionalisierung des Portfolio Managements, um langfristig Nutzen zu erzielen, einschließlich Kosteneinsparungen Die Geschäftsleitung und der Verwaltungsrat möchten Veränderungsinitiativen schlank durchführen und erwarten:\nSchnellere Erkenntnisse, Ergebnisse und Feedback Verbesserte Effektivität (schnell anpassen, schnell scheitern, Verschwendung reduzieren) Reduktion der laufenden Arbeiten: «Dinge zu Ende bringen» Aufteilung großer Initiativen in MVPs (Minimum Viable Product) und darauf aufbauende Iterationen Was wir getan haben # Wir haben uns entschieden, das Lean Portfolio Management aus dem SAFe®-Framework für unser Portfolio von Veränderungsinitiativen anzuwenden. SAFe® hat sich zum Quasi-Industriestandard für schlanke Unternehmen entwickelt. Zühlke unterstützt Kunden bei der Transformation zu schlanken Unternehmen, und wir wollten «unsere eigene Medizin nehmen». SAFe® bietet wertvolle Anleitungen und Vorlagen für das Lean Portfolio Management. Wo wir nach unserem 6-Monats-MVP stehen # Wir haben eine Vision und strategische Themen auf Unternehmensebene. Wir haben Epics und Epic Owner. Ein Epic entspricht in unserem Fall einer Veränderungsinitiative. Wir haben eine Confluence-Seite mit den wichtigsten Informationen, einschließlich der Hypothese und, bei großen Initiativen, einem Lean Business Case. Wir haben ein Portfolio Kanban mit den Epics und eine Epic Roadmap. Wir haben ein Portfolio-Team, das einen Top-Executive, einen Portfolio Manager, einen LPM-Berater und einen Enterprise Architekten umfasst. Wir sind dabei, operative Wertströme zu etablieren. Wir haben keine Entwicklungswertströme. Daher können wir Epics nicht einfach ins Backlog legen und die Wertströme diese ziehen lassen. Wir müssen immer noch entscheiden, welche Epics aus dem Backlog umgesetzt werden sollen, und können im Portfolio der Veränderungsinitiativen kaum Lean Budgeting betreiben (in anderen Portfolios ist dies bereits möglich, siehe Partizipatives Budgetieren: Finanzierung im 21. Jahrhundert). Die Epic Roadmap ist derzeit das wichtigste Artefakt, um «Work in Progress» auf Gruppenebene zu begrenzen. Wir haben die Gelegenheit genutzt und einige Zühlke-spezifische Anpassungen eingeführt:\nZusätzlich zu den «Initiativen»-Epics ermutigen wir dazu, «Ziel»-Epics in den Funnel des Portfolio Kanban einzubringen. Wir haben OKRs für die gruppenweite Ausrichtung und Nachverfolgung eingeführt, und zwar mit dem gleichen Tool (gtmhub). So können wir Ziele und Initiativen bequem im selben Tool verfolgen, das die Führungsteams für ihre Geschäftsziele nutzen. Alle Mitarbeitenden können sehen, was passiert. Unsere Erkenntnisse nach dem MVP # Positiv: Strategische Themen sind der «Nordstern» für Jahresziele und Epics. Positiv: Transparenz über strategische Initiativen in der gesamten Gruppe. Positiv: Unterstützung bei der Ermittlung strategischer Ziele und der Nachverfolgung des Umsetzungsfortschritts. Positiv (Zühlke-Ergänzung): Wir ermutigen dazu, sowohl Ziele als auch Epics in das Portfolio Kanban einzutragen. Noch zu tun: Initiativen schlank umsetzen. Noch zu tun: Das Fehlen von Entwicklungswertströmen erschwert die Koordination (z.B. WIP-Limits sicherstellen) und die Budgetierung. Originalbeitrag: Zühlke\n","date":"20. April 2022","externalUrl":null,"permalink":"/de/blogs/lean-portfolio-management-bei-zuehlke/","section":"Blogs","summary":"Als führendes Innovationsunternehmen mit 1600 Mitarbeitenden in Deutschland, Großbritannien, Österreich, Serbien, Bulgarien, Singapur, Hongkong, Portugal, der Schweiz und Vietnam hat Zühlke stets laufende und geplante strategische Initiativen.\nIm Jahr 2021 beschloss die Geschäftsleitung, ein modernes Portfolio Management einzuführen.\n","title":"Lean Portfolio Management bei Zühlke","type":"blogs"},{"content":"","date":"20 April 2022","externalUrl":null,"permalink":"/en/tags/okrs/","section":"Tags","summary":"","title":"OKRs","type":"tags"},{"content":"","date":"20 April 2022","externalUrl":null,"permalink":"/en/tags/portfolio-management/","section":"Tags","summary":"","title":"Portfolio Management","type":"tags"},{"content":"","date":"20 April 2022","externalUrl":null,"permalink":"/en/tags/strategic-planning/","section":"Tags","summary":"","title":"Strategic Planning","type":"tags"},{"content":"","date":"20. April 2022","externalUrl":null,"permalink":"/de/tags/strategische-planung/","section":"Tags","summary":"","title":"Strategische Planung","type":"tags"},{"content":"Working at the same company for more than 20 years, continuously developing yourself, and never losing any enthusiasm for innovation? How that works is shown in this fascinating interview with Romano Roth, Chief of DevOps and Partner at Zühlke Group. In this Career Design Interview, Romano explains the role that a growth mindset, curiosity, self-reflection, and the company\u0026rsquo;s feedback culture play.\nInterview: Claudia Scherrer\nSource: myworklifedesign.ch\nPut simply: by the company investing in me. From day one, I was supported, coached, and always shown perspectives for growth. For example, I had the opportunity to do an EMBA to find out whether I wanted to pursue a management career or a technical career. This helped me enormously to shape my career and made it possible to constantly evolve. For me, there is no reason to switch to another company.\nI started right after university as a Junior Software Developer. At the time, I was quite overwhelmed by the size and complexity of my first project. The great thing was that I was extremely well supported by my colleagues from the first day. They took the time to explain things to me and gave me tasks that matched my skill level. This created a sense of belonging right from the start. That\u0026rsquo;s how I evolved, becoming an Advanced Software Engineer, then an Expert Software Engineer. First I focused heavily on technology and kept getting better at it. Then came the step toward becoming an architect. I dealt with architectures, working in teams, and leading teams. At some point, the time was right for the step toward becoming a consultant. The following questions, which are also close to my heart, have always occupied me: How can we automate something? How can we ensure quality? How can we deliver value continuously? That\u0026rsquo;s how I quickly came to the topic of CI/CD (Continuous Integration and Continuous Deployment). And when the DevOps movement started, I jumped on it. Today I support companies in their DevOps or Agile transformations and am one of the organizers of the DevOps Meetups in Zurich and DevOpsDays Zurich. The DevOps topic is truly close to my heart. That\u0026rsquo;s why I make so many videos about it.\nWhen my step toward Distinguished Consultant was coming up, I received dedicated coaching for stage presence. The trainer Sabine Stücheli recorded me on video to reflect on my appearances. She recommended that I regularly record myself for training purposes and experiment with voice, gestures, and so on. I did that and thought, \u0026ldquo;Hey, those actually turned out to be not bad videos…\u0026rdquo; I once uploaded a video to YouTube to see if it would lead anywhere. The response was extremely positive. This encouraged me to keep improving the quality of the videos and to continue using this channel to talk about my topics: YouTube\nThere are several factors. First, you have to bring genuine interest and curiosity. You have to be hungry for knowledge. Second, you need a change mindset. You shouldn\u0026rsquo;t be too fixated on one path and must be willing to constantly reflect on your stance and adjust it if necessary.\nIn addition to genuine interest and curiosity, you need a change mindset. You shouldn\u0026rsquo;t be too fixated on one path and must be willing to constantly reflect on your stance and adjust it if necessary.\nThat\u0026rsquo;s exactly the thing. What\u0026rsquo;s important is that you find out what suits you through conversations with others or through further training. For a certain time, UX was my topic. Along the way, I noticed that I find DevOps even more exciting. In five years, I might find something else more interesting again. It\u0026rsquo;s enormously important to maintain this flexibility and agility so that you can also change things. What I often do is a personal retrospective. About every 14 days, I reflect on what went well and what I could improve. I then implement the improvements. For a successful career, I consider it very important to continuously work on yourself, reflect, and improve.\nWhat I often do is a personal retrospective. About every 14 days, I reflect on what went well and what I could improve. I then implement the improvements. For a successful career, I consider it very important to continuously work on yourself, reflect, and improve.\nYes, definitely. There have been situations again and again where I failed or something didn\u0026rsquo;t go the way it should. But then I didn\u0026rsquo;t hear, \u0026ldquo;You\u0026rsquo;re bad. You\u0026rsquo;re making mistakes,\u0026rdquo; but rather, \u0026ldquo;You\u0026rsquo;re just not at the skill level yet. You can do this or that to get there.\u0026rdquo; Thanks to this mindset in our company, good and open conversations arise in such situations. The feedback culture is something very important at Zühlke. Employees have a career coach. This is either the supervisor or, as in my case, since I\u0026rsquo;m in a self-organized team, a mentor. This way you have very good conversations and can reflect on self-image versus external perception.\nWhat makes innovation projects and careers successful is continuous perseverance. The process is typically similar: you are at a certain starting point and you have a path. You roughly know where the goal is, but you don\u0026rsquo;t know what the path to the goal is. Accordingly, you take the first steps and head in some direction. The most important thing, in innovation projects as well as in careers, is to start and take the first steps. With that, you can also go in the wrong direction. Then you must be able to accept that and make a change. That\u0026rsquo;s part of agility. It\u0026rsquo;s important to reflect in short cycles. I would recommend two-week or monthly cycles. This way, you can introduce continuous reflection and continuous improvement.\nThat\u0026rsquo;s a good question. Currently, I find the topic of self-organization very exciting. Since last year, I\u0026rsquo;ve been on a self-organized team, and it\u0026rsquo;s absolutely great. You grow much more strongly together as a unit. The greatest moment is when you go and say, \u0026ldquo;We now have to discuss salaries together.\u0026rdquo; Then it becomes somewhat emotional. Everyone reveals their salary. At that point, you notice how everything changes, you grow into a real team, and trust is lifted to a whole new level. I think companies should go much more in the direction of self-organization, empowerment, and transparency.\n","date":"5 April 2022","externalUrl":null,"permalink":"/en/blogs/an-inspiring-career-of-more-than-20-years-at-one-company/","section":"Blogs","summary":"Working at the same company for more than 20 years, continuously developing yourself, and never losing any enthusiasm for innovation? How that works is shown in this fascinating interview with Romano Roth, Chief of DevOps and Partner at Zühlke Group. In this Career Design Interview, Romano explains the role that a growth mindset, curiosity, self-reflection, and the company’s feedback culture play.\n","title":"An Inspiring Career of More Than 20 Years at One Company","type":"blogs"},{"content":"","date":"5 April 2022","externalUrl":null,"permalink":"/en/tags/career-development/","section":"Tags","summary":"","title":"Career Development","type":"tags"},{"content":"Über 20 Jahre beim gleichen Unternehmen arbeiten, sich dabei stets weiterentwickeln und kein bisschen Innovationsfreude verlieren? Wie das geht, zeigt das spannende Interview mit Romano Roth, Chief of DevOps und Partner bei Zühlke Group. Welche Rolle dabei eine wachstumsorientierte Haltung, Neugier, Selbstreflexion und die Feedback-Kultur im Unternehmen spielen, erläutert Romano im Career Design Interview.\nInterview: Claudia Scherrer\nQuelle: myworklifedesign.ch\nVereinfacht gesagt, indem das Unternehmen in mich investiert hat. Vom ersten Tag an wurde ich unterstützt, gecoacht und man hat mir immer Entwicklungsperspektiven aufgezeigt. Ich hatte beispielsweise die Möglichkeit, einen EMBA zu machen, um herauszufinden, ob ich eine Managementkarriere oder eine technische Karriere verfolgen möchte. Dies hat mir enorm geholfen, meine Karriere zu formen und ermöglicht, mich ständig weiterzuentwickeln. Für mich gibt es keinen Grund, zu einem anderen Unternehmen zu wechseln.\nIch startete direkt nach der Universität als Junior Software-Entwickler. Damals war ich ziemlich überwältigt von der Grösse und der Komplexität meines ersten Projekts. Das Grossartige war, dass ich vom ersten Tag an extrem gut unterstützt wurde durch meine Kollegen. Sie haben sich die Zeit genommen, mir Dinge zu erklären und Aufgaben gegeben, die meinem Skill-Level entsprechend waren. Dies hat von Anfang an ein Gefühl der Verbundenheit gegeben. So habe ich mich weiterentwickelt, wurde Advanced Software Engineer, dann Expert Software Engineer. Zuerst habe ich mich stark mit der Technologie beschäftigt und bin dort immer besser geworden. Dann stand der Schritt Richtung Architekt an. Ich habe mich mit Architekturen, der Zusammenarbeit im Team und der Führung von Teams beschäftigt. Irgendwann war die Zeit reif für den Schritt Richtung Consultant. Dabei haben mich immer die folgenden Fragen beschäftigt, welche auch eine Herzensangelegenheit von mir sind: Wie können wir etwas automatisieren? Wie können wir Qualität sicherstellen? Wie können wir kontinuierlich Wert liefern? Darum bin ich rasch auf das Thema CI/CD (Continuous Integration und Continuous Deployment) gekommen. Und als das DevOps Movement gestartet ist, bin ich dort aufgesprungen. Heute begleite ich Unternehmen bei ihrer DevOps oder Agile Transformation und bin einer der Organisatoren der DevOps Meetups in Zürich und der DevOpsDays Zürich. Das DevOps Thema liegt mir wirklich am Herzen. Darum mache ich auch so viele Videos dazu.\nAls mein Schritt Richtung Distinguished Consultant anstand, habe ich dediziertes Coaching für Auftrittskompetenz erhalten. Die Trainerin Sabine Stücheli hat mich auf Video aufgenommen, um meine Auftritte zu reflektieren. Sie hat mir empfohlen, mich selbst zu Trainingszwecken regelmässig aufzunehmen und mit Stimme, Gestik, etc. zu experimentieren. Ich habe das gemacht und dachte: „Hey, das sind eigentlich gar nicht mal so schlechte Videos geworden…\u0026quot; Ich habe mal ein Video auf YouTube hochgeladen, um zu schauen, ob das etwas bringt. Die Resonanz war enorm positiv. Dies hat mich ermutigt, die Qualität der Videos stets zu verbessern und diesen Kanal weiter zu nutzen, um über meine Themen zu sprechen: YouTube\nEs gibt mehrere Faktoren. Erstens muss man echtes Interesse und Neugier mitbringen. Du musst Hunger nach Wissen haben. Zweitens muss man ein Change-Mindset mitbringen. Man darf nicht zu fixiert sein auf einen Weg und muss die Bereitschaft haben, seine Haltung stets zu reflektieren und gegebenenfalls anzupassen.\nNeben echtem Interesse und Neugier muss man ein Change-Mindset mitbringen. Man darf nicht zu fixiert sein auf einen Weg und muss die Bereitschaft haben, seine Haltung stets zu reflektieren und gegebenenfalls anzupassen.\nDas ist genau das Ding. Wichtig ist, dass man im Gespräch mit anderen oder Weiterbildungen herausfindet, was für einen passend ist. Eine gewisse Zeit war UX das Thema für mich. Auf dem Weg habe ich gemerkt, dass ich DevOps noch spannender finde. In 5 Jahren finde ich vielleicht wieder etwas anderes interessanter. Es ist enorm wichtig, diese Flexibilität und Agilität beizubehalten, um auch Dinge ändern zu können. Was ich oft mache ist eine Eigen-Retrospektive. Ich reflektiere etwa alle 14 Tage, was gut gelaufen ist und was ich verbessern könnte. Die Verbesserungsmöglichkeiten setze ich dann um. Für eine erfolgreiche Karriere erachte es als sehr wichtig, dass man kontinuierlich an sich arbeitet, sich selbst reflektiert und verbessert.\nWas ich oft mache ist eine Eigen-Retrospektive. Ich reflektiere etwa alle 14 Tage, was gut gelaufen ist und was ich verbessern könnte. Die Verbesserungsmöglichkeiten setze ich dann um. Für eine erfolgreiche Karriere erachte ich es als sehr wichtig, dass man kontinuierlich an sich arbeitet, sich selbst reflektiert und verbessert.\nJa, definitiv. Es hat immer wieder Situationen gegeben, wo ich gescheitert bin oder etwas nicht so gelaufen ist wie es sollte. Ich habe dann aber nicht gehört: «Du bist schlecht. Du machst Fehler.», sondern vielmehr «Du bist halt noch nicht auf dem Skill-Level. Dies oder jenes kannst du machen, um dorthin zu kommen». Dank diesem Mindset bei uns im Unternehmen entstehen in solchen Situationen gute und offene Gespräche. Die Feedback-Kultur ist etwas ganz Wichtiges bei Zühlke. Die Mitarbeiter haben einen Karrierecoach. Dies ist entweder der Vorgesetzte oder wie in meinem Fall, ich bin in einem selbstorganisierten Team, ein Mentor. So hat man sehr gute Gespräche und kann Selbstbild vs. Fremdbild reflektieren.\nWas Innovationsprojekte und Karrieren erfolgreich macht ist das kontinuierliche Dranbleiben. Der Prozess ist typischerweise ähnlich: Du bist an einem gewissen Ausgangspunkt und du hast einen Weg. Du weisst in etwa, wo das Ziel ist, aber du weisst nicht, was der Weg zum Ziel ist. Entsprechend machst du erste Schritte und gehst mal in eine Richtung. Das Wichtigste, in Innovationsprojekten wie auch der Karriere, ist mal zu starten und erste Schritte zu machen. Damit kann man auch mal in die falsche Richtung gehen. Dann muss man in der Lage sein, das zu akzeptieren und eine Änderung zu machen. Das ist Teil der Agilität. Wichtig ist, in kurzen Zyklen zu reflektieren. Ich würde 2-Wochen oder Monatszyklen empfehlen. Dadurch kann man die kontinuierliche Reflexion und kontinuierliche Verbesserung reinbringen.\nDas ist eine gute Frage. Aktuell finde ich das Thema Selbstorganisation sehr spannend. Seit letztem Jahr bin ich in einem selbstorganisierten Team und es ist absolut grossartig. Man wächst als Einheit viel stärker zusammen. Der grossartigste Moment ist der, wo man hingeht und sagt: „Wir müssen jetzt zusammen über Löhne diskutieren.\u0026quot; Dann wird es etwas emotional. Jeder gibt seinen Lohn preis. An diesem Punkt merkt man wie sich alles ändert, man zu einem richtigen Team zusammenwächst und das Vertrauen auf ein ganz neues Level gehoben wird. Ich finde Unternehmen sollten viel mehr in die Richtung Selbstorganisation, Empowerment und Transparenz gehen.\n","date":"5. April 2022","externalUrl":null,"permalink":"/de/blogs/eine-inspirierende-karriere-ueber-mehr-als-20-jahre/","section":"Blogs","summary":"Über 20 Jahre beim gleichen Unternehmen arbeiten, sich dabei stets weiterentwickeln und kein bisschen Innovationsfreude verlieren? Wie das geht, zeigt das spannende Interview mit Romano Roth, Chief of DevOps und Partner bei Zühlke Group. Welche Rolle dabei eine wachstumsorientierte Haltung, Neugier, Selbstreflexion und die Feedback-Kultur im Unternehmen spielen, erläutert Romano im Career Design Interview.\n","title":"Eine inspirierende Karriere über mehr als 20 Jahre innerhalb eines Unternehmens","type":"blogs"},{"content":"","date":"5 April 2022","externalUrl":null,"permalink":"/en/tags/long-term-employment/","section":"Tags","summary":"","title":"Long-Term Employment","type":"tags"},{"content":"","date":"5 April 2022","externalUrl":null,"permalink":"/en/tags/professional-growth/","section":"Tags","summary":"","title":"Professional Growth","type":"tags"},{"content":"","date":"30 March 2022","externalUrl":null,"permalink":"/en/tags/dark-launches/","section":"Tags","summary":"","title":"Dark Launches","type":"tags"},{"content":"Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.\nDie Grundlage: CI/CD # Bevor wir über Feature Toggles sprechen können, müssen wir ein paar Grundlagen verstehen. Continuous Integration (CI) bedeutet, dass jedes Mal, wenn Code committed wird, dieser mit dem restlichen Code reintegriert wird. Der CI-Server baut den Code, führt statische Code-Analyse durch, macht statische Security-Analyse, führt Unit Tests und Integrationstests aus. Das Ergebnis ist ein deployierbares Artefakt. Das Wichtigste dabei: Das Feedback muss den Entwickler so schnell wie möglich erreichen, innerhalb von Minuten, nicht Stunden.\nContinuous Delivery baut auf CI auf. Das deployierbare Artefakt wird automatisch in eine Staging-Umgebung deployt, eine produktionsnahe Umgebung, in der Acceptance Testing und exploratives Testen stattfinden können. Continuous Deployment geht noch einen Schritt weiter: Das Artefakt fliesst automatisch durch alle Quality Gates in die Produktion. Eine Zeile Code ändern, committen, und sie fliesst den ganzen Weg bis in die Produktion.\n\u0026ldquo;Es gibt nichts Nervigeres, als Code zu committen und zwei Stunden später das Feedback zu bekommen. Bis dahin arbeitet man längst an etwas völlig anderem.\u0026rdquo;\nDas Schlüsselkonzept: Deployment von Release trennen # Das ist das fundamentale Konzept, das Continuous Deployment ermöglicht: die Trennung von Deployment und Release.\nEin Deployment bedeutet, den kompilierten Code in die Produktion zu bringen, mit dem Feature Toggle ausgeschaltet. Ein Release bedeutet, den Feature Toggle einzuschalten und den Nutzern Zugang zur neuen Funktionalität zu geben. Durch die Trennung dieser beiden Konzepte kann man kontinuierlich in die Produktion deployen, ohne unfertigen Nutzer Features anzuzeigen.\nDark Launches # Wenn man Code in die Produktion deployt, mit dem Feature Toggle ausgeschaltet, führt man einen \u0026ldquo;Dark Launch\u0026rdquo; durch. Die Funktionalität ist bereits in der Produktion, aber für die Nutzer unsichtbar. Das gibt einem die Möglichkeit, das Monitoring und Alerting aufzusetzen und zu prüfen, wie der neue Code unter realer Last mit dem Live-System interagiert.\nDas bekannteste Beispiel ist der Facebook Messenger. Ein ganzes Jahr vor dem offiziellen Release war der Facebook Messenger bereits in der Produktion, versteckt hinter Feature Flags. Facebook nutzte dieses Jahr, um Monitoring und Alerting anzuschliessen und zu beobachten, wie der Messenger sich unter Facebooks massiver Last verhält. Am Tag des Releases mussten sie nur den Toggle umschalten, und alles funktionierte.\nWas genau ist ein Feature Toggle? # Im Kern ist ein Feature Toggle nichts anderes als eine if-Anweisung: Wenn das Flag true ist, wird der neue Code-Pfad ausgeführt. Wenn das Flag false ist, wird der alte Code-Pfad ausgeführt. Das ist das gesamte Konzept.\nEine wichtige Unterscheidung: Ein Feature Toggle ist keine Anwendungskonfiguration. Anwendungskonfigurationen sind permanente Einstellungen der Anwendung. Ein Feature Toggle ist temporär. Er existiert nur, um Continuous Deployment oder Dark Launches zu ermöglichen. Sobald das Feature released und stabil ist, entfernt man den Toggle aus dem Code.\n\u0026ldquo;Feature Toggles im Blick behalten. Wenn man das nicht tut, verbreiten sie sich überall, führen zu unübersichtlichem Code und erheblichen technischen Schulden.\u0026rdquo;\nEin Wort der Warnung: Jeder Feature Toggle, den man hinzufügt, ist im Grunde ein Testfall. Wenn man zu viele aktive Toggles hat, wächst die kombinatorische Komplexität schnell. Man sollte sie mit Bedacht einsetzen und immer aufräumen, nachdem das Feature released wurde.\nFeature Flags im grossen Stil verwalten # Für einen einzelnen Toggle reichen eine einfache if-Anweisung und eine Wiki-Seite vielleicht aus. Im grossen Stil braucht man aber richtiges Tooling. Plattformen wie Flagsmith, ein Open-Source Feature-Flagging-Tool, bieten Dashboards, um Flags über Umgebungen hinweg zu verwalten, zu steuern wer was sieht und sich mit Analytics-Anbietern zu integrieren.\nBen Rometsch hat in einer Live-Demo gezeigt, wie Flagsmith in der Praxis funktioniert:\nFlags auf Umgebungsebene: Ein Flag erstellen, in der Entwicklungsumgebung aktivieren, in der Produktion deaktiviert lassen. So können Entwickler Features in der Entwicklungsumgebung testen, während die Produktion stabil bleibt. Überschreibungen auf Nutzerebene: Ein Flag für einen bestimmten Nutzer in der Produktion aktivieren. So kann ein Entwickler den neuen Checkout-Flow in der Produktion testen, während alle anderen den alten sehen. Segmentbasierte Rollouts: Regeln basierend auf Nutzer-Merkmalen (Alter, Standort, Tarif) definieren, um zu steuern, welche Nutzergruppen ein Feature sehen. Prozentuale Rollouts: Ein Feature zuerst an 1% der Nutzer ausrollen, auf Probleme prüfen, dann schrittweise auf 50% und schliesslich 100% erhöhen. Progressive Enhancement und Resilienz # Ein wichtiges Designprinzip: Die Anwendung muss sich auch dann korrekt verhalten, wenn die Feature-Flagging-API nicht erreichbar ist. Das liegt nicht daran, dass die API ausfällt, sondern weil Nutzer unzuverlässige Netzwerke haben, seltsame Ad-Blocker nutzen oder gerade in einen Tunnel gefahren sind. Immer ein Standardverhalten designen, das auch ohne die Flags der Plattform funktioniert.\nVon Feature Flags zu Experimentation # Sobald Feature Flags im Einsatz sind, wird A/B Testing fast gratis. Man kann 50% der Nutzer den neuen Checkout-Flow zeigen und 50% den alten, und dann messen, welcher besser performt. Man geht vom \u0026ldquo;Testen in der Produktion als Entwickler\u0026rdquo; zum \u0026ldquo;A/B-Test gegen die Plattform\u0026rdquo; mit nur wenigen Klicks, und ohne Code-Änderungen.\n\u0026ldquo;Der heilige Gral ist es, den Kreislauf zu schliessen: vom Schreiben des Feature-Codes bis hin zur Generierung von Daten über die Wirksamkeit dieses Features.\u0026rdquo;\nKernaussagen # Deployment von Release trennen. Das ist das fundamentale Konzept, das Continuous Deployment ermöglicht. Mit ausgeschaltetem Toggle deployen, durch Einschalten releasen.\nFeature Toggles sind temporär. Sie sind keine Anwendungskonfigurationen. Entfernen, sobald das Feature released und stabil ist.\nDark Launches reduzieren Risiko. Code in die Produktion zu deployen, bevor er released wird, ermöglicht es, Monitoring aufzusetzen und das Verhalten unter realer Last zu prüfen.\nEinfach starten, schrittweise wachsen. Mit einfachen An/Aus-Flags beginnen. Dann zu Überschreibungen auf Nutzerebene, segmentbasierten Rollouts und schliesslich A/B Testing übergehen.\nToggles aufräumen. Jeder nicht entfernte Toggle fügt Komplexität und potenzielle technische Schulden hinzu. Konsequent tracken und entfernen.\nFür Resilienz designen. Die Anwendung muss sich korrekt verhalten, auch wenn der Feature-Flag-Service nicht erreichbar ist.\n","date":"30. March 2022","externalUrl":null,"permalink":"/de/blogs/feature-toggles-was-warum-wie/","section":"Blogs","summary":"Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.\n","title":"Feature Toggles: Was, warum, wie?","type":"blogs"},{"content":"Feature toggles are one of those concepts that sound simple on the surface but unlock enormous power in practice. In this DevOps Meetup Zurich session, I team up with Ben Rometsch, founder of Flagsmith, to explain the what, why, and how of feature toggles. We cover the foundational concepts of CI/CD that make feature toggles necessary, the difference between deployment and release, and how modern feature flagging platforms enable progressive rollouts, user segmentation, and A/B testing.\nThe Foundation: CI/CD # Before we can talk about feature toggles, we need to understand a few fundamentals. Continuous Integration (CI) means that every time you commit code, it gets reintegrated with the rest of the codebase. The CI server builds the code, runs static code analysis, static security analysis, unit tests, and integration tests. The output is a deployable artifact. The most important thing: feedback must reach the developer as fast as possible, within minutes, not hours.\nContinuous Delivery builds on top of CI. The deployable artifact gets automatically deployed into a staging environment, a production-like environment, where acceptance testing and exploratory testing can happen. Continuous Deployment goes one step further: the artifact flows automatically through all quality gates into production. Change a line of code, commit it, and it flows all the way to production.\n\u0026ldquo;There is nothing more annoying than committing your code and getting feedback two hours later. By that time, you are working on something completely different.\u0026rdquo;\nThe Key Concept: Separating Deployment from Release # This is the fundamental concept that enables continuous deployment: the separation of deployment and release.\nA deployment means bringing the compiled code into production with the feature toggle turned off. A release means switching the feature toggle on, giving users access to the new functionality. By separating these two concepts, you can continuously deploy to production without exposing unfinished features to users.\nDark Launches # When you deploy code to production with the feature toggle off, you are doing a \u0026ldquo;dark launch.\u0026rdquo; The functionality is already in production, but invisible to users. This gives you the opportunity to wire up monitoring, alerting, and verify how the new code interacts with the live system under real load.\nThe most famous example is Facebook Messenger. A full year before the official release, Facebook Messenger was already in production, hidden behind feature flags. Facebook used that year to connect monitoring, alerting, and observe how the messenger behaved under Facebook\u0026rsquo;s massive load. When the release day came, they simply flipped the toggle and everything worked.\nWhat Exactly is a Feature Toggle? # At its core, a feature toggle is nothing more than an if statement: if the flag is true, execute the new code path. If the flag is false, execute the old code path. That is the entire concept.\nOne important distinction: a feature toggle is not an application configuration. Application configurations are permanent settings of your application. A feature toggle is temporary. It exists only to enable continuous deployment or dark launches. Once the feature is released and stable, you remove the toggle from the code.\n\u0026ldquo;Keep track of your feature toggles. If you don\u0026rsquo;t, they will spread all over the place, leading to messy code and significant technical debt.\u0026rdquo;\nA word of caution: every feature toggle you add is essentially a test case. If you have too many active toggles, the combinatorial complexity grows quickly. Use them wisely and always clean them up after the feature is released.\nManaging Feature Flags at Scale # For a single toggle, a simple if statement and a wiki page might suffice. But at scale, you need proper tooling. Platforms like Flagsmith, an open-source feature flagging tool, provide dashboards to manage flags across environments, control who sees what, and integrate with analytics providers.\nBen Rometsch demonstrated how Flagsmith works in practice:\nEnvironment-level flags: Create a flag, enable it in development, keep it off in production. This lets engineers test features in dev while production stays stable. User-level overrides: Enable a flag for a specific user in production. This allows an engineer to test the new checkout flow in production while everyone else sees the old one. Segment-based rollouts: Define rules based on user traits (age, location, plan type) to control which groups of users see a feature. Want to show the new checkout to users over 40? Create a segment rule. Percentage-based rollouts: Roll out a feature to 1% of users first, monitor for issues, then gradually increase to 50% and eventually 100%. Progressive Enhancement and Resilience # An important design principle: your application must behave in a sane way even if the feature flagging API is unreachable. This is not because the API goes down, but because users have unreliable networks, weird ad blockers, or just walked into a tunnel. Always design for a default behavior that works without receiving flags from the platform.\nFrom Feature Flags to Experimentation # Once you have feature flags in place, A/B testing becomes almost free. You can show 50% of users the new checkout flow and 50% the old one, then measure which one performs better. You go from \u0026ldquo;testing in production as an engineer\u0026rdquo; to \u0026ldquo;running an A/B test against the platform\u0026rdquo; with just a few clicks, and no code changes needed.\n\u0026ldquo;The holy grail is completing the loop: from writing the feature code all the way to generating data about the effectiveness of that feature.\u0026rdquo;\nKey Takeaways # Separate deployment from release. This is the fundamental concept that enables continuous deployment. Deploy with the toggle off, release by switching it on.\nFeature toggles are temporary. They are not application configurations. Remove them once the feature is released and stable.\nDark launches reduce risk. Deploying code to production before releasing it lets you wire up monitoring and verify behavior under real load.\nStart simple, grow incrementally. Begin with basic on/off flags. Then move to user-level overrides, segment-based rollouts, and finally A/B testing.\nClean up your toggles. Every unremoved toggle adds complexity and potential technical debt. Track them and remove them consistently.\nDesign for resilience. Your application must behave correctly even when the feature flag service is unreachable.\n","date":"30 March 2022","externalUrl":null,"permalink":"/en/blogs/feature-toggles-what-why-how/","section":"Blogs","summary":"Feature toggles are one of those concepts that sound simple on the surface but unlock enormous power in practice. In this DevOps Meetup Zurich session, I team up with Ben Rometsch, founder of Flagsmith, to explain the what, why, and how of feature toggles. We cover the foundational concepts of CI/CD that make feature toggles necessary, the difference between deployment and release, and how modern feature flagging platforms enable progressive rollouts, user segmentation, and A/B testing.\n","title":"Feature Toggles: What, Why, How?","type":"blogs"},{"content":"","date":"28. March 2022","externalUrl":null,"permalink":"/de/tags/budgetierung/","section":"Tags","summary":"","title":"Budgetierung","type":"tags"},{"content":"","date":"28 March 2022","externalUrl":null,"permalink":"/en/tags/budgeting/","section":"Tags","summary":"","title":"Budgeting","type":"tags"},{"content":"","date":"28 March 2022","externalUrl":null,"permalink":"/en/tags/decision-making/","section":"Tags","summary":"","title":"Decision Making","type":"tags"},{"content":"","date":"28. March 2022","externalUrl":null,"permalink":"/de/tags/entscheidungsfindung/","section":"Tags","summary":"","title":"Entscheidungsfindung","type":"tags"},{"content":"","date":"28 March 2022","externalUrl":null,"permalink":"/en/tags/finance-management/","section":"Tags","summary":"","title":"Finance Management","type":"tags"},{"content":"","date":"28. March 2022","externalUrl":null,"permalink":"/de/tags/finanzmanagement/","section":"Tags","summary":"","title":"Finanzmanagement","type":"tags"},{"content":" One size fits all? Nothing of the sort! Participatory budgeting calls for a tailored solution, one that can constantly evolve and adapt to the given situation. In this article, we describe how we do it at Zühlke.\nZühlke is continuing to apply the concept of participatory budgeting More entrepreneurial thinking for greater innovation and added value Lessons learned implemented in Zühlke’s version 2.0 We presented the innovative method of participatory budgeting in our first blog post on the topic back in September 2021 and used the anonymized example of \u0026lsquo;Fruitmix\u0026rsquo;* to illustrate how it works. In December 2021, we returned as coaches for the second participatory budgeting event for the ‘Fruitmix’ portfolio.\nIn the second half of the year, the \u0026lsquo;Fruitmix\u0026rsquo; portfolio implemented the budget that the participating value stream leads had defined themselves. Many interesting epics were tackled and there was a strong focus on developing the minimum viable product (MVP) for each one. The second participatory budgeting event at Zühlke Switzerland called for an adapted approach to the one taken the first time. Romano and Nadine returned as participatory budgeting coaches and hosted the event:\nLooking back, planning forward # Together with the portfolio management team, they defined the timeline and analysed the feedback from the first participatory budgeting event. The problem back then was that the Fruitmix committee budget was being inadequately allocated across the value streams. Too many ideas and projects, not enough time and funds. The introduction of the Scaled Agile Framework (SAFe) toolkit and the \u0026lsquo;participatory budgeting\u0026rsquo; method went down well with the involved value stream leads. The method, which has been adapted to Zühlke’s situation, led to a positive outcome in four sub-stages. Most importantly, the outcome was supported by all participants. In the second round, the aim was to build on this findings and lessons learned. The process execution followed the same sequence:\nPreparing the content Assembling the participants Conducting the forums Analysing the results The preparatory work (stage one) was similar to that carried out in the first round. The guidelines and principles for the portfolio and the event had not changed much since the first event was held. The portfolio was again aligned with Zühlke Switzerland’s targets, OKRs (objectives \u0026amp; key results) and strategy. The value stream leads prepared their epics (including the MVPs), while the coaches focused on reviewing information and on the agenda, calendar invitations, virtual forum discussion rooms and the calculation basis. The SAFe Excel template for the PB event was helpful here. And because the coaches are Certified SAFe® 5 Program Consultants, they had access to all the necessary resources. The feedback from the value stream leads and the coaches’ retrospectives led to two significant changes to the first stage: in order to make things easier and less confusing for the participants, a distinction was no longer made in the second version of Zühlke’s Particpatory Budgeting Process between the two budget aspects ‘grow the business’ (GTB) and ‘run the business’ (RTB). In addition, the participants were given two extra weeks to prepare and were asked to focus more on the content of the epics. In the second stage, there was an additional information meeting for all value streams. The new composition of the value streams was also taken into account; strawberries were now present in the portfolio as well. All value stream leads prepared for the upfront meeting. The aim was to find out more about the planned epics and initiate interaction between the value streams in order to identify potential priorities and collaborations before the event. Stages three and four remained the same in essence. In this second round, the event received more attention and support from the management. The management team attended the event as a silent audience. Budgeting remained the responsibility of the value stream leads.\nLearning and improving iteratively # Two of the four described differences between version one and two of the participatory budgeting event were organisational in nature: The information meeting was used to understand the epic context in detail. The extended timeline eased the pressure and facilitated creative collaboration. In addition, the participatory budgeting phase was extended to four weeks. Although this is twice as long, the mutually invested time (meetings, budgeting) was roughly the same. The attention received from the management gave more weight to the chosen method and thereby helped to increase acceptance of it within the organisation. This stronger support made it easier to initiate discussions about the epics, generate wider interest and get the backing of Zühlke colleagues who were not involved. The other two changes were process-related and had a significant impact on the course of the event: The general Zühlke strategy, targets and OKRs are no longer the only decisive factors for the epics, as the epic’s business hypothesis is now additionally subject to guidelines. A threshold or significance value was introduced for this purpose in the second round of the event; an epic was only to be discussed in this event if it fulfilled one of three values:\nThree or more value streams were affected, or It concerned a potential ‘new fruit’, or The MVP investment exceeded a predetermined amount This ensured that only significant epic pitches were discussed. Other ideas and suggestions could be put forward in the individual tasks for the value streams. That is why the second change to the process and workflow was necessary; determining the RTB share of the budget was no longer part of the budgeting event itself but, instead, was calculated in advance by the Fruitmix committee using a transparent but confidential formula developed internally by Zühlke. This gave the individual value streams more autonomy to manage their smaller projects and issues. At the same time, the main/big epics (GTB) attracted more attention by having a budgeting event dedicated exclusively to them. The total budget for the event was reduced in proportion to the pre-allocated RTB share.\nCreating an adapted recipe for success together # The adapted preparatory measures quickly proved effective during the event. The value stream leads were well prepared and informed about the epics to be discussed. The pitches on the adjustments and changes to the epics went smoothly. At the same time, skipping the RTB budgeting round saved a valuable 45 minutes to invest in effective budgeting for the innovative new services. The participatory budgeting process in the Zühlke ‘Fruitmix’ portfolio has seen various changes since the initial idea, from the SAFe version of participatory budgeting as a tool to the lessons learned in the first and the second round. The recipe for success is simple: iterative improvement towards an increasingly tailored solution. As coaches, we now want to keep working on this and continuously improve it. The excellent insights from all of the participants, as well as regular discussions on the topic, will be particularly useful to us in achieving this. Potential focal points for the third round might include creating a more refined version of the epic template and incorporating the medium-term goals (MOALs) into the epic assessment. An added benefit is that the value stream leads now have much more experience of the process, which will help to streamline the procedures and make the workflows more fluid. This potential is to be exploited in the next participatory budgeting round, stay tuned!\nZühlke\u0026rsquo;s processes, investments, people, portfolios and solutions have been anonymised for the purpose of this article. And since we\u0026rsquo;re all big fans of fruit, we\u0026rsquo;ve come up with a fruity theme for our digital ideas. co-author: Nadine Broghammer\nOriginal Post: Zühlke | Medium\n","date":"28 March 2022","externalUrl":null,"permalink":"/en/blogs/participatory-budgeting-next-level-financing/","section":"Blogs","summary":" One size fits all? Nothing of the sort! Participatory budgeting calls for a tailored solution, one that can constantly evolve and adapt to the given situation. In this article, we describe how we do it at Zühlke.\n","title":"Participatory budgeting: next level financing","type":"blogs"},{"content":" Eine Lösung für alles? Von wegen! Partizipative Budgetierung verlangt nach einer massgeschneiderten Lösung, die sich ständig weiterentwickeln und an die jeweilige Situation anpassen kann. In diesem Artikel beschreiben wir, wie wir das bei Zühlke umsetzen.\nZühlke wendet das Konzept der partizipativen Budgetierung weiterhin an Mehr unternehmerisches Denken für grössere Innovation und Mehrwert Erkenntnisse aus Version 2.0 bei Zühlke umgesetzt Wir haben die innovative Methode der partizipativen Budgetierung in unserem ersten Blogbeitrag im September 2021 vorgestellt und am anonymisierten Beispiel von «Fruitmix»* illustriert, wie sie funktioniert. Im Dezember 2021 kehrten wir als Coaches für das zweite partizipative Budgetierungsevent des «Fruitmix»-Portfolios zurück.\nIm zweiten Halbjahr setzte das «Fruitmix»-Portfolio das Budget um, das die teilnehmenden Value-Stream-Leads selbst definiert hatten. Viele interessante Epics wurden angegangen, und der Fokus lag stark auf der Entwicklung des Minimum Viable Product (MVP) für jedes einzelne. Das zweite partizipative Budgetierungsevent bei Zühlke Schweiz erforderte einen angepassten Ansatz gegenüber dem ersten Mal. Romano und Nadine kehrten als partizipative Budgetierungs-Coaches zurück und moderierten das Event:\nRückblick und Vorausplanung # Gemeinsam mit dem Portfoliomanagement-Team definierten sie den Zeitplan und analysierten das Feedback vom ersten partizipativen Budgetierungsevent. Das Problem damals war, dass das Budget des Fruitmix-Gremiums unzureichend auf die Value Streams verteilt wurde. Zu viele Ideen und Projekte, nicht genug Zeit und Mittel. Die Einführung des Scaled Agile Framework (SAFe) Toolkits und der Methode «partizipative Budgetierung» kam bei den beteiligten Value-Stream-Leads gut an. Die an Zühlkes Situation angepasste Methode führte in vier Teilschritten zu einem positiven Ergebnis. Am wichtigsten: Das Ergebnis wurde von allen Teilnehmenden getragen. In der zweiten Runde war das Ziel, auf diesen Erkenntnissen aufzubauen. Die Prozessabwicklung folgte der gleichen Reihenfolge:\nInhalte vorbereiten Teilnehmer zusammenstellen Foren durchführen Ergebnisse analysieren Die Vorbereitungsarbeit (Stufe eins) war ähnlich wie in der ersten Runde. Die Leitlinien und Prinzipien für das Portfolio und das Event hatten sich seit dem ersten Event kaum verändert. Das Portfolio war erneut auf die Ziele, OKRs (Objectives \u0026amp; Key Results) und die Strategie von Zühlke Schweiz ausgerichtet. Die Value-Stream-Leads bereiteten ihre Epics (einschliesslich der MVPs) vor, während die Coaches sich auf die Überprüfung der Informationen, die Agenda, Kalendereinladungen, virtuelle Forum-Diskussionsräume und die Berechnungsgrundlage konzentrierten. Das SAFe Excel Template für das PB-Event war hier hilfreich. Und da die Coaches zertifizierte SAFe® 5 Program Consultants sind, hatten sie Zugang zu allen notwendigen Ressourcen.\nDas Feedback der Value-Stream-Leads und die Retrospektiven der Coaches führten zu zwei wesentlichen Änderungen in der ersten Stufe: Um die Dinge einfacher und weniger verwirrend für die Teilnehmer zu gestalten, wurde in der zweiten Version von Zühlkes partizipativem Budgetierungsprozess nicht mehr zwischen den beiden Budgetaspekten «Grow the Business» (GTB) und «Run the Business» (RTB) unterschieden. Ausserdem erhielten die Teilnehmer zwei zusätzliche Wochen zur Vorbereitung und wurden gebeten, sich stärker auf den Inhalt der Epics zu konzentrieren.\nIn der zweiten Stufe gab es ein zusätzliches Informationsmeeting für alle Value Streams. Die neue Zusammensetzung der Value Streams wurde ebenfalls berücksichtigt; Erdbeeren waren nun auch im Portfolio vertreten. Alle Value-Stream-Leads bereiteten sich auf das Vorab-Meeting vor. Das Ziel war, mehr über die geplanten Epics zu erfahren und die Interaktion zwischen den Value Streams anzuregen, um potenzielle Prioritäten und Kooperationen vor dem Event zu identifizieren.\nDie Stufen drei und vier blieben im Wesentlichen gleich. In dieser zweiten Runde erhielt das Event mehr Aufmerksamkeit und Unterstützung vom Management. Das Management-Team nahm als stilles Publikum am Event teil. Die Budgetierung blieb in der Verantwortung der Value-Stream-Leads.\nIterativ lernen und verbessern # Zwei der vier beschriebenen Unterschiede zwischen Version eins und zwei des partizipativen Budgetierungsevents waren organisatorischer Natur:\nDas Informationsmeeting diente dazu, den Epic-Kontext im Detail zu verstehen. Der verlängerte Zeitrahmen reduzierte den Druck und erleichterte kreative Zusammenarbeit. Zusätzlich wurde die partizipative Budgetierungsphase auf vier Wochen verlängert. Obwohl das doppelt so lang ist, war die gemeinsam investierte Zeit (Meetings, Budgetierung) ungefähr gleich.\nDie Aufmerksamkeit des Managements verlieh der gewählten Methode mehr Gewicht und trug so dazu bei, die Akzeptanz innerhalb der Organisation zu steigern. Diese stärkere Unterstützung erleichterte es, Diskussionen über die Epics anzustossen, breiteres Interesse zu wecken und die Unterstützung von nicht involvierten Zühlke-Kollegen zu gewinnen.\nDie beiden anderen Änderungen waren prozessbezogen und hatten einen erheblichen Einfluss auf den Verlauf des Events:\nDie allgemeine Zühlke-Strategie, Ziele und OKRs sind nicht mehr die einzigen entscheidenden Faktoren für die Epics, da die Geschäftshypothese des Epics nun zusätzlich Richtlinien unterliegt. In der zweiten Runde wurde hierfür ein Schwellen- oder Relevanzwert eingeführt; ein Epic wurde nur dann in diesem Event diskutiert, wenn es einen von drei Werten erfüllte:\nDrei oder mehr Value Streams waren betroffen, oder es handelte sich um eine potenzielle «neue Frucht», oder die MVP-Investition überschritt einen vorbestimmten Betrag Dies stellte sicher, dass nur relevante Epic-Pitches diskutiert wurden. Andere Ideen und Vorschläge konnten in den individuellen Aufgaben der Value Streams eingebracht werden.\nDeshalb war die zweite Prozess- und Workflow-Änderung notwendig; die Bestimmung des RTB-Anteils am Budget war nicht mehr Teil des Budgetierungsevents selbst, sondern wurde im Voraus vom Fruitmix-Gremium anhand einer transparenten, aber vertraulichen, intern bei Zühlke entwickelten Formel berechnet. Dies gab den einzelnen Value Streams mehr Autonomie bei der Verwaltung ihrer kleineren Projekte und Themen. Gleichzeitig erhielten die Haupt-Epics (GTB) mehr Aufmerksamkeit durch ein Budgetierungsevent, das ausschliesslich ihnen gewidmet war. Das Gesamtbudget für das Event wurde proportional zum vorab zugeteilten RTB-Anteil reduziert.\nGemeinsam ein angepasstes Erfolgsrezept schaffen # Die angepassten Vorbereitungsmassnahmen erwiesen sich während des Events schnell als wirksam. Die Value-Stream-Leads waren gut vorbereitet und über die zu diskutierenden Epics informiert. Die Pitches zu den Anpassungen und Änderungen der Epics verliefen reibungslos. Gleichzeitig sparte das Überspringen der RTB-Budgetierungsrunde wertvolle 45 Minuten, die in eine effektive Budgetierung für die innovativen neuen Services investiert werden konnten.\nDer partizipative Budgetierungsprozess im Zühlke-«Fruitmix»-Portfolio hat seit der ursprünglichen Idee verschiedene Veränderungen durchlaufen: von der SAFe-Version der partizipativen Budgetierung als Werkzeug über die Erkenntnisse aus der ersten und zweiten Runde. Das Erfolgsrezept ist einfach: iterative Verbesserung hin zu einer immer massgeschneiderteren Lösung.\nAls Coaches wollen wir nun weiter daran arbeiten und den Prozess kontinuierlich verbessern. Die hervorragenden Erkenntnisse aller Teilnehmer sowie regelmässige Diskussionen zum Thema werden uns dabei besonders nützlich sein. Potenzielle Schwerpunkte für die dritte Runde könnten eine verfeinerte Version des Epic Templates und die Einbeziehung der mittelfristigen Ziele (MOALs) in die Epic-Bewertung sein. Ein zusätzlicher Vorteil ist, dass die Value-Stream-Leads nun wesentlich mehr Erfahrung mit dem Prozess haben, was dazu beitragen wird, die Abläufe zu straffen und die Workflows flüssiger zu gestalten. Dieses Potenzial soll in der nächsten partizipativen Budgetierungsrunde ausgeschöpft werden. Bleiben Sie dran!\nZühlkes Prozesse, Investitionen, Mitarbeitende, Portfolios und Lösungen wurden für diesen Artikel anonymisiert. Und da wir alle grosse Frucht-Fans sind, haben wir uns ein fruchtiges Thema für unsere digitalen Ideen ausgedacht. Co-Autorin: Nadine Broghammer\nOriginalbeitrag: Zühlke | Medium\n","date":"28. March 2022","externalUrl":null,"permalink":"/de/blogs/partizipative-budgetierung-finanzierung-auf-dem-naechsten-level/","section":"Blogs","summary":" Eine Lösung für alles? Von wegen! Partizipative Budgetierung verlangt nach einer massgeschneiderten Lösung, die sich ständig weiterentwickeln und an die jeweilige Situation anpassen kann. In diesem Artikel beschreiben wir, wie wir das bei Zühlke umsetzen.\n","title":"Partizipative Budgetierung: Finanzierung auf dem nächsten Level","type":"blogs"},{"content":"","date":"28. March 2022","externalUrl":null,"permalink":"/de/tags/portfoliomanagement/","section":"Tags","summary":"","title":"Portfoliomanagement","type":"tags"},{"content":"","date":"12 March 2022","externalUrl":null,"permalink":"/en/tags/assessment/","section":"Tags","summary":"","title":"Assessment","type":"tags"},{"content":"","date":"12 March 2022","externalUrl":null,"permalink":"/en/tags/scaled-agile/","section":"Tags","summary":"","title":"Scaled Agile","type":"tags"},{"content":"","date":"12 March 2022","externalUrl":null,"permalink":"/en/tags/training/","section":"Tags","summary":"","title":"Training","type":"tags"},{"content":" Das SAFe® for DevOps Training ist ein Assessment oder ein Workshop, der ideal für Teams geeignet ist. Warum? Weil der Fokus darauf liegt, den Wertstrom dieser Teams voranzutreiben. Indem wir Fragen, Herausforderungen und mögliche Hindernisse adressieren, können wir am Training arbeiten, um ihnen Mehrwert zu bieten. Wir geben den Teams den Theorie-Input, was DevOps genau ist.\nEin Mehrwert ist, dass wir auch SAFe® for DevOps für den Health Radar berühren, sodass sie in der Lage sind, sich selbst in verschiedenen Disziplinen von DevOps zu bewerten, gefolgt von Value Stream Mapping, um die Schritte aufzuzeichnen, die nötig sind, um eine Idee in die Produktion zu bringen. Das ist der aktuelle Wertstrom, und damit leiten wir den zukünftigen Wertstrom ab. Mit dem zukünftigen Wertstrom erstellen wir eine Reihe von Action Items, die priorisiert werden. Das Team verlässt diesen Kurs mit seinem aktuellen Wertstrom, dem zukünftigen Wertstrom, dem Assessment und dem klaren Set an Action Items, an denen es nach dem Kurs direkt arbeiten kann.\nWas man in diesem Kurs lernen kann:\n● Was ist DevOps und welche Bedeutung hat es heute in Unternehmen?\n● Die Bedeutung von Continuous Testing\n● Was genau ist Continuous Security?\n● Mappe deinen aktuellen Wertstrom und den zukünftigen Wertstrom\n● Miss den Fluss von Ideen durch die Delivery-Pipeline\n● Identifiziere Engpässe und leite den zukünftigen Wertstrom ab\n● Verstehe DevOps für den Health Radar\n● Verbessere Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand\n● Nutze den Action Plan für Teams, an dem sie nach dem Kurs direkt arbeiten können\nWas, wenn wir nur ein Team sind und kein Agile Release Train (ART)?\nDas ist kein Problem, du kannst als einzelnes Team kommen. Es stützt sich nicht ausschliesslich auf ein Scaled-Agile-Framework, einige Begriffe mögen auftauchen, aber wir werden sie für maximales Verständnis stets erklären.\nNach diesem Kurs bist du direkt in der Lage, an deiner Continuous-Delivery-Pipeline zu arbeiten und sie mit deinem Team zu verbessern.\nKursübersicht\nOriginal Post: Medium\n","date":"12. March 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-safe-fuer-devops-kurs/","section":"Blogs","summary":" Das SAFe® for DevOps Training ist ein Assessment oder ein Workshop, der ideal für Teams geeignet ist. Warum? Weil der Fokus darauf liegt, den Wertstrom dieser Teams voranzutreiben. Indem wir Fragen, Herausforderungen und mögliche Hindernisse adressieren, können wir am Training arbeiten, um ihnen Mehrwert zu bieten. Wir geben den Teams den Theorie-Input, was DevOps genau ist.\n","title":"Was ist der SAFe® for DevOps Kurs?","type":"blogs"},{"content":" The SAFe® for DevOps training is an assessment or a workshop that is ideally suited for teams. Why? Because the focus is on driving the value stream of these teams. Addressing questions, challenges, and any potential obstacles - we can work on the training to provide value to them. We will give them the theory input of what exactly DevOps is.\nValue addition is that we will also touch upon SAFe® for DevOps for health radar so that they are equipped to assess themselves in different disciplines of DevOps, followed by value stream mapping to chart out the steps needed to bring an idea into production. This is the current value stream and with this, we will derive the future value stream. With the future value stream, we will create a set of action items that are prioritized. The team will leave this course with their current value stream, future value stream, assessment and the clear set of action items which they can directly work on after the course.\nWhat one can learn from this course:\n● What is DevOps and its importance in companies today?\n● The importance of continuous testing\n● What exactly is continuous security?\n● Map your current value stream and the future value stream\n● Measure flow of ideas through the delivery pipeline\n● Identify bottlenecks and derive future value stream\n● Understand DevOps for health radar\n● Improve continuous exploration, continuous integration, continuous deployment and release on demand\n● Use the action plan for teams to directly use to work after the course\nWhat if we are only one team and not an Agile Release Train (ART)\nThis is not a problem, you can come as a single team. It is not solely resting upon a scaled agile framework, some terms may pop up but we will always explain it for maximum understanding.\nAfter this course, you will be directly be equipped to work on your continuous delivery pipeline and improve it with your team.\nCourse overview\nOriginal Post: Medium\n","date":"12 March 2022","externalUrl":null,"permalink":"/en/blogs/what-is-safe-for-devops-course/","section":"Blogs","summary":" The SAFe® for DevOps training is an assessment or a workshop that is ideally suited for teams. Why? Because the focus is on driving the value stream of these teams. Addressing questions, challenges, and any potential obstacles - we can work on the training to provide value to them. We will give them the theory input of what exactly DevOps is.\n","title":"What is SAFe® for DevOps Course?","type":"blogs"},{"content":"","date":"7 March 2022","externalUrl":null,"permalink":"/en/tags/retrospective/","section":"Tags","summary":"","title":"Retrospective","type":"tags"},{"content":"","date":"7. March 2022","externalUrl":null,"permalink":"/de/tags/retrospektive/","section":"Tags","summary":"","title":"Retrospektive","type":"tags"},{"content":"Learn ist der letzte Schritt des SAFe for DevOps Health Radar, und in vielerlei Hinsicht der wichtigste. Hier treffen wir die schwierigen Entscheidungen darüber, wo wir investieren, wo wir aufhören und wie wir alles, was wir tun, kontinuierlich verbessern. In diesem Video erkläre ich, was der Learn-Schritt umfasst und warum er der Schlüssel ist, um das Richtige richtig zu bauen.\nDer Weg zum Learn-Schritt # Bevor wir zum Learn-Schritt gelangen, haben wir die gesamte Continuous Delivery Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren die Hypothese, erfassen sie im Epic Hypothesis Statement, forschen gemeinsam nach dem echten Kundenbedürfnis, entwerfen die minimale Architektur und brechen das Epic in priorisierte Features auf dem Backlog herunter.\nDann entwickeln wir User Stories, committen Code, bauen deploybare Artefakte, testen End-to-End, deployen in die Staging-Umgebung und deployen in die Produktion mit dem Feature Toggle ausgeschaltet. Wir verifizieren in der Produktion, monitoren und reagieren als ganzes Team auf Incidents. Wenn das Business sagt, der Zeitpunkt ist richtig, schalten wir den Feature Toggle ein. Wir stabilisieren und messen dann, ob unsere Hypothese standhält.\nJetzt, mit all diesen Messdaten, betreten wir den Learn-Schritt.\nPivot or Persevere # Mit dem Wissen aus dem Measure-Schritt können wir eine Pivot-or-Persevere-Entscheidung treffen. Sollen wir mehr oder weniger in ein Feature oder Epic investieren?\nDas ist entscheidend, weil eines der Hauptprobleme in der heutigen Software-Entwicklung darin besteht, dass wir so viele gute Ideen haben, aber nicht genügend Ressourcen, um alle umzusetzen. Wir müssen die Epics und Features identifizieren, die den grössten Geschäftswert bringen, und in diese investieren. Nur weil wir etwas gebaut haben, heisst das nicht, dass wir es behalten, warten oder noch mehr Geld investieren müssen. Wir müssen die Sunk Costs ignorieren und uns auf das konzentrieren, was den grössten Wert für unsere Kunden bringt.\n\u0026ldquo;Nur weil wir etwas gebaut haben, heisst das nicht, dass wir ein Feature behalten oder mehr Geld investieren müssen. Wir müssen die Sunk Costs ignorieren.\u0026rdquo;\nDas verbindet sich mit dem Lean-Startup-Zyklus, der durch den gesamten SAFe DevOps Health Radar läuft. Im Hypothesize-Schritt haben wir die Hypothese erstellt. Im Measure-Schritt haben wir Daten gesammelt. Jetzt im Learn-Schritt treffen wir die Entscheidung: Ist die Hypothese bewiesen und wir investieren mehr, oder ist sie widerlegt und wir stoppen oder machen einen Pivot zu einem neuen Epic?\nValue Stream Mapping # Im Learn-Schritt analysieren wir auch unseren Wertstrom. Wir führen einen Value-Stream-Mapping-Workshop durch. So funktioniert es im Überblick:\nAlle Schritte identifizieren, die nötig sind, um eine Idee von der Entstehung in die Produktion zu bringen. Alle Personen identifizieren, die in jedem Prozessschritt benötigt werden. Die Process Time messen: die tatsächliche wertschöpfende Arbeitszeit in jedem Schritt. Die Lead Time messen: die gesamte verstrichene Zeit von einem Prozessschritt bis zum Ende des nächsten. Die Percentage Complete and Accurate (%C\u0026amp;A) messen: wie oft der Output eines Schritts vom nächsten Schritt ohne Nacharbeit genutzt werden kann. Mit diesen Daten sieht man den aktuellen Wertstrom klar, identifiziert Engpässe und fokussiert sich auf deren Beseitigung. Dann definiert man den zukünftigen Wertstrom: wo man hin möchte. Man beseitigt Engpässe, optimiert den Fluss und eliminiert unnötige Prozessschritte. Dann identifiziert man die Schritte, die nötig sind, um vom aktuellen zum zukünftigen Zustand zu gelangen.\nAlle drei Monate überprüft man den Wertstrom und bewertet, wie er sich verbessert hat. Diese kontinuierliche Analyse stellt fortlaufenden Fortschritt sicher.\nUnermüdliche Verbesserung # Der Learn-Schritt steht für unermüdliche Verbesserung. Wir pflegen und verbessern unsere Continuous Delivery Pipelines kontinuierlich, um unsere Fähigkeit zum Testen von Hypothesen zu verbessern. Diese Verbesserung geschieht durch mehrere Praktiken:\nRetrospektiven: Alle zwei Wochen hält das gesamte Team eine Retrospektive. Was lief gut? Was können wir verbessern? Das Team erstellt Backlog-Items für Verbesserungsmassnahmen und arbeitet sie im nächsten Sprint ab.\nWertstromanalyse: Den Wertstrom kontinuierlich analysieren, Engpässe identifizieren, zur Ursache vordringen und sie systematisch beheben.\nIncident Post-Mortems: Nach jedem Incident eine Post-Mortem-Analyse durchführen. Identifizieren, was in Zukunft besser gemacht werden kann, und kontinuierlich verbessern, damit solche Incidents verhindert werden.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Learn-Schritt:\nSit: Features werden nach dem Release nie evaluiert. Crawl: Features werden manchmal mit subjektiven Informationen oder einseitigen Meinungen bewertet. Walk: Hypothesen werden mit objektiven Messungen evaluiert, aber Entscheidungen werden stark von Firmenpolitik beeinflusst. Run: Hypothesen werden objektiv evaluiert. Pivot-or-Persevere-Entscheidungen werden ohne Gnade oder schlechtes Gewissen getroffen. Fly: Kontinuierliches Lernen und Experimentieren sind in der DNA der Organisation verankert. Wo steht Ihr Team auf dieser Skala? Das Ziel ist, sich in Richtung objektiver, datengetriebener Entscheidungen zu bewegen, die frei von Politik und Sunk-Cost-Denken sind.\nWas der Learn-Schritt liefert # Das Ergebnis des Learn-Schritts ist bedeutend:\nKontinuierliche Verbesserung: Man wird mit jeder Iteration besser. Jeder Sprint bringt neue Erkenntnisse und Verbesserungen für Pipeline und Prozesse.\nEine klare Sicht auf den Wertstrom: Alle, die im Wertstrom arbeiten, verstehen, wie Wert durch das System fliesst und wo die Engpässe sind. Dieses gemeinsame Verständnis bringt IT und Business in Einklang.\nSchwierige Entscheidungen auf Basis von Daten: Man hat die Informationen, die nötig sind, um zu entscheiden, ob man mehr in ein Epic oder Feature investiert oder aufhört. Diese Entscheidungen setzen Ressourcen frei, die auf die Ideen umgelenkt werden können, die den grössten Wert bringen.\nFokus auf die richtigen Dinge: Durch das Stoppen von Arbeit an widerlegten Hypothesen senkt man den Work in Process und ermöglicht den Teams, sich auf das zu konzentrieren, was wirklich zählt.\nKernaussagen # Pivot-or-Persevere-Entscheidungen datenbasiert treffen. Sunk Costs ignorieren und sich auf das konzentrieren, was den grössten Wert für Kunden bringt. Den Wertstrom regelmässig visualisieren. Alle drei Monate den Wertstrom überprüfen, um Engpässe zu identifizieren und den Verbesserungsfortschritt zu verfolgen. Unermüdliche Verbesserung praktizieren. Jeden Sprint Retrospektiven halten, Incidents mit Post-Mortems analysieren und die Delivery Pipeline kontinuierlich verbessern. Auf objektive Bewertung abzielen. Weg von Politik und subjektiven Meinungen, hin zu datengetriebenen Entscheidungen über Features und Epics. Learn schliesst den Kreislauf. Die Erkenntnisse aus Learn fliessen zurück in die Continuous Exploration und schaffen einen kontinuierlichen Zyklus aus Hypothese, Bau, Messung und Lernen. Ressourcen freisetzen durch Stoppen. Nicht jede Idee verdient fortlaufende Investition. Arbeit an widerlegten Hypothesen zu stoppen ist genauso wertvoll wie die Weiterarbeit an bewiesenen. ","date":"7. March 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-learn-safe-devops-health-radar/","section":"Blogs","summary":"Learn ist der letzte Schritt des SAFe for DevOps Health Radar, und in vielerlei Hinsicht der wichtigste. Hier treffen wir die schwierigen Entscheidungen darüber, wo wir investieren, wo wir aufhören und wie wir alles, was wir tun, kontinuierlich verbessern. In diesem Video erkläre ich, was der Learn-Schritt umfasst und warum er der Schlüssel ist, um das Richtige richtig zu bauen.\n","title":"Was ist Learn? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Learn is the last step of the SAFe for DevOps Health Radar, and in many ways it is the most important one. This is where we make the hard decisions about where to invest, where to stop, and how to continuously improve everything we do. In this video, I walk through what the Learn step involves and why it is the key to building the right thing right.\nThe Journey to Learn # Before we reach the Learn step, we have gone through the entire continuous delivery pipeline. It starts with bright ideas from the customer or the business. We extract the hypothesis, put it into an epic hypothesis statement, collaborate and research to find the real customer need, architect the minimal amount needed, and break the epic into prioritized features on a backlog.\nThen we develop user stories, commit code, build deployable artifacts, test end-to-end, deploy to staging, and deploy to production with the feature toggle off. We verify in production, monitor, and respond to incidents as a whole team. When the business says the time is right, we switch the feature toggle on. We stabilize, and then we measure whether our hypothesis holds.\nNow, with all that measurement data, we enter the Learn step.\nPivot or Persevere # With the knowledge gathered from the Measure step, we can make a pivot-or-persevere decision. Should we invest more or less in a feature or in an epic?\nThis is critical because one of the main problems in today\u0026rsquo;s software engineering is that we have so many bright ideas but not enough resources to implement them all. We need to identify the epics and features that bring the most business value and invest in those. Just because we have built something does not mean we need to keep it, maintain it, or invest more money into it. We need to ignore the sunk costs and focus on what brings the most value for our customers.\n\u0026ldquo;Just because we have built it does not mean we need to keep a feature or invest more money into it. We need to ignore the sunk costs.\u0026rdquo;\nThis connects to the lean startup cycle that runs through the entire SAFe DevOps Health Radar. In the Hypothesize step, we created the hypothesis. In the Measure step, we gathered data. Now in the Learn step, we make the decision: is the hypothesis proven and we invest more, or is it disproven and we stop or pivot to a new epic?\nValue Stream Mapping # In the Learn step, we also analyze our value stream. We conduct a value stream mapping workshop. Here is how it works in short:\nIdentify all steps needed to bring an idea from creation into production. Identify all people needed in each process step. Measure the process time: the actual value-adding work time in each step. Measure the lead time: the total elapsed time from one process step to the end of the next. Measure the percentage complete and accurate (%C\u0026amp;A): how often the output of a step can be used by the next step without rework. With this data, you can clearly see your current value stream, identify bottlenecks, and focus on removing them. Next, you define your future value stream: where you want to be. You remove bottlenecks, streamline the flow, and eliminate unnecessary process steps. Then you identify the steps needed to get from current to future state.\nEvery three months, you revisit your value stream and assess how it has improved. This continuous analysis ensures ongoing progress.\nRelentless Improvement # The Learn step is about relentless improvement. We constantly maintain and improve our continuous delivery pipelines to enhance our ability to test hypotheses. This improvement happens through several practices:\nRetrospectives: Every two weeks, the whole team holds a retrospective. What went well? What can we improve? The team creates backlog items for improvement actions and tackles them in the next sprint.\nValue stream analysis: Continuously analyze the value stream, identify bottlenecks, go to the root cause, and resolve them systematically.\nIncident post-mortems: With every incident, conduct a post-mortem analysis. Identify what can be done better, and continuously improve so that these incidents are prevented in the future.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Learn step:\nSit: Features are never evaluated post-release. Crawl: Features are sometimes evaluated using subjective information or unilateral opinions. Walk: Hypotheses are evaluated using objective measures, but actions are heavily influenced by corporate politics. Run: Hypotheses are objectively evaluated. Pivot-or-persevere decisions are made without mercy or guilt. Fly: Continuous learning and experimentation are ingrained in the DNA of the organization. Where does your team fall on this scale? The goal is to move toward objective, data-driven decisions that are free from politics and sunk-cost thinking.\nWhat Learn Produces # The output of the Learn step is significant:\nContinuous improvement: You get better and better with every iteration. Each sprint brings new insights and new improvements to your pipeline and processes.\nA clear view of the value stream: Everyone working in the value stream understands how value flows through the system and where the bottlenecks are. This shared understanding aligns IT and business.\nHard decisions based on data: You have the information needed to decide whether to invest more in an epic or feature, or to stop. These decisions free up resources that can be redirected to the ideas that bring the most value.\nFocus on the right things: By stopping work on invalidated hypotheses, you lower work in process and enable your teams to concentrate on what truly matters.\nKey Takeaways # Make pivot-or-persevere decisions based on data. Ignore sunk costs and focus on what brings the most value to customers. Map your value stream regularly. Every three months, revisit the value stream to identify bottlenecks and track improvement progress. Practice relentless improvement. Hold retrospectives every sprint, analyze incidents with post-mortems, and continuously improve your delivery pipeline. Aim for objective evaluation. Move away from politics and subjective opinions toward data-driven decisions about features and epics. Learn completes the loop. The insights from Learn flow back into Continuous Exploration, creating a continuous cycle of hypothesis, build, measure, and learn. Free up resources by stopping. Not every idea deserves continued investment. Stopping work on disproven hypotheses is just as valuable as continuing work on proven ones. ","date":"7 March 2022","externalUrl":null,"permalink":"/en/blogs/what-is-learn-safe-devops-health-radar/","section":"Blogs","summary":"Learn is the last step of the SAFe for DevOps Health Radar, and in many ways it is the most important one. This is where we make the hard decisions about where to invest, where to stop, and how to continuously improve everything we do. In this video, I walk through what the Learn step involves and why it is the key to building the right thing right.\n","title":"What is Learn? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"27 February 2022","externalUrl":null,"permalink":"/en/tags/analytics/","section":"Tags","summary":"","title":"Analytics","type":"tags"},{"content":"","date":"27 February 2022","externalUrl":null,"permalink":"/en/tags/measure/","section":"Tags","summary":"","title":"Measure","type":"tags"},{"content":"Measure ist der Schritt des SAFe for DevOps Health Radar, in dem alles zusammenkommt. Nach dem Deployment in die Produktion und der Stabilisierung sammeln wir nun qualitative und quantitative Informationen über unsere Epics und Features. Das Ziel ist es, unsere Hypothesen zu validieren und fundierte strategische Entscheidungen zu treffen. In diesem Video erkläre ich, was der Measure-Schritt umfasst und warum er essenziell ist, um das Richtige zu bauen.\nDer gesamte Weg zum Measure-Schritt # Bevor wir zum Measure-Schritt gelangen, haben wir die gesamte Continuous Delivery Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Wir nehmen diese Ideen, fassen sie in Epics zusammen und identifizieren die echte Hypothese hinter jedem Epic mithilfe des Epic Hypothesis Statements.\nVon dort aus forschen wir gemeinsam, um den echten Marktbedarf oder Kundenbedarf zu ermitteln. Dann entwerfen wir die minimale Architektur, die nötig ist, um die Hypothese zu beweisen. Im Synthesize-Schritt brechen wir das Epic in Features herunter, priorisieren sie auf einem Backlog, erstellen eine Roadmap und arbeiten unsere Vision aus.\nMit diesen Features gehen wir in die Entwicklung. Wir brechen Features in User Stories herunter, entwickeln sie, committen Quellcode in die Versionskontrolle und bauen deploybare Artefakte. Diese Artefakte werden End-to-End getestet und in eine Staging-Umgebung für die abschliessende Verifikation deployed. Dann deployen wir in die Produktion mit dem Feature Toggle ausgeschaltet.\nWir verifizieren mit einer Teilmenge der Tests, dass alles in der Produktion funktioniert, und monitoren das System kontinuierlich. Wenn etwas passiert, werden wir alarmiert und reagieren als ein Team. Wenn das Business sagt, der Zeitpunkt ist richtig, schalten wir den Feature Toggle ein, stabilisieren die Produktionsumgebung und prüfen, ob alles gemäss den SLAs funktioniert.\nJetzt betreten wir den Measure-Schritt.\nWas im Measure-Schritt passiert # Im Measure-Schritt sammeln wir sowohl qualitative als auch quantitative Informationen über unsere Epics und Features in der Produktion. Der Kernzweck ist es, den Geschäftswert hinter unseren Epics und Features zu identifizieren und die Hypothesen zu beweisen oder zu widerlegen, die wir ganz am Anfang aufgestellt haben.\nDiese Daten ermöglichen es uns, fundierte strategische Entscheidungen zu treffen. Zum Beispiel können wir entscheiden, in bestimmte Epics oder Features nicht mehr zu investieren, oder wir bestätigen, dass eine Hypothese wahr ist, und entscheiden, mehr zu investieren.\nZurück zur Hypothese # Im Hypothesize-Schritt haben wir Epics und ihre zugrunde liegenden Hypothesen mithilfe des Epic Hypothesis Statements definiert. Hinter jeder bedeutenden Initiative steht eine Hypothese, und mit dem Lean-Startup-Zyklus versuchen wir, das minimale brauchbare Produkt zu identifizieren, das wir bauen können, um zu beweisen, ob die Hypothese wahr oder falsch ist.\nDer Schlüssel zu dieser Validierung sind die Leading Indicators. Mit Leading Indicators können wir identifizieren, ob wir das Richtige bauen. Um diese Indikatoren zu erfassen, nutzen wir die Application Telemetry, die wir in unsere Lösung eingebaut haben.\nNatürlich müssen wir die Geschäftsergebnisse mit der Telemetrie korrelieren, um festzustellen, ob die Hypothese wahr oder falsch ist. Wichtig ist, auf Vanity Metrics zu achten. Die Anzahl der Downloads zum Beispiel könnte nicht die richtige Metrik oder der richtige Leading Indicator in Ihrem Fall sein. Was als Vanity Metric gilt, kann auch vom spezifischen Kontext abhängen, in dem man sich befindet.\nFeature-Benefit-Hypothesen messen # Wir messen nicht nur die Hypothese unserer Epics. Wir messen auch die Benefit Hypothesis unserer Features und Enabler Features. Im Synthesize-Schritt haben wir das Epic in Features heruntergebrochen. Jedes Feature hat einen Titel, eine Reihe von Akzeptanzkriterien und wichtige nicht-funktionale Anforderungen. Aber das Wichtigste an einem Feature ist die Benefit Hypothesis, und genau diese validieren wir im Measure-Schritt.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Measure-Schritt:\nSit: Wir definieren oder messen den Wert von Features nicht. Crawl: Wir haben definiert, was \u0026ldquo;Wert\u0026rdquo; ist, wissen aber nicht, wie man ihn misst. Walk: Wir erfassen qualitatives Feedback vom Business über den Wert unserer Features. Run: Wir erfassen qualitatives und quantitatives Feedback vom Business und unseren Monitoring-Systemen über den Wert unserer Features. Fly: Wir aggregieren das quantitative und qualitative Feedback, um die ursprüngliche Hypothese objektiv zu validieren und Pivot-or-Persevere-Entscheidungen zu informieren. Wo steht Ihr Team auf dieser Skala? Das Ziel ist, zu einem Zustand zu gelangen, in dem Daten Ihre Hypothesen objektiv validieren und direkt Ihre Investitionsentscheidungen informieren.\nTools für den Measure-Schritt # Beim Blick auf die periodische Tabelle der DevOps-Tools fallen die relevanten Tools für den Measure-Schritt in die Kategorie AIOps und Analytics. Drei Beispiele:\nMatomo: Eine gute Wahl, wenn man sich in einer On-Premises-Umgebung befindet. Google Analytics: Eine weit verbreitete Option, wenn man in der Cloud ist. Dynatrace: Eine umfassende Observability-Plattform für Monitoring und Analytics. Was der Measure-Schritt liefert # Das Ergebnis des Measure-Schritts ist klar:\nValidierte Hypothesen: Für Epics können wir feststellen, ob die Hypothese wahr oder falsch ist. Für Features prüfen wir, ob die Benefit Hypothesis erfüllt wurde.\nFundierte Entscheidungen: Mit qualitativen und quantitativen Daten können wir strategische Entscheidungen darüber treffen, wo wir mehr investieren, wo weniger, und wo wir ganz aufhören.\nIdentifikation des Geschäftswerts: Wir erhalten ein klares Bild davon, ob unsere Epics und Features den erwarteten Geschäftswert liefern.\nKernaussagen # Measure ist der Schritt, in dem alles zusammenkommt. Alle vorherigen Schritte des SAFe DevOps Health Radar führen zu diesem Punkt, an dem wir validieren, ob wir das Richtige gebaut haben. Sowohl qualitative als auch quantitative Daten sammeln. Beide Arten von Feedback sind nötig, um ein vollständiges Bild des gelieferten Werts von Features und Epics zu erhalten. Hypothesen mit Leading Indicators validieren. Application Telemetry nutzen und mit Geschäftsergebnissen korrelieren, um Hypothesen zu beweisen oder zu widerlegen. Auf Vanity Metrics achten. Nicht jede Metrik, die beeindruckend aussieht, ist wirklich aussagekräftig. Leading Indicators wählen, die den tatsächlichen Wert widerspiegeln, den man liefern möchte. Fundierte strategische Entscheidungen ermöglichen. Die Daten aus dem Measure-Schritt befähigen Teams und Führung, objektive, faktenbasierte Entscheidungen über Investitionen und Richtung zu treffen. Dieser Schritt führt in den Learn-Schritt. Die hier gesammelten Erkenntnisse fliessen direkt in den Learn-Schritt, wo Pivot-or-Persevere-Entscheidungen getroffen werden. ","date":"27. February 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-measure-safe-devops-health-radar/","section":"Blogs","summary":"Measure ist der Schritt des SAFe for DevOps Health Radar, in dem alles zusammenkommt. Nach dem Deployment in die Produktion und der Stabilisierung sammeln wir nun qualitative und quantitative Informationen über unsere Epics und Features. Das Ziel ist es, unsere Hypothesen zu validieren und fundierte strategische Entscheidungen zu treffen. In diesem Video erkläre ich, was der Measure-Schritt umfasst und warum er essenziell ist, um das Richtige zu bauen.\n","title":"Was ist Measure? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Measure is the step of the SAFe for DevOps Health Radar where everything comes together. After deploying to production and stabilizing, we now collect qualitative and quantitative information about our epics and features. The goal is to validate our hypotheses and make informed strategic decisions. In this video, I walk through what the Measure step involves and why it is essential for building the right thing.\nThe Full Journey to Measure # Before we reach the Measure step, we have gone through the entire continuous delivery pipeline. It starts with bright ideas from the customer or the business. We take these ideas and put them into epics, identifying the real hypothesis behind each epic using the epic hypothesis statement.\nFrom there, we collaborate and research to find the real market need or customer need. Then we architect the minimal amount of architecture needed to prove the hypothesis. In the synthesize step, we break down the epic into features, prioritize them on a backlog, build up a roadmap, and elaborate on our vision.\nWith these features, we move into development. We break features into user stories, develop them, commit source code to version control, and build deployable artifacts. These artifacts are tested end-to-end and deployed to a staging environment for final verification. Then we deploy to production with the feature toggle off.\nWe verify with a subset of tests that everything works in production and continuously monitor the system. If anything happens, we get alerted and respond as one team. When the business says the time is right, we switch on the feature toggle, stabilize the production environment, and check that everything works according to SLAs.\nNow we enter the Measure step.\nWhat Happens in the Measure Step # In the Measure step, we collect both qualitative and quantitative information about our epics and features in production. The core purpose is to identify the business value behind our epics and features, and to prove or disprove the hypotheses we stated at the very beginning.\nThis data enables us to make informed strategic decisions. For example, we might decide to stop investing in certain epics or features, or we might confirm that a hypothesis is true and decide to invest more.\nConnecting Back to the Hypothesis # Back in the Hypothesize step, we defined epics and their underlying hypotheses using the epic hypothesis statement. Every significant initiative has a hypothesis behind it, and with the lean startup cycle, we try to identify the minimal viable product that we can build to prove if that hypothesis is true or false.\nThe key to this validation is the use of leading indicators. With leading indicators, we can identify if we are building the right thing. To gather these indicators, we use the application telemetry that we have built into our solution.\nOf course, we need to correlate the business results with the telemetry to determine if the hypothesis is true or false. It is important to be aware of vanity metrics. The number of downloads, for example, might not be the right metric or leading indicator in your case. What counts as a vanity metric can also depend on the specific context you are working in.\nMeasuring Feature Benefit Hypotheses # We do not only measure the hypothesis of our epics. We also measure the benefit hypothesis of our features and enabler features. In the Synthesize step, we broke the epic down into features. Each feature has a title, a set of acceptance criteria, and important non-functional requirements. But the most important thing about a feature is its benefit hypothesis, and this is exactly what we validate in the Measure step.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Measure step:\nSit: We don\u0026rsquo;t define or measure the value of features. Crawl: We\u0026rsquo;ve defined what \u0026ldquo;value\u0026rdquo; is but don\u0026rsquo;t know how to measure it. Walk: We capture qualitative feedback from the business about the value of our features. Run: We capture qualitative and quantitative feedback from the business and our monitoring systems about the value of our features. Fly: We aggregate the quantitative and qualitative feedback to objectively validate the original hypothesis and inform pivot-or-persevere decisions. Where does your team fall on this scale? The goal is to move toward a state where data objectively validates your hypotheses and directly informs your investment decisions.\nTools for the Measure Step # Looking at the periodic table of DevOps tools, the tools relevant for the Measure step fall into the AIOps and analytics category. Three examples:\nMatomo: A strong choice when you are in an on-premises environment. Google Analytics: A widely used option when you are in the cloud. Dynatrace: A comprehensive observability platform for monitoring and analytics. What Measure Produces # The output of the Measure step is clear:\nValidated hypotheses: For epics, we can determine whether the hypothesis is true or false. For features, we verify whether the benefit hypothesis has been fulfilled.\nInformed decisions: With qualitative and quantitative data, we can make strategic decisions about where to invest more, where to invest less, and where to stop entirely.\nBusiness value identification: We gain a clear picture of whether our epics and features deliver the expected business value.\nKey Takeaways # Measure is where everything comes together. All previous steps in the SAFe DevOps Health Radar lead to this point, where we validate whether we built the right thing. Collect both qualitative and quantitative data. Both types of feedback are needed to get a complete picture of the value delivered by features and epics. Validate hypotheses with leading indicators. Use application telemetry and correlate it with business results to prove or disprove your hypotheses. Watch out for vanity metrics. Not every metric that looks impressive is actually meaningful. Choose leading indicators that truly reflect the value you are trying to deliver. Enable informed strategic decisions. The data from the Measure step empowers teams and leadership to make objective, fact-based decisions about investment and direction. This step feeds into Learn. The insights gathered here flow directly into the Learn step, where pivot-or-persevere decisions are made. ","date":"27 February 2022","externalUrl":null,"permalink":"/en/blogs/what-is-measure-safe-devops-health-radar/","section":"Blogs","summary":"Measure is the step of the SAFe for DevOps Health Radar where everything comes together. After deploying to production and stabilizing, we now collect qualitative and quantitative information about our epics and features. The goal is to validate our hypotheses and make informed strategic decisions. In this video, I walk through what the Measure step involves and why it is essential for building the right thing.\n","title":"What is Measure? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"17 February 2022","externalUrl":null,"permalink":"/en/tags/production-stability/","section":"Tags","summary":"","title":"Production Stability","type":"tags"},{"content":"","date":"17. February 2022","externalUrl":null,"permalink":"/de/tags/produktionsstabilit%C3%A4t/","section":"Tags","summary":"","title":"Produktionsstabilität","type":"tags"},{"content":"","date":"17 February 2022","externalUrl":null,"permalink":"/en/tags/sla/","section":"Tags","summary":"","title":"SLA","type":"tags"},{"content":"Nachdem wir ein neues Feature für unsere Nutzer freigegeben haben, müssen wir sicherstellen, dass alles reibungslos läuft. Stabilize ist die Aktivität im SAFe DevOps Health Radar, die sich auf die Aufrechterhaltung eines hohen Niveaus an Geschäftskontinuität konzentriert, damit wir unseren Kunden kontinuierlich Mehrwert liefern können. In diesem Video erkläre ich, was Stabilize umfasst und warum es für eine stabile, widerstandsfähige Produktionsumgebung unverzichtbar ist.\nWo Stabilize in die Pipeline passt # Der SAFe DevOps Health Radar beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren eine Hypothese, erstellen ein Epic, forschen gemeinsam nach dem echten Kundenbedürfnis, entwerfen die minimale Architektur und brechen das Epic in Features herunter. Wir entwickeln User Stories, committen Code, bauen deploybare Artefakte, testen End-to-End, deployen in die Staging-Umgebung und dann in die Produktion mit ausgeschaltetem Feature Toggle. Nach der Verifizierung in der Produktion und dem Monitoring reagieren wir auf alle Incidents. Wenn der richtige Zeitpunkt gekommen ist, schalten wir den Feature Toggle ein und geben das Feature für die Nutzer frei.\nJetzt kommt Stabilize. Das Feature ist live und wir müssen sicherstellen, dass alles weiterhin zuverlässig funktioniert.\nArchitektur für Betriebsfähigkeit # Im Architecture-Schritt, den wir früher in dieser Serie behandelt haben, entwerfen wir die Architektur für Betriebsfähigkeit. All diese Entscheidungen kommen jetzt in Stabilize zusammen. Wenn wir keine ordentlichen operativen Fähigkeiten in unser System eingebaut haben, werden wir jetzt Schwierigkeiten haben.\nGute Betriebsfähigkeit bedeutet:\nUmfassendes Logging, das alle Daten erfasst, die wir während der Stabilisierung benötigen Telemetrie, um das Systemverhalten in Echtzeit zu beobachten Feature Toggles, um Features bei Bedarf ein- und auszuschalten Wiederherstellungsmechanismen, damit wir schnell reagieren können, wenn etwas schiefgeht Disaster Recovery # Ausfälle werden in der Produktion passieren. Selbst die grossen Player wie Google, Amazon und Facebook haben katastrophale Situationen erlebt. Deshalb ist eine Disaster-Recovery-Strategie unverzichtbar.\nFeatures müssen so gestaltet sein, dass sie Disaster Recovery unterstützen. In einem Katastrophenszenario sollte man in der Lage sein, kürzlich deployte Features abzuschalten, um das Problem zu isolieren. Vor allem muss die Disaster-Recovery-Strategie regelmässig geprobt und idealerweise automatisiert und häufig getestet werden.\nProaktive Erkennung und teamübergreifende Zusammenarbeit # Wenn wir ein ordentliches Monitoring-System haben, können wir Alerts auf gefährliche Schwellenwerte setzen. Wird ein Schwellenwert erreicht, wird das Team benachrichtigt und die teamübergreifende Zusammenarbeit beginnt. Das gesamte Team, das über den Wertstrom hinweg arbeitet, analysiert das Problem gemeinsam, nicht gegeneinander, und löst es zusammen.\nNach jedem Incident führen wir ein Incident Post-Mortem durch. Wir identifizieren, was wir tun können, um solche Incidents in Zukunft zu verhindern, und setzen entsprechende Massnahmen um.\nSicherheit in der Produktion # Im Build-Schritt scannen wir bereits nach Sicherheitslücken in unserem Anwendungscode und in Bibliotheken. Aber nur den neu erstellten Code zu scannen reicht nicht aus. Code, der bereits in der Produktion läuft, braucht ebenfalls kontinuierliche Aufmerksamkeit.\nWir nutzen Security Information and Event Management (SIEM) Systeme, die eine Echtzeitanalyse von Sicherheitswarnungen liefern. So testen wir unsere laufenden Services kontinuierlich auf Schwachstellen, Angriffe und Eindringlinge.\nMonitoring der nicht-funktionalen Anforderungen # Im Test-End-to-End-Schritt haben wir unsere nicht-funktionalen Anforderungen definiert und automatisierte Tests dafür eingerichtet. In Stabilize überwachen wir alle diese Anforderungen kontinuierlich: Zuverlässigkeit, Leistung, Wartbarkeit, Skalierbarkeit, Benutzerfreundlichkeit und mehr.\nNicht-funktionale Anforderungen sind Einschränkungen für jedes Backlog-Element. Alles, was wir am System ändern, muss diesen entsprechen. Deshalb ist kontinuierliches Monitoring so wichtig.\nSLIs, SLOs und SLAs # Das Verständnis von Service Level Indicators, Objectives und Agreements ist entscheidend für den effektiven Betrieb eines Systems.\nService Level Indicator (SLI): Ein Prozentsatz einer wichtigen Metrik, gemessen an einem bestimmten Kriterium. Zum Beispiel: Im 95. Perzentil soll die Antwortzeit auf einer bestimmten Schnittstelle unter 400 Millisekunden liegen.\nService Level Objective (SLO): Der Prozentsatz eines SLI, den Ihr Team über einen bestimmten Zeitraum erreichen muss. Zum Beispiel: Die Antwortzeit im 95. Perzentil muss in 90% der Fälle über die nächsten 30 Tage unter 400 Millisekunden liegen.\nService Level Agreement (SLA): Die Vereinbarung mit Kunden und Nutzern, die festlegt, was passiert, wenn ein SLO verletzt wird. Zum Beispiel: Wird das SLO verletzt, fallen Strafzahlungen an oder Kunden gehen verloren.\nSite Reliability Engineering # SRE wurde um 2004 von Google eingeführt. Site Reliability Engineers sind hochqualifizierte, T-förmige Ingenieure, die sowohl in der Entwicklung als auch im Betrieb stark sind. Sie betreuen hochskalierbare und hochzuverlässige Systeme.\nDie Beziehung zwischen SRE und DevOps hängt von den Verfügbarkeitszielen ab:\nFünf Neunen (99,999%): Nur 864 Millisekunden Ausfallzeit pro Tag, 5,26 Minuten pro Jahr. SREs sind hier am besten geeignet. Vier Neunen (99,99%): Auch auf dieser Stufe bringen SREs erheblichen Mehrwert. Drei Neunen und darunter: DevOps-Praktiken sind in der Regel ausreichend. Je höher das Verfügbarkeitsziel, desto anspruchsvoller wird das Engineering. SREs bringen die spezialisierten Fähigkeiten mit, die für diese anspruchsvollen Anforderungen nötig sind.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Stabilize:\nSit: Wir erleben häufige ungeplante Ausfälle und/oder Sicherheitsverletzungen mit langen Wiederherstellungszeiten. Crawl: Wir erleben gelegentlich ungeplante Ausfälle, erholen uns aber innerhalb unserer Service Level Agreements. Walk: Wir haben sehr wenige ungeplante Ausfälle. Verfügbarkeit, Sicherheit und Disaster-Recovery-Massnahmen sind wirksam. Run: Wir haben keine ungeplanten Ausfälle. Wir planen und proben Ausfälle und Wiederherstellung. Fly: Wir maximieren die Widerstandsfähigkeit, indem wir bewusst Fehler in unsere Produktionsumgebung einschleusen und Wiederherstellungsverfahren proben. Was Stabilize produziert # Das Ergebnis der Stabilize-Aktivität ist eine Produktionsumgebung, die:\nStabil und widerstandsfähig ist Zuverlässig und verfügbar ist Unterstützbar und wartbar ist Sicher gegen Schwachstellen und Angriffe ist All dies unter Einhaltung der SLOs, die in den SLAs definiert sind. Mit Stabilize erreichen wir das hohe Mass an Geschäftskontinuität, das nötig ist, um unseren Kunden kontinuierlich Mehrwert zu liefern.\nWichtige Erkenntnisse # Früh für Betriebsfähigkeit entwerfen. Logging, Telemetrie, Feature Toggles und Wiederherstellungsmechanismen müssen von Anfang an eingebaut werden. Eine Disaster-Recovery-Strategie haben. Regelmässig proben und wo möglich automatisieren. Ausfälle werden passieren. Nicht-funktionale Anforderungen kontinuierlich überwachen. Zuverlässigkeit, Leistung und Sicherheit sind keine einmaligen Themen. SLIs, SLOs und SLAs verstehen. Sie definieren die operativen Erwartungen und Konsequenzen für Ihr System. SRE für hohe Verfügbarkeitsziele nutzen. Für fünf und vier Neunen bringt Site Reliability Engineering unverzichtbare Expertise. Bewusst Fehler einschleusen. Der höchste Reifegrad bedeutet, die Widerstandsfähigkeit des Systems proaktiv in der Produktion zu testen. ","date":"17. February 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-stabilize-safe-devops-health-radar/","section":"Blogs","summary":"Nachdem wir ein neues Feature für unsere Nutzer freigegeben haben, müssen wir sicherstellen, dass alles reibungslos läuft. Stabilize ist die Aktivität im SAFe DevOps Health Radar, die sich auf die Aufrechterhaltung eines hohen Niveaus an Geschäftskontinuität konzentriert, damit wir unseren Kunden kontinuierlich Mehrwert liefern können. In diesem Video erkläre ich, was Stabilize umfasst und warum es für eine stabile, widerstandsfähige Produktionsumgebung unverzichtbar ist.\n","title":"Was ist Stabilize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"After we release a new feature to our users, we need to make sure everything runs smoothly. Stabilize is the SAFe DevOps Health Radar activity that focuses on maintaining a high level of business continuity so we can continuously deliver value to our customers. In this video, I walk through what Stabilize involves and why it is essential for a stable, resilient production environment.\nWhere Stabilize Fits in the Pipeline # The SAFe DevOps Health Radar starts with bright ideas from the customer or business. We extract a hypothesis, create an epic, collaborate and research to identify the real customer need, architect the minimal amount needed, and break the epic into features. We develop user stories, commit code, build deployable artifacts, test end-to-end, deploy to staging, and then deploy to production with the feature toggle off. After verifying in production and monitoring, we respond to any incidents. When the time is right, we switch the feature toggle on and release the feature to users.\nNow comes Stabilize. The feature is live and we need to assure that everything continues to work reliably.\nArchitecting for Operability # If you recall the Architecture step from earlier in the series, that is where we architect for operability. All of those decisions come together in Stabilize. If we did not build proper operational capabilities into our system, we will have a hard time now.\nGood operability means:\nComprehensive logging that captures all the data we need during stabilization Telemetry to observe system behavior in real time Feature toggles to switch features on and off when needed Recovery mechanisms so we can respond quickly when something goes wrong Disaster Recovery # Failures will happen in production. Even the big players like Google, Amazon, and Facebook have experienced disastrous situations. That is why a disaster recovery strategy is essential.\nYour features need to be designed to support disaster recovery. In a disaster scenario, you should be able to switch off recently deployed features to isolate the problem. Most importantly, the disaster recovery strategy must be rehearsed often, and ideally automated and tested regularly.\nProactive Detection and Cross-Team Collaboration # When we have a proper monitoring system in place, we can create alerts on dangerous thresholds. If a threshold is reached, the team gets notified and cross-team collaboration begins. The whole team working across the value stream analyzes the problem together, not against each other, and solves it together.\nAfter every incident, we conduct an incident post-mortem. We identify what we can do to prevent such an incident from happening again and implement measures accordingly.\nSecurity in Production # In the Build step, we already scan for security vulnerabilities in our application code and libraries. But scanning only newly created code is not enough. Code that already runs in production also needs continuous attention.\nWe use Security Information and Event Management (SIEM) systems to provide real-time analysis of security alerts. This way we continuously test our running services for vulnerabilities, attacks, and intruders.\nMonitoring Non-Functional Requirements # Back in the Test End-to-End step, we defined our non-functional requirements and set up automated tests for them. In Stabilize, we continuously monitor all of these requirements: reliability, performance, maintainability, scalability, usability, and more.\nNon-functional requirements are constraints on every backlog item. Everything we change in the system must comply with them. That is why continuous monitoring is critical.\nSLIs, SLOs, and SLAs # Understanding service level indicators, objectives, and agreements is crucial for operating a system effectively.\nService Level Indicator (SLI): A percentage of an important metric measured against a specific criterion. For example: in the 95th percentile, response time must be below 400 milliseconds on a given interface.\nService Level Objective (SLO): The percentage of an SLI your team must hit over a certain period. For example: the 95th percentile response time must be below 400 milliseconds in 90% of cases over the next 30 days.\nService Level Agreement (SLA): The agreement with clients and users that defines consequences when an SLO is breached. For example: if the SLO is breached, penalties apply or customers are lost.\nSite Reliability Engineering # SRE was introduced around 2004 by Google. Site Reliability Engineers are highly skilled, T-shaped engineers who are strong in both development and operations. They maintain highly scalable and highly reliable systems.\nThe relationship between SRE and DevOps depends on your availability targets:\nFive nines (99.999%): Only 864 milliseconds of downtime per day, 5.26 minutes per year. SREs are best suited here. Four nines (99.99%): SREs add significant value at this level as well. Three nines and below: DevOps practices are typically sufficient. The higher the availability target, the more challenging the engineering becomes. SREs bring the specialized skills needed for those demanding requirements.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for Stabilize:\nSit: We experience frequent unplanned outages and/or security breaches with long recovery times. Crawl: We experience occasional unplanned outages but recover within our service level agreements. Walk: We have very few unplanned outages. Availability, security, and disaster recovery measures are effective. Run: We have no unplanned outages. We plan and rehearse failure and recovery. Fly: We maximize resiliency by deliberately injecting faults into our production environment and rehearsing recovery procedures. What Stabilize Produces # The output of the Stabilize activity is a production environment that is:\nStable and resilient Reliable and available Supportable and maintainable Secure against vulnerabilities and attacks All of this while meeting the SLOs defined in the SLAs. With Stabilize in place, we achieve the high level of business continuity needed to continuously deliver value to our customers.\nKey Takeaways # Architect for operability early. Logging, telemetry, feature toggles, and recovery mechanisms must be built in from the start. Have a disaster recovery strategy. Rehearse it often and automate where possible. Failures will happen. Monitor non-functional requirements continuously. Reliability, performance, and security are not one-time concerns. Understand SLIs, SLOs, and SLAs. They define the operational expectations and consequences for your system. Use SRE for high availability targets. For five and four nines, Site Reliability Engineering brings essential expertise. Inject faults deliberately. The highest maturity level means proactively testing your system\u0026rsquo;s resilience in production. ","date":"17 February 2022","externalUrl":null,"permalink":"/en/blogs/what-is-stabilize-safe-devops-health-radar/","section":"Blogs","summary":"After we release a new feature to our users, we need to make sure everything runs smoothly. Stabilize is the SAFe DevOps Health Radar activity that focuses on maintaining a high level of business continuity so we can continuously deliver value to our customers. In this video, I walk through what Stabilize involves and why it is essential for a stable, resilient production environment.\n","title":"What is Stabilize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"9 February 2022","externalUrl":null,"permalink":"/en/tags/canary-release/","section":"Tags","summary":"","title":"Canary Release","type":"tags"},{"content":"","date":"9 February 2022","externalUrl":null,"permalink":"/en/tags/release-management/","section":"Tags","summary":"","title":"Release Management","type":"tags"},{"content":"Release ist einer der letzten Schritte im SAFe for DevOps Health Radar. Zu diesem Zeitpunkt ist die neue Funktionalität bereits in der Produktion deployed und verifiziert. Jetzt ist es an der Zeit, die neue Funktionalität einer kleinen Gruppe von Nutzern oder allen Nutzern zugänglich zu machen. In diesem Video erkläre ich, was der Release-Schritt umfasst und warum er eine entscheidende Geschäftsentscheidung ist.\nDer Weg zum Release # Bevor wir zum Release-Schritt gelangen, haben wir die gesamte Continuous Delivery Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren die Hypothese hinter diesen Ideen und erfassen sie in Epics. Wir forschen gemeinsam, um das echte Kunden- oder Marktbedürfnis zu identifizieren. Wir entwerfen die minimale Architektur, die nötig ist, um die Hypothese zu beweisen. Dann brechen wir das Epic in Features herunter, priorisieren sie und legen sie auf ein Backlog.\nVon dort aus entwickeln wir User Stories, committen Quellcode, reintegrieren unsere Änderungen und bauen ein deploybare Artefakt. Dieses Artefakt wird End-to-End getestet, in eine Staging-Umgebung für die finale Verifikation deployed und dann in die Produktion deployed. Wir verifizieren in der Produktion, richten das Monitoring ein und reagieren auf allfällige Probleme. Jetzt sind wir bereit für das Release.\nWarum Release eine Geschäftsentscheidung ist # Die Freigabe neuer Funktionalität ist eine entscheidende Geschäftsentscheidung. Ein zu frühes Release kann grosse Auswirkungen haben, und ein zu spätes Release ebenso. Deshalb gehört die Entscheidung, wann released wird, dem Business und nicht dem Entwicklungsteam.\nGenau deshalb trennen wir Deployment von Release. Deployment bringt den kompilierten Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Durch die Trennung dieser beiden Aspekte geben wir dem Business die Möglichkeit zu entscheiden, wann der richtige Zeitpunkt für das Release neuer Funktionalität ist.\nFeature Toggles und Dark Launches # Ein Feature Toggle ist im Kern nichts anderes als eine If-Anweisung. Wenn das Feature Flag eingeschaltet ist, ist die neue Funktionalität aktiv. Wenn das Feature Flag ausgeschaltet ist, bleibt das bisherige Verhalten bestehen. Dieser einfache Mechanismus ermöglicht es uns, kontinuierlich in die Produktion zu deployen, ohne die Funktionalität für die Nutzer freizugeben.\nDieses Muster wird als Dark Launch bezeichnet. Wir deployen neue Funktionalität in die Produktion, ohne sie für die Nutzer sichtbar zu machen. Das erlaubt uns, das gesamte Monitoring und Alerting einzurichten und zu beobachten, wie sich der neue Code in der Produktion verhält, bevor ihn jemand nutzt. Feature Toggles habe ich im Detail in meinem Video zum Deploy-Schritt behandelt und das Konzept der Architektur für Releasability in meinem Video zum Architect-Schritt.\nArchitektur für Releasability # Wenn wir für Releasability architekturieren, betrachten wir unsere Lösung als ein grosses System und zerlegen es in kleinere Teile. Das können Microservices, Komponenten oder jede andere sinnvolle Zerlegung sein. Für jede dieser Komponenten definieren wir eine eigene Deployment- und Release-Strategie.\nZum Beispiel kann eine Komponente mit intensiver Entwicklung alle zwei Wochen neue Funktionalität für die Endbenutzer freigeben. Eine andere Komponente mit weniger Entwicklungsaktivität released nur bei Bedarf, wenn es etwas Sinnvolles zum Releasen gibt. Eine dritte Komponente folgt vielleicht einem monatlichen Release-Rhythmus. Die Gesamtlösung wird möglicherweise vierteljährlich released.\nSo architekturieren wir für Releasability. Es erfordert die Trennung von Deployment und Release und den Einsatz von Feature Toggles und Dark Launches.\nCanary Releases # Durch die Trennung von Deployment und Release und durch den Einsatz von Feature Toggles und Dark Launches sind wir in der Lage, Canary Releases durchzuführen. Bei einem Canary Release machen wir ein neues Feature nur für eine Teilmenge der Nutzer verfügbar. Diese können die neue Funktionalität in der Produktion testen und uns Feedback geben. Wir können dann schrittweise die Anzahl der Nutzer erhöhen, die Zugang zur neuen Funktionalität haben.\nDieser Ansatz ermöglicht es uns, Probleme sehr früh zu erkennen, und diese Probleme betreffen nur eine kleine Anzahl von Nutzern. Der Begriff \u0026ldquo;Canary Release\u0026rdquo; stammt von den Kanarienvögeln, die Bergleute in früheren Zeiten verwendeten. Sie nahmen einen Kanarienvogel mit in die Mine, und wenn der Vogel starb, wussten sie, dass es Zeit war, herauszukommen.\nCanary Releases sind weit verbreitet. Vielleicht kennen Sie sie auch unter den Begriffen Alpha-Testing, Beta-Testing oder Friends-and-Family-Release.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Release-Schritt:\nSit: Releases sind eng an Deployments gekoppelt und Kunden sind extrem unzufrieden mit der Häufigkeit der Releases. Crawl: Releases sind eng an Deployments gekoppelt, aber Kunden sind etwas unzufrieden mit der Häufigkeit der Releases. Walk: Release und Deployment sind gekoppelt, aber beide erfolgen kontinuierlich oder bei Bedarf. Run: Release ist vom Deployment entkoppelt. Deployed Features werden basierend auf der Geschäftsbereitschaft für die Endbenutzer freigegeben. Fly: Deployed Features können für einzelne Segmente der Nutzerpopulation freigegeben werden. Feature Toggles werden refactored, wenn sie nicht mehr benötigt werden. Kernaussagen # Releasing ist eine Geschäftsentscheidung. Nur das Business weiss, wann der richtige Zeitpunkt ist, eine bestimmte Funktionalität für Endbenutzer freizugeben. Deployment von Release trennen. Deployment bringt Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Feature Toggles nutzen. Ein Feature Toggle ist einfach eine If-Anweisung, die steuert, ob ein Feature für Nutzer aktiv ist. Dark Launches einsetzen. In die Produktion deployen, ohne für Nutzer freizugeben. So können Sie den neuen Code in der Produktion überwachen und validieren, bevor ihn jemand sieht. Für Releasability architekturieren. Die Lösung in kleinere Komponenten aufteilen, jede mit ihrer eigenen Deployment- und Release-Strategie. Canary Releases nutzen. Features zuerst für eine kleine Teilmenge der Nutzer verfügbar machen, Feedback sammeln und schrittweise an alle ausrollen. ","date":"9. February 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-release-safe-devops-health-radar/","section":"Blogs","summary":"Release ist einer der letzten Schritte im SAFe for DevOps Health Radar. Zu diesem Zeitpunkt ist die neue Funktionalität bereits in der Produktion deployed und verifiziert. Jetzt ist es an der Zeit, die neue Funktionalität einer kleinen Gruppe von Nutzern oder allen Nutzern zugänglich zu machen. In diesem Video erkläre ich, was der Release-Schritt umfasst und warum er eine entscheidende Geschäftsentscheidung ist.\n","title":"Was ist Release? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Release is one of the final steps in the SAFe for DevOps Health Radar. At this point, the new functionality is already deployed to production and verified. Now it is time to make the new functionality available to a small group of users or to all users. In this video, I walk through what the Release step involves and why it is a crucial business decision.\nThe Journey to Release # Before we reach the Release step, we have gone through the entire continuous delivery pipeline. It starts with bright ideas from the customer or the business. We extract the hypothesis behind these ideas and put them into epics. We collaborate and research to identify the real customer or market need. We architect the minimal amount of architecture needed to prove the hypothesis. Then we break down the epic into features, prioritize them, and put them on a backlog.\nFrom there, we develop user stories, commit source code, reintegrate our changes, and build a deployable artifact. This artifact is tested end-to-end, deployed to a staging environment for final verification, and then deployed to production. We verify in production, set up monitoring, and respond to any problems. Now we are ready to release.\nWhy Release Is a Business Decision # Releasing new functionality is a crucial business decision. Releasing too early can have a huge impact, and releasing too late can also have a negative impact. This is why the decision of when to release belongs to the business, not to the development team.\nThis is exactly why we separate deployment from release. Deployment is bringing the compiled code into production with the feature toggle turned off. Release is switching the feature toggle on. By separating these two concerns, we give the business the ability to decide when the right time is to release new functionality.\nFeature Toggles and Dark Launches # A feature toggle is, at its core, nothing more than an if-statement. If the feature flag is on, the new functionality is active. If the feature flag is off, the old behavior continues. This simple mechanism enables us to continuously deploy into production without releasing the functionality to users.\nThis pattern is called a dark launch. We deploy new functionality into production without making it visible to users. This allows us to set up all monitoring and alerting, and observe how the new code behaves in production before anyone uses it. I covered feature toggles in more detail in my video about the Deploy step and the concept of architecting for releasability in my video about the Architect step.\nArchitecting for Releasability # When we architect for releasability, we look at our solution as one big system and break it into smaller parts. These can be microservices, components, or any other decomposition that makes sense. For each of these components, we define a separate deployment and release strategy.\nFor example, one component might have heavy development going on and releases new functionality to end-users every two weeks. Another component with less development activity might release on demand, only when there is something meaningful to release. A third component might follow a monthly release cadence. The overall solution might be released every quarter.\nThis is how we architect for releasability. It requires separating deployment from release and using feature toggles and dark launches.\nCanary Releases # By separating deployment from release and by using feature toggles and dark launches, we are able to do canary releases. With a canary release, we make a new feature available to only a subset of users. They can test out the new functionality in production and give us feedback. We can then slowly increase the number of users who have access to the new functionality.\nThis approach lets us detect problems very early, and those problems only affect a small number of users. The term \u0026ldquo;canary release\u0026rdquo; comes from the canary birds that miners used in the old days. They would take a canary bird into the mine, and if the bird died, they knew it was time to get out.\nCanary releases are commonly used. You may also have heard them referred to as alpha testing, beta testing, or a friends-and-family release.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Release step:\nSit: Releases are tightly coupled to deployments and customers are extremely dissatisfied with the frequency of releases. Crawl: Releases are tightly coupled to deployments, but customers are somewhat dissatisfied with the frequency of releases. Walk: Release and deployment are coupled but both occur continuously or on-demand. Run: Release is decoupled from deployment. Deployed features are released to the end-user population based on business readiness. Fly: Deployed features can be released to individual segments of the user population. Feature toggles are refactored when no longer used. Key Takeaways # Releasing is a business decision. Only the business knows when the time is right to release a certain functionality to end-users. Separate deployment from release. Deployment brings code into production with the feature toggle off. Release switches the feature toggle on. Use feature toggles. A feature toggle is simply an if-statement that controls whether a feature is active for users. Leverage dark launches. Deploy to production without releasing to users. This lets you monitor and validate the new code in production before anyone sees it. Architect for releasability. Break your solution into smaller components, each with its own deployment and release strategy. Use canary releases. Make features available to a small subset of users first, gather feedback, and gradually roll out to everyone. ","date":"9 February 2022","externalUrl":null,"permalink":"/en/blogs/what-is-release-safe-devops-health-radar/","section":"Blogs","summary":"Release is one of the final steps in the SAFe for DevOps Health Radar. At this point, the new functionality is already deployed to production and verified. Now it is time to make the new functionality available to a small group of users or to all users. In this video, I walk through what the Release step involves and why it is a crucial business decision.\n","title":"What is Release? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Together with my colleague Nadine, I presented an updated version of our participatory budgeting approach. We had already shared the first version at a previous event, but since then we made significant changes that we wanted to share. A quick disclaimer: we did not invent participatory budgeting. We built on the materials from the SAFe (Scaled Agile Framework), so you will find the copyright on the relevant slides. If you want to introduce participatory budgeting in your own organization, we are happy to share our experience and always reference the original SAFe materials.\nThe Problem We Faced # In Q3 2020, we had the following problem. Our portfolio (anonymized as the \u0026ldquo;fruit portfolio\u0026rdquo;) included several products, and we were organized with separate teams for each product line. These teams naturally wanted to run projects to be more innovative in the market, and for that they needed funding.\nThis funding was distributed by a portfolio committee that had a fixed budget of 100,000 francs (anonymized figure). Once a year, the committee would ask the portfolio what projects they wanted to pursue. Inevitably, the total sum of requested projects was about three times higher than the available budget.\nWhat did the committee do? They looked at the requests, concluded that everyone had asked for double what they actually needed, and simply cut everything in half. Then, if someone happened to know the right people or had a persuasive conversation at the coffee machine, they might get a little more. At the end of the day, everyone was dissatisfied. The teams felt they received too little, and the committee knew they had not really distributed the money in the right way.\nDiscovering SAFe\u0026rsquo;s Participatory Budgeting # We looked around for better approaches to budgeting and came across the SAFe framework. At the portfolio level, SAFe offers participatory budgeting (PB). One thing I always emphasize: SAFe is a framework that works like a toolbox. You open it, see all the tools inside, and you pick the one you need. That is exactly what we did. We took the participatory budgeting tool and adapted it to our needs.\nVersion 1: Our First Implementation # For version 1, we took the original SAFe participatory budgeting material and applied it to our context. Our large organization has an overall budget, and a portion of that goes into the fruit portfolio. This portfolio has strategic goals and OKRs (Objectives and Key Results).\nWe reorganized our teams along value streams, following the principle of organizing around the flow of value. Each value stream sells its products within the portfolio. We then asked each value stream to prepare their epics. An epic, unlike a traditional project, has a hypothesis: something you want to test in the market. Teams had to fill out the SAFe epic template, writing down their hypothesis and how they planned to validate it.\nIn the participatory budgeting event, we distinguished between two budget categories:\nRTB (Run the Business): Everything needed to keep the value stream alive and continue selling existing products. GTB (Grow the Business): The epics for trying something new in the market to grow the business. For example, a hypothesis might be: \u0026ldquo;If we start selling plantains, we can increase our banana revenue by 10%.\u0026rdquo; In the first round, we discussed and agreed on the RTB budgets. With the remaining money, we went into a second round to discuss which GTB initiatives (epics) to fund. Some epics did not make the cut, some were modified, and some received partial funding. The feedback from this first event was overwhelmingly positive.\nWhat We Changed for Version 2 # After the first round, we collected feedback from participants, reflected on what went well and what did not, and sat down with management to introduce several changes.\nEliminating the RTB/GTB Distinction # The distinction between Run the Business and Grow the Business was confusing and sometimes hindering. People tried to game the system by labeling things as RTB or GTB depending on what seemed more advantageous. We eliminated this distinction entirely in version 2.\nReducing Information Overload # The information density was too high in version 1. Participants had to process too much in too little time. They needed more time to understand the epics from other value streams, evaluate trade-offs, and discuss options before the actual event.\nExtending the Timeline # In version 1, everything happened within a very short period: information, budgeting, and communication all in May. For version 2, we stretched the process across roughly four weeks instead of two:\nIntroduction session (one month before): We explained what an epic is, how to write a hypothesis, and what a Minimum Viable Product means. Interim meeting: We reviewed which epics from the previous half-year had been successful and introduced the new epics for the upcoming period. Participatory budgeting event: Now more focused, with time dedicated to real discussion rather than information sharing. Communication: As before, results were communicated promptly after the event. Pre-Calculating the Run the Business Portion # Instead of debating RTB at the event itself, we pre-calculated each value stream\u0026rsquo;s RTB portion using an internal formula. This freed up the event entirely for discussing growth initiatives and strategic epics.\nIntroducing Guardrails for Epics # We introduced three guardrails to keep discussions focused:\nMinimum viable size: An epic had to exceed a certain financial threshold to even be discussed at the event. Anything smaller could be funded by the value stream itself. Minimum scope: An epic had to affect at least three value streams. If only two were involved, they could arrange bilateral agreements without occupying the full group of 14 value stream leads. Openness to innovation: Despite the guardrails, we remained open to genuinely new and innovative ideas that deserved a hearing. The Revised Event Agenda # In version 1, the agenda included a management opening, two budgeting rounds (RTB and GTB), a confidence vote, and a feedback session. In version 2, we kept the management framing (opening and closing statements) but consolidated to a single budgeting round focused entirely on growth epics:\nRecap: Review of successful epics from the previous cycle. Forward look: Discussion and budgeting of new epics. Feedback and closing: With management confirmation that the agreed budget has their full support. How the Discussions Worked # We split into two rooms, each with about seven of the 14 value stream leads. Nadine and I moderated one room each, using a shared Excel template (adapted from the SAFe template). The spreadsheet showed the available budget, all proposed epics with descriptions, and their requested funding.\nParticipants proposed different options. For example: \u0026ldquo;Let us discuss an exploration option where we fund Mario\u0026rsquo;s and Luigi\u0026rsquo;s epics for new territories.\u0026rdquo; Or: \u0026ldquo;What about a momentum option where almost every epic gets partial funding?\u0026rdquo; We worked through multiple options, found agreement within each room, then reconvened in a plenary session. There, the two groups compared their proposals, discussed differences, and arrived at a unified budget.\nWhat We Learned # The feedback from version 2 was again positive overall, but several observations stood out:\nDiscussions Were Intense # This time, the discussions at the tables were significantly more intense. Participants felt they needed even more time, and we agreed. The pre-event discussions that should have happened between value stream leads did not always take place. We need to find a way to encourage those conversations before the event.\nEpic Owners vs. Value Stream Leads # In version 1, epic owners and value stream leads were the same people. In version 2, some epics were proposed by epic owners who were different from the value stream leads. This caused confusion because the lead at the table sometimes did not fully understand the epic. The feedback was clear: epic owners should be available for questions, even if they are not the primary participants.\nNo Epic Was Rejected # All epics received at least some funding. Nobody wanted to offend anyone, so budgets were reduced but never cut entirely. This was not ideal. I believe that in our next event (scheduled for May), the discussions will be harder and some epics will genuinely be stopped.\nThe RTB/GTB Confusion Persists # Even though we removed the formal RTB/GTB split, the conceptual confusion remained. Some people tried to promote routine items as epics to get them into the growth discussion. We still need to improve understanding of what truly qualifies as an epic.\nThe Epic Template Works Well # Everyone appreciates the discipline of thinking in hypotheses and leading indicators. The concept of a Minimum Viable Product resonated strongly with participants. One improvement request: show on the epic template which OKR or strategic goal the epic supports, so that epics without a clear strategic fit are immediately visible.\nTime-Boxing Works # Giving each group a fixed time to arrive at a budget proposal worked very well. It created urgency and focus.\nEntrepreneurial Thinking # The biggest positive surprise was the level of entrepreneurial thinking we observed. The value stream leads genuinely engaged with the company\u0026rsquo;s strategic goals, OKRs, and MOALs (Measures of Agile Leadership). They debated whether an epic truly advances a strategic objective or whether a different approach would be better. Management\u0026rsquo;s feedback was that the participants thought like real entrepreneurs. This was truly great to see.\nOf course, when you discuss significant sums of money and strategic direction, emotions run high. People are passionate about their products and their ideas. Good moderation is essential to ensure that quieter voices are also heard.\nConclusion # Participatory budgeting is something I can genuinely recommend. Our management is fully behind it. The greatest advantage is that at the end, everyone understands the budget: why we arrived at these numbers and what the priorities are. Everyone stands behind the result. This is not a budget dictated from above. It is a budget created participatively, where people have a voice and commit to the outcome. That makes all the difference.\n","date":"4 February 2022","externalUrl":null,"permalink":"/en/blogs/participatory-budgeting-v2-next-level-financing/","section":"Blogs","summary":"Together with my colleague Nadine, I presented an updated version of our participatory budgeting approach. We had already shared the first version at a previous event, but since then we made significant changes that we wanted to share. A quick disclaimer: we did not invent participatory budgeting. We built on the materials from the SAFe (Scaled Agile Framework), so you will find the copyright on the relevant slides. If you want to introduce participatory budgeting in your own organization, we are happy to share our experience and always reference the original SAFe materials.\n","title":"Participatory Budgeting V2.0: Next Level Financing","type":"blogs"},{"content":"Gemeinsam mit meiner Kollegin Nadine habe ich eine aktualisierte Version unseres partizipativen Budgetierungsansatzes vorgestellt. Wir hatten bereits die erste Version an einem früheren Event geteilt, aber seither haben wir einiges verändert, das wir natürlich nicht vorenthalten wollten. Ein kurzer Disclaimer: Wir haben Participatory Budgeting nicht erfunden. Wir haben auf den Vorlagen des SAFe (Scaled Agile Framework) aufgebaut, daher findet ihr auch das Copyright auf den relevanten Folien. Wenn ihr selbst Participatory Budgeting bei euch einführen wollt, sind wir gerne bereit, unsere Erfahrung zu teilen, und verweisen dabei immer auf die Originalpräsentation und Originalunterlagen von SAFe.\nDas Problem, das wir hatten # Im Q3 2020 hatten wir folgendes Problem. Unser Portfolio (anonymisiert als \u0026ldquo;Früchte-Portfolio\u0026rdquo;) umfasste verschiedene Produkte, und wir waren mit separaten Teams für jede Produktlinie aufgestellt. Diese Teams wollten natürlich Projekte durchführen, um innovativer am Markt zu sein, und dafür brauchten sie Geld.\nDieses Geld wurde von einem Portfolio-Komitee verteilt, das ein Budget von 100.000 Franken (anonymisierte Zahl) zur Verfügung hatte. Einmal im Jahr ging das Komitee hin und fragte: \u0026ldquo;Was für Projekte möchtet ihr machen, um innovativ am Markt zu sein?\u0026rdquo; Die Teams kamen mit ihren Projekten, und natürlich war die Summe dieser Projekte meistens dreimal so hoch wie das verfügbare Budget.\nWas machte das Komitee? Es schaute sich die Anträge an und sagte sich: \u0026ldquo;Die haben alle doppelt so viel beantragt wie nötig.\u0026rdquo; Also wurde alles pauschal halbiert. Dann kannte man vielleicht noch jemanden, der an der Kaffeemaschine gut zugeredet hatte, und dem gab man noch ein bisschen mehr. Am Ende des Tages waren alle unzufrieden. Die Teams hatten zu wenig bekommen, und das Komitee wusste, dass es das Geld nicht wirklich richtig verteilt hatte.\nSAFe\u0026rsquo;s Participatory Budgeting entdecken # Wir haben uns umgeschaut, was es eigentlich so für Budgetierungsmöglichkeiten gibt, und sind auf das SAFe Framework gestossen. Dort im oberen Bereich auf dem Portfolio Level gibt es das Participatory Budgeting (PB). Etwas ganz Wichtiges, das ich immer wieder erwähne: Das SAFe Framework ist wie eine Toolbox. Man macht sie auf, sieht alle Tools drin und kann sich eines herausnehmen. Genau das haben wir gemacht. Wir haben das Participatory-Budgeting-Tool herausgenommen und auf unsere Bedürfnisse angepasst.\nVersion 1: Unsere erste Umsetzung # Für Version 1 haben wir das originale SAFe Participatory Budgeting Material genommen und auf unseren Kontext angewendet. Unser grosses Unternehmen hat ein Gesamtbudget, und ein Teil davon geht in das Früchte-Portfolio. Dieses Portfolio hat strategische Ziele und OKRs (Objectives and Key Results).\nWir haben unsere Teams gemäss den Wertströmen reorganisiert, denn man muss sich ja gemäss dem Wertstrom organisieren. Jeder Value Stream verkauft seine Produkte innerhalb des Portfolios. Wir sind dann hingegangen und haben gesagt: \u0026ldquo;Was sind eure Epics?\u0026rdquo; Ein Epic hat im Gegensatz zu einem Projekt eine Hypothese, also etwas, das man am Markt austesten will. Die Teams mussten das Epic Template von SAFe ausfüllen mit ihrer Hypothese und wie sie diese am Markt validieren wollen.\nBeim Participatory Budgeting Event haben wir zwei Budget-Kategorien unterschieden:\nRTB (Run the Business): Alles, was ich brauche, um meinen Wertstrom am Leben zu erhalten und weiterhin Produkte zu verkaufen. GTB (Grow the Business): Die Epics, mit denen ich an den Markt gehe, etwas Neues ausprobiere und dadurch mehr verkaufe. Ein Epic kann zum Beispiel sein: \u0026ldquo;Unsere Hypothese ist, wenn wir Plantanen verkaufen, können wir unseren Umsatz im Bananenverkauf um zehn Prozent steigern.\u0026rdquo; Im ersten Durchlauf haben wir über das Run the Business diskutiert. Die Value Streams mussten ihr Business offenlegen, wie viel sie brauchen. Wir sind in verschiedene Räume gegangen und haben innerhalb von 15 Minuten ein Budget-Vorschlag herausgearbeitet. Mit dem Rest sind wir in die zweite Runde gegangen und haben darüber diskutiert, welche Grow-the-Business-Initiativen wir finanzieren. Gewisse Epics wurden nicht gemacht, gewisse wurden angepasst und gewisse nur teilfinanziert. Das Feedback nach diesem ersten Event war grossartig.\nWas wir für Version 2 geändert haben # Nach der ersten Runde haben wir Feedback gesammelt, selbst reflektiert, was gut und weniger gut lief, und uns mit dem Management zusammengesetzt. Daraus haben wir einige Veränderungen ins Leben gerufen.\nAbschaffung der RTB/GTB-Unterscheidung # Die Unterscheidung zwischen Run the Business und Grow the Business war verwirrend und teilweise hinderlich. Leute versuchten, das System auszutricksen, indem sie Dinge je nach Vorteil als RTB oder GTB labelten. Wir haben diese Unterscheidung in Version 2 komplett abgeschafft.\nReduktion der Informationsdichte # Die Informationsdichte war in Version 1 zu hoch. Die Teilnehmer mussten zu viel in zu wenig Zeit verarbeiten. Sie brauchten mehr Zeit, um die Epics anderer Value Streams zu verstehen, Abwägungen zu treffen und Optionen zu diskutieren, bevor der eigentliche Event stattfand.\nAnpassung der Timeline # In Version 1 fand alles innerhalb einer sehr kurzen Periode statt: Information, Budgetierung und Kommunikation, alles im Mai. Für Version 2 haben wir den Prozess auf rund vier Wochen statt zwei gestreckt:\nEinführungssession (einen Monat vorher): Wir haben erklärt, was ein Epic ist, wie man eine Hypothese schreibt und was ein Minimum Viable Product bedeutet. Zwischenmeeting: Wir haben angeschaut, welche Epics vom letzten Halbjahr erfolgreich waren und welche die neuen Epics für die kommende Periode sind. Participatory Budgeting Event: Jetzt deutlich fokussierter, mit Zeit für echte Diskussionen statt Informationsvermittlung. Kommunikation: Wie zuvor wurden die Ergebnisse zeitnah nach dem Event kommuniziert. Vorberechnung des Run-the-Business-Anteils # Statt am Event selbst über RTB zu debattieren, haben wir den RTB-Anteil jedes Value Streams vorab berechnet mit einer internen Formel. Dadurch war der Event komplett frei für die Diskussion über Wachstumsinitiativen und strategische Epics.\nEinführung von Leitplanken für Epics # Wir haben drei Leitplanken eingeführt, um die Diskussionen fokussiert zu halten:\nMinimale Grösse: Ein Epic musste einen bestimmten finanziellen Schwellenwert überschreiten, um überhaupt in dieser Runde diskutiert zu werden. Alles Kleinere konnte ein Value Stream selbst finanzieren. Minimaler Scope: Ein Epic musste mindestens drei Value Streams betreffen. Wenn nur zwei betroffen waren, konnten diese eine bilaterale Absprache treffen, ohne das gesamte Gremium von 14 Value Stream Leads zu beschäftigen. Offenheit für Innovation: Trotz der Leitplanken waren wir offen für wirklich neue, brandheisse Ideen, die eine Chance und Gehör verdient haben. Die überarbeitete Event-Agenda # In Version 1 umfasste die Agenda ein Management-Opening, zwei Budgetierungsrunden (RTB und GTB), einen Confidence Vote und eine Feedback-Session. In Version 2 haben wir das Management-Framing (Eröffnung und Schlussvotum) beibehalten, aber auf eine einzige Budgetierungsrunde konsolidiert, die sich ganz auf Wachstums-Epics konzentrierte:\nRückblick: Review der erfolgreichen Epics aus dem vorherigen Zyklus. Ausblick: Diskussion und Budgetierung der neuen Epics. Feedback und Abschluss: Mit Bestätigung des Managements, dass das vereinbarte Budget vollen Support hat. Was jetzt beschlossen wurde, hat Management Support. Darauf waren wir besonders stolz.\nWie die Diskussionen abliefen # Wir haben uns in zwei Räume aufgeteilt, jeder mit rund sieben der 14 Value Stream Leads. Nadine und ich haben je einen Raum moderiert und mit einem gemeinsamen Excel-Template gearbeitet (angepasst vom SAFe Template). Die Tabelle zeigte das verfügbare Budget, alle eingereichten Epics mit Beschreibung und deren angefragte Finanzierung.\nDie Teilnehmer brachten verschiedene Optionen ein. Zum Beispiel: \u0026ldquo;Lasst uns eine Explorations-Option diskutieren, bei der wir Marios und Luigis Epics für neue Territorien finanzieren.\u0026rdquo; Oder: \u0026ldquo;Was wäre eine Momentum-Option, bei der fast jedes Epic einen Teil des Budgets erhält?\u0026rdquo; Wir haben mehrere Optionen durchgearbeitet, Einigung innerhalb jedes Raums gefunden und uns dann im Plenum wieder getroffen. Dort haben die beiden Gruppen ihre Vorschläge verglichen, Unterschiede diskutiert und ein gemeinsames Budget erarbeitet.\nWas wir gelernt haben # Das Feedback zu Version 2 war insgesamt wieder positiv, aber einige Beobachtungen stachen hervor:\nDie Diskussionen waren intensiv # Dieses Mal waren die Diskussionen an den Tischen deutlich intensiver. Die Teilnehmer fanden, es hätte noch mehr Zeit gebraucht, und dem stimmten wir zu. Die Vorgespräche zwischen Value Stream Leads, die vor dem Event hätten stattfinden sollen, sind nicht immer passiert. Wir müssen uns etwas einfallen lassen, wie diese Diskussionen zustande kommen, denn in einer halben Stunde schnell über gewisse Epics zu diskutieren, ist einfach sehr wenig Zeit.\nEpic Owner vs. Value Stream Leads # In Version 1 waren Epic Owner und Value Stream Leads die gleichen Personen. In Version 2 gab es aber Epics, die von Epic Ownern eingebracht wurden, wo der Value Stream Lead nicht genau wusste, was dahinter steht. Das Feedback war klar: Die Epic Owner sollten für Nachfragen dabei sein, auch wenn sie nicht die primären Teilnehmer sind.\nKein Epic wurde abgelehnt # Alle Epics haben zumindest eine Teilfinanzierung erhalten. Niemand wollte jemand anderen vor den Kopf stossen, also wurden Budgets zwar reduziert, aber nie komplett gestrichen. Das war nicht ideal. Ich glaube, beim nächsten Participatory Budgeting (geplant für Mai) werden die Diskussionen härter geführt und ein paar Epics werden tatsächlich gestoppt.\nDie RTB/GTB-Verwirrung bleibt # Auch wenn wir die formale RTB/GTB-Trennung aufgehoben haben, blieb die konzeptuelle Verwirrung bestehen. Gewisse Schlaumeier haben versucht, Routine-Themen als Epics zu promoten, um sie in die Wachstumsdiskussion zu bringen. Da müssen wir noch nachbessern.\nDas Epic Template funktioniert gut # Alle finden den Gedanken des Denkens in Hypothesen und Leading Indicators grossartig. Auch das MVP-Denken (Minimum Viable Product) kommt sehr gut an. Ein Verbesserungswunsch: Bereits auf dem Epic Template ausweisen, auf welches OKR oder strategisches Ziel das Epic einzahlt, damit Epics ohne klaren strategischen Fit sofort sichtbar sind.\nTime-Boxing funktioniert # Jeder Gruppe eine fixe Zeit zu geben, um zu einem Budget-Vorschlag zu kommen, hat sehr gut funktioniert. Es schafft Dringlichkeit und Fokus.\nUnternehmerisches Denken # Die grösste positive Überraschung war das Ausmass an unternehmerischem Denken, das wir beobachten konnten. Die Value Stream Leads haben sich wirklich mit den strategischen Zielen des Unternehmens auseinandergesetzt, mit den MOALs und OKRs. Sie haben hinterfragt, ob ein Epic wirklich ein strategisches Ziel voranbringt oder ob man etwas anderes machen müsste. Das Feedback vom Management war, dass die Teilnehmer wirklich unternehmerisch gedacht haben. Das war grossartig zu sehen.\nNatürlich, wenn es um viel Geld und strategische Ausrichtung geht, gehen die Emotionen hoch. Die Leute brennen für ihre Produkte und ihre Ideen. Gute Moderation ist essenziell, damit auch leisere Stimmen gehört werden.\nFazit # Participatory Budgeting ist etwas, das ich allen empfehlen kann. Auch unser Management ist Feuer und Flamme dafür. Der ganz grosse Vorteil: Am Schluss verstehen alle das Budget. Warum sind wir auf dieses Budget gekommen? Alle stehen hinter dem Ergebnis. Das ist kein Budget, das von oben herunter diktiert wird, sondern ein Budget, das partizipativ gestaltet wird. Die Leute kommen partizipativ zu diesem Budget und stehen dahinter. Und das macht den entscheidenden Unterschied.\n","date":"4. February 2022","externalUrl":null,"permalink":"/de/blogs/participatory-budgeting-v2-next-level-finanzierung/","section":"Blogs","summary":"Gemeinsam mit meiner Kollegin Nadine habe ich eine aktualisierte Version unseres partizipativen Budgetierungsansatzes vorgestellt. Wir hatten bereits die erste Version an einem früheren Event geteilt, aber seither haben wir einiges verändert, das wir natürlich nicht vorenthalten wollten. Ein kurzer Disclaimer: Wir haben Participatory Budgeting nicht erfunden. Wir haben auf den Vorlagen des SAFe (Scaled Agile Framework) aufgebaut, daher findet ihr auch das Copyright auf den relevanten Folien. Wenn ihr selbst Participatory Budgeting bei euch einführen wollt, sind wir gerne bereit, unsere Erfahrung zu teilen, und verweisen dabei immer auf die Originalpräsentation und Originalunterlagen von SAFe.\n","title":"Participatory Budgeting V2.0: Next Level Finanzierung","type":"blogs"},{"content":"Am 1. Februar 2002 begann meine Reise bei Zühlke als Junior Software Engineer. Zwanzig Jahre später bin ich immer noch hier. In diesem Beitrag möchte ich teilen, wie diese 20 Jahre aussahen, was mich motiviert hat und warum ich plane, noch mindestens weitere 20 Jahre zu bleiben.\nDie Anfangsjahre: Start als Junior (2002-2004) # Nach einem sehr anspruchsvollen Bewerbungsgespräch wurde ich bei Zühlke eingestellt und kam in die Abteilung für Windows und Embedded Solutions, geleitet von Philipp Sutter (der heute Verwaltungsratspräsident bei Zühlke ist). Damals hatte Zühlke 219 Mitarbeitende mit Standorten in Zürich, Frankfurt und London.\nMein erstes Projekt war im Industriebereich. Dort entwickelten wir eine grosse C++-Applikation zum Entwerfen von Kraftwerken und zur Berechnung ihrer Effizienz. Von Anfang an erhielt ich Schulungen in .NET, dem Rational Unified Process und Design Patterns. Eines der grossartigsten Erlebnisse war das fünftägige Camp, bei dem die ganze Abteilung an einen abgelegenen Ort fuhr und wir gemeinsam codierten und neue Technologien erkundeten.\nGenau als ich anfing, traf die Dotcom-Krise die gesamte IT-Branche. Ich war einer der letzten Angestellten, die in den nächsten zwei Jahren bei Zühlke eingestellt wurden. Das Highlight war zu sehen, wie das Zühlke-Management mit dieser Krise umging: transparent und fürsorglich.\nIn diesen Jahren schlug ich auch neue soziale Events bei Zühlke vor: ein Snow Event, bei dem die ganze Abteilung in die Berge zum Skifahren ging, und ein Game Event, bei dem wir zusammen Computerspiele spielten. Beides wurde ein grosser Erfolg.\n2004 war die Krise vorbei. Ich wurde zum Advanced Software Engineer befördert und begann mit der Migration der Kraftwerks-Software von C++ nach C#/.NET.\nWachstum in neue Rollen (2005-2009) # 2005 wechselte ich die Branche und kam in den Versicherungsbereich, wo ich WinForms-Applikationen in .NET entwickelte. Da ich unsicher war, ob ich eine rein technische Karriere verfolgen oder in Richtung Management gehen sollte, begann ich ein Executive MBA.\n2007 wurde ich Expert Software Engineer. Mein neues Projekt war am Flughafen, wo wir die neueste Technologie der damaligen Zeit einsetzten: die Windows Presentation Foundation (WPF). Ich führte auch den WPF Architecture Blueprint ein, der heute noch in Legacy-Projekten verwendet wird.\n2008 begann mit einem dreimonatigen Sabbatical durch Australien und Neuseeland mit meiner Frau. Dann kam die Finanzkrise. Wieder einmal bewältigte das Zühlke-Management die Situation beeindruckend.\n2009 wurde ich zum Lead Software Architect befördert. Zusammen mit einem Kollegen gründete ich den .NET Architectural Circle, eine der ersten Communities of Practice bei Zühlke. Er wurde zum Vorbild für alle heutigen Communities of Practice. Dies war auch das Jahr, in dem Bitcoin erfunden wurde und die ersten DevOpsDays in Gent stattfanden, die die weltweite DevOps-Bewegung auslösten.\nVom Architekten zum Partner (2010-2016) # 2010 gründete ich zusammen mit Kollegen die Client Technology Days, eine zweitägige Minikonferenz in der Schweiz mit Fokus auf User Experience, UI-Design und Benutzeroberflächentechnologie. Dieses Event wurde so erfolgreich, dass wir es in den folgenden Jahren mehrfach durchführten. Schliesslich inspirierte es Zühlke zur Gründung der Software Engineering Days, einer globalen Konferenz für alle Software Engineers.\n2013 wurde ich zum Principal Consultant befördert und wechselte in die Bankenbranche. 2014 wurde ich Teamleiter in der neu gegründeten Client Technology Unit.\nDer grösste Meilenstein kam 2016, als ich die Ehre hatte, Partner der Zühlke Gruppe zu werden. Zühlke war zu diesem Zeitpunkt auf 834 Mitarbeitende gewachsen. Ich ging auch auf mein zweites Sabbatical: sechs Monate durch die USA, Kanada, die Osterinseln und Bora Bora.\nDie DevOps-Ära (2017-2022) # Nach meiner Rückkehr vom Sabbatical blieb ich in der Bankenbranche, fokussierte mich aber zunehmend auf DevOps. Ich absolvierte ein Führungstraining in Ashridge in England und half bei der Etablierung mehrerer interner Events: die DevOpsDays bei Zühlke und die Architecture Days bei Zühlke.\n2020 wurde ich zum Distinguished Consultant befördert und konzentrierte mich auf agile Transformationen und DevOps-Transformationen. Trotz der COVID-Krise wuchs Zühlke auf 1'234 Mitarbeitende und bezog ein wunderschönes neues Büro (das wir wegen COVID leider nicht besuchen konnten).\n2021 war ein aussergewöhnliches Jahr. Zusammen mit Kolleginnen und Kollegen etablierten wir Lean Portfolio Management, Participatory Budgeting und gründeten die DevOps Practice bei Zühlke. Das Unternehmen wuchs auf 1'620 Mitarbeitende und eröffnete neue Standorte in Porto und Ho-Chi-Minh-Stadt.\n20 Jahre in Zahlen # Ein Rückblick auf 20 Jahre in Zahlen:\n4'943 Tage oder rund 42'000 Stunden bei Zühlke 160 Schulungen mit rund CHF 100'000 investiert in meine Weiterbildung 34 Zertifikate erworben 19 Camps (wären 20 gewesen ohne COVID) 100+ soziale Events mit Teams 25 Projekte mit 15 Kunden in 8 Branchen 3 Sabbaticals Warum es sich lohnt zu bleiben # Zühlke investiert stark in die Weiterbildung der Mitarbeitenden. Die Camps sind grossartig: Zeit zum Austauschen und gemeinsamen Erkunden neuer Technologien. Neben den Camps gibt es unzählige soziale Events und eine Kultur, die dazu ermutigt, neue Initiativen voranzutreiben. Ob Snow Event, Game Event, Client Technology Days, Lean Portfolio Management oder Participatory Budgeting: Ich hatte immer die Freiheit, Neues vorzuschlagen und umzusetzen.\nAls ich bei Zühlke anfing, traf ich Leute, die bereits 5, 10 oder sogar 20 Jahre dabei waren. Ich war überrascht, dass so viele so lange blieben. Jetzt bin ich selbst einer dieser Leute. Und ich bin mir ziemlich sicher, dass ich noch weitere 20 Jahre bei Zühlke bleiben werde.\n","date":"1. February 2022","externalUrl":null,"permalink":"/de/blogs/was-es-bedeutet-mehr-als-20-jahre-fuer-dieselbe-firma-zu-arbeiten/","section":"Blogs","summary":"Am 1. Februar 2002 begann meine Reise bei Zühlke als Junior Software Engineer. Zwanzig Jahre später bin ich immer noch hier. In diesem Beitrag möchte ich teilen, wie diese 20 Jahre aussahen, was mich motiviert hat und warum ich plane, noch mindestens weitere 20 Jahre zu bleiben.\n","title":"Was es bedeutet, mehr als 20 Jahre für dieselbe Firma zu arbeiten","type":"blogs"},{"content":"On February 1, 2002, I started my journey at Zühlke as a junior software engineer. Twenty years later, I am still here. In this post, I want to share what those 20 years looked like, what kept me going, and why I plan to stay for at least another 20.\nThe Early Years: Starting as a Junior (2002-2004) # After a very hard interview, I got hired at Zühlke and joined the Windows and Embedded Solutions unit, led by Philipp Sutter (who is now chairman of the board at Zühlke). Back then, Zühlke had 219 people with locations in Zürich, Frankfurt, and London.\nMy first project was in the industrial sector, where we built a large C++ application for designing power plants and calculating their efficiency. Right from the start, I received training in .NET, the Rational Unified Process, and design patterns. One of the greatest experiences was the five-day camp, where the whole unit went to a remote location, and we coded and explored new technologies together.\nJust as I started, the dot-com crisis hit. I was one of the last people hired for the next two years. The highlight was seeing how the Zühlke management handled this crisis with transparency and care.\nDuring these years, I also proposed new social events at Zühlke: a Snow Event where the whole unit went skiing in the mountains, and a Game Event where we came together to play computer games. Both became a big success.\nBy 2004, the crisis was over. I got promoted to Advanced Software Engineer and started migrating the power plant software from C++ to C#/.NET.\nGrowing into New Roles (2005-2009) # In 2005, I changed industries and moved into the insurance sector, developing WinForms applications in .NET. Unsure whether to pursue a purely technical career or move into management, I started an Executive MBA.\nIn 2007, I became an Expert Software Engineer. My new project was at the airport, using the newest technology at the time: Windows Presentation Foundation (WPF). I also introduced the WPF Architecture Blueprint, which is still used in legacy projects today.\n2008 began with a three-month sabbatical through Australia and New Zealand with my wife. Then the financial crisis hit. Once again, Zühlke\u0026rsquo;s management handled the situation impressively.\nIn 2009, I was promoted to Lead Software Architect. Together with a colleague, I created the .NET Architectural Circle, one of the first communities of practice at Zühlke. It became the blueprint for all communities of practice that exist today. This was also the year Bitcoin was invented and the first DevOpsDays took place in Ghent, sparking the DevOps movement worldwide.\nFrom Architect to Partner (2010-2016) # In 2010, together with colleagues, I founded the Client Technology Days, a two-day mini-conference in Switzerland focused on user experience, UI design, and user interface technology. This event became so successful that we ran it multiple times over the following years, and it eventually inspired Zühlke to create the Software Engineering Days, a global conference for all software engineers.\nIn 2013, I was promoted to Principal Consultant and moved into the banking industry. In 2014, I became a team lead in the newly founded Client Technology Unit.\nThe biggest milestone came in 2016 when I was honored to become a Partner of the Zühlke Group. Zühlke had grown to 834 people by then. I also went on my second sabbatical, six months through the US, Canada, Easter Island, and Bora Bora.\nThe DevOps Era (2017-2022) # After returning from sabbatical, I stayed in the banking industry but increasingly focused on DevOps. I went through leadership training at Ashridge in England and helped establish several internal events: the DevOpsDays at Zühlke and the Architecture Days at Zühlke.\nIn 2020, I was promoted to Distinguished Consultant and focused on agile transformations and DevOps transformations. Despite the COVID crisis, Zühlke grew to 1,234 people and moved into a beautiful new office (which we could not visit due to COVID).\n2021 was an extraordinary year. Together with colleagues, we established Lean Portfolio Management, Participatory Budgeting, and founded the DevOps Practice at Zühlke. The company grew to 1,620 people and opened new locations in Porto and Ho Chi Minh City.\n20 Years by the Numbers # Looking back at 20 years, here are some numbers:\n4,943 days or about 42,000 hours at Zühlke 160 trainings with roughly CHF 100,000 invested in my education 34 certificates earned 19 camps (would have been 20 without COVID) 100+ social events with teams 25 projects with 15 customers across 8 industries 3 sabbaticals What Makes It Worth Staying # Zühlke invests heavily in the education of their people. The camps are amazing: time to socialize and explore new technologies together. Beyond camps, there are countless social events and a culture that encourages you to drive new initiatives. Whether it was the Snow Event, the Game Event, the Client Technology Days, Lean Portfolio Management, or Participatory Budgeting, I always had the freedom to propose and create new things.\nWhen I first started at Zühlke, I met people who had been with the company for 5, 10, even 20 years. I was surprised so many stayed that long. Now I am one of those people. And I am pretty sure I will stay for 20 more.\n","date":"1 February 2022","externalUrl":null,"permalink":"/en/blogs/what-its-like-to-work-for-the-same-company-for-more-than-20-years/","section":"Blogs","summary":"On February 1, 2002, I started my journey at Zühlke as a junior software engineer. Twenty years later, I am still here. In this post, I want to share what those 20 years looked like, what kept me going, and why I plan to stay for at least another 20.\n","title":"What It's Like to Work for the Same Company for More Than 20 Years","type":"blogs"},{"content":"In diesem Artikel erkläre ich, was Continuous Deployment innerhalb des SAFe® DevOps Health Radars ist und warum es für die schnelle und sichere Wertlieferung unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\nWo Continuous Deployment einzuordnen ist # Continuous Deployment ist die dritte Dimension in der SAFe DevOps Pipeline. Davor kommt Continuous Exploration, wo wir mit Kunden und dem Business zusammenarbeiten, um Hypothesen aufzustellen, Marktbedürfnisse zu verstehen, eine minimale Architektur zu definieren und Epics in Features herunterzubrechen. Danach folgt Continuous Integration, wo diese Features in User Stories zerlegt, implementiert, in die Versionsverwaltung eingecheckt und als verifizierte, deploybare Artefakte in einer Staging-Umgebung bereitgestellt werden.\nMit Continuous Deployment bringen wir diese verifizierten Artefakte kontinuierlich in die Produktion und machen alles bereit für das Release.\nWarum Continuous Deployment wichtig ist # In traditionellen Deployment-Praktiken sind Deployment und Release dasselbe. Teams sammeln alle Features aus ein, zwei oder drei Monaten und deployen und releasen dann alles zusammen. Das birgt ein enormes Risiko, weil die Menge an Änderungen massiv ist.\nContinuous Deployment löst dieses Problem durch kleine Batch-Grössen. Wir deployen kontinuierlich kleine Änderungen in die Produktion, was den Wertfluss massiv erhöht. Das Schlüsselprinzip dabei ist die Trennung von Deployment und Release.\nTrennung von Deployment und Release # Dies ist eines der wichtigsten Konzepte:\nDeployment bedeutet, den kompilierten Code mit ausgeschaltetem Feature Flag in die Produktion zu bringen. Release bedeutet, das Feature Flag einzuschalten, damit die Benutzer auf die neue Funktionalität zugreifen können. Diese Trennung ermöglicht es uns, on Demand zu releasen. Alle Änderungen sind bereits in der Produktion, und das Business entscheidet, wann der richtige Zeitpunkt für das Release einer Funktion ist. Dies hat einen massiven Einfluss auf die Time-to-Market.\nDie vier Aktivitäten von Continuous Deployment # Continuous Deployment besteht aus vier Aktivitäten: Deploy, Verify, Monitor und Respond.\nDeploy # Die erste Aktivität ist das Deployment in die Produktion. Wir bringen den kompilierten Code mit ausgeschaltetem Feature Toggle in die Produktion. Ein Feature Toggle ist im Wesentlichen eine If-Anweisung im Code, mit der wir konfigurieren können, ob ein Feature ein- oder ausgeschaltet ist. Das ermöglicht Dark Launches, bei denen Funktionalität bereits in der Produktion vorhanden ist, ohne für die Benutzer sichtbar zu sein.\nVerify # Sobald unser deploybares Artefakt in die Produktion gebracht wurde, müssen wir überprüfen, ob alles korrekt funktioniert. Dazu führen wir eine Teilmenge der Tests aus, die bereits während der Integrationsphase durchgeführt wurden. Wenn einer dieser Tests fehlschlägt, führen wir sofort ein Rollback auf die letzte stabile Version durch.\nMonitor # Während der Architekturphase haben wir für Betreibbarkeit designt. Alle Log-Einträge und Telemetriedaten, die wir während des Entwicklungszyklus eingebaut haben, fliessen nun in unser Monitoring-System ein. Damit können wir die Anwendungsgesundheit, Systemleistung, das Endbenutzerverhalten, Incidents und den Geschäftswert überwachen.\nRespond # In der Produktion können und werden Dinge schiefgehen. Wenn das passiert, müssen wir schnell reagieren. Wir setzen Alerts und Schwellenwerte auf unser Monitoring-System, damit wir benachrichtigt werden, bevor die Benutzer betroffen sind. Wenn etwas passiert, nutzen wir teamübergreifende Zusammenarbeit, um das Problem zu lösen und die Geschäftskontinuität sicherzustellen.\nWie schnell ist dieser Prozess? # Lassen Sie mich das ganz konkret machen. Ein Feature wird in eine User Story heruntergebrochen. Die User Story wird entwickelt, der Build-Server erstellt ein deploybares Artefakt, und dieses Artefakt wird verifiziert und in eine Staging-Umgebung deployt. Von dort können wir sofort in die Produktion deployen, mit einer Teilmenge der Tests verifizieren, das Monitoring starten und bei Problemen alarmiert werden.\nDieser gesamte Prozess kann innerhalb von Minuten oder Stunden durchgeführt werden. Es gibt absolut keinen Grund, alle Änderungen über Monate hinweg zu sammeln und sie in einem grossen Paket zu deployen.\nDas Ergebnis # Wenn Continuous Deployment gut umgesetzt wird, haben Sie:\nEin stabiles Produktionssystem mit den neuesten Änderungen Ein Monitoring-System, das Features, Performance, Benutzerverhalten, Incidents und Geschäftswert verfolgt Ein Alerting- und Benachrichtigungssystem für schnelle Reaktionen Die Fähigkeit, on Demand zu releasen, wobei das Business die Kontrolle darüber hat, wann Features live gehen Continuous Deployment ermöglicht kleine Batch-Grössen mit hoher Frequenz und geringem Risiko. Durch die Trennung von Deployment und Release entscheidet das Business, wann der richtige Zeitpunkt ist. Das hat einen massiven positiven Einfluss auf die Time-to-Market.\n","date":"23. January 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-continuous-deployment-safe-devops-health-radar/","section":"Blogs","summary":"In diesem Artikel erkläre ich, was Continuous Deployment innerhalb des SAFe® DevOps Health Radars ist und warum es für die schnelle und sichere Wertlieferung unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\n","title":"Was ist Continuous Deployment? | SAFe® DevOps Health Radar","type":"blogs"},{"content":"In this article, I explain what Continuous Deployment is within the SAFe® DevOps Health Radar and why it is essential for delivering value quickly and safely. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out of this toolbox what fits your needs and what solves your problems.\nWhere Continuous Deployment Fits # Continuous Deployment is the third dimension in the SAFe DevOps pipeline. Before it comes Continuous Exploration, where we work with customers and the business to form hypotheses, understand market needs, define a minimal architecture, and break epics into features. After that, Continuous Integration takes those features, breaks them into user stories, implements them, commits code to version control, and produces verified deployable artifacts in a staging environment.\nWith Continuous Deployment, we take these verified artifacts and bring them into production continuously, making everything ready for release.\nWhy Continuous Deployment Matters # In traditional deployment practices, deployment and release are the same thing. Teams stack up all features from one, two, or three months and then deploy and release everything together. This carries enormous risk because of the massive amount of changes involved.\nContinuous Deployment solves this by working with small batch sizes. We continuously deploy small changes into production, which increases the flow of value massively. The key principle here is separating deployment from release.\nSeparating Deployment from Release # This is one of the most important concepts to understand:\nDeployment is bringing the compiled code into production with the feature flag turned off. Release is switching on the feature flag so that users can access the new functionality. This separation enables us to release on demand. All changes are already in production, and the business decides when the time is right to release a feature. This has a massive impact on time to market.\nThe Four Activities of Continuous Deployment # Continuous Deployment consists of four activities: Deploy, Verify, Monitor, and Respond.\nDeploy # The first activity is deploying into production. We bring the compiled code into production with the feature toggle off. A feature toggle is essentially an if-statement in the code that allows us to configure whether a feature is on or off. This enables dark launches, where functionality is already in production without being visible to users.\nVerify # Once our deployable artifact has been deployed to production, we need to verify that everything is working correctly. We do this by executing a subset of the tests that were already run during the integration phase. If any of these tests fail, we perform an immediate rollback to the latest stable version.\nMonitor # During the architecture phase, we designed for operability. All the log statements and telemetry that we built into the system during the development cycle now feed into our monitoring system. This allows us to track application health, system performance, end user behavior, incidents, and business value.\nRespond # Things can and will go wrong in production. When they do, we need to respond quickly. We set alerts and thresholds on top of our monitoring system so that we get notified before users are affected. When something does happen, we use cross-team collaboration to resolve the issue and ensure business continuity.\nHow Fast Is This Process? # Let me make this very concrete. A feature gets broken down into a user story. The user story gets developed, the build server creates a deployable artifact, and that artifact gets verified and deployed to a staging environment. From there, we can immediately deploy into production, verify with a subset of tests, start monitoring, and get alerted if something goes wrong.\nThis whole process can be done within minutes or hours. There is absolutely no need to stack up all changes for months and deploy them in one big chunk.\nThe Result # When Continuous Deployment is done well, you have:\nA stable production system with the latest changes A monitoring system that tracks features, performance, user behavior, incidents, and business value An alerting and notification system for rapid response The ability to release on demand, giving the business control over when features go live Continuous Deployment enables small batch sizes with high frequency and low risk. By separating deployment from release, the business decides when the time is right. This has a massive positive impact on time to market.\n","date":"23 January 2022","externalUrl":null,"permalink":"/en/blogs/what-is-continuous-deployment-safe-devops-health-radar/","section":"Blogs","summary":"In this article, I explain what Continuous Deployment is within the SAFe® DevOps Health Radar and why it is essential for delivering value quickly and safely. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out of this toolbox what fits your needs and what solves your problems.\n","title":"What is Continuous Deployment? | SAFe® DevOps Health Radar","type":"blogs"},{"content":"","date":"9 January 2022","externalUrl":null,"permalink":"/en/tags/incident-management/","section":"Tags","summary":"","title":"Incident Management","type":"tags"},{"content":"","date":"9 January 2022","externalUrl":null,"permalink":"/en/tags/infrastructure-as-code/","section":"Tags","summary":"","title":"Infrastructure as Code","type":"tags"},{"content":"","date":"9 January 2022","externalUrl":null,"permalink":"/en/tags/production-monitoring/","section":"Tags","summary":"","title":"Production Monitoring","type":"tags"},{"content":"","date":"9. January 2022","externalUrl":null,"permalink":"/de/tags/produktions%C3%BCberwachung/","section":"Tags","summary":"","title":"Produktionsüberwachung","type":"tags"},{"content":"Wie erkennt und behebt man proaktiv Produktionsprobleme, bevor sie zu einer Geschäftsunterbrechung führen? Respond ist die Aktivität im SAFe DevOps Health Radar, die genau diese Frage beantwortet. In diesem Video erkläre ich, was Respond umfasst und warum es für die Aufrechterhaltung einer stabilen Produktionsumgebung unverzichtbar ist.\nWo Respond in die Pipeline passt # Der SAFe DevOps Health Radar beginnt beim Kunden. Gute Ideen werden in Hypothesen und Epics umgewandelt. In Collaborate and Research identifizieren wir das echte Kundenbedürfnis. Wir erstellen die minimale Architektur, brechen Epics in Features herunter, entwickeln User Stories, committen Code, bauen deploybare Artefakte, testen End-to-End, deployen in die Staging-Umgebung und dann kontinuierlich in die Produktion. Nach der Verifizierung des Produktions-Deployments und dem Monitoring der Umgebung kommen wir zu Respond.\nIm Respond-Schritt wollen wir proaktiv Produktionsprobleme erkennen und beheben, bevor sie zu einer Geschäftsunterbrechung führen können.\nWarum Respond wichtig ist # Produktionsprobleme passieren. Selbst die grossen Player wie Google, Facebook und Amazon haben Ausfälle. Produktionsprobleme betreffen immer den Kunden und binden Ressourcen. Wenn etwas kaputtgeht, muss das Team Fixes erstellen, Patches bereitstellen, erneut deployen und erneut testen. All das reduziert den Fluss von zukünftigem Mehrwert in die Produktion.\nDeshalb ist die proaktive Reaktion auf Incidents so entscheidend.\nProaktive Erkennung # Im Monitoring-Schritt (früher in dieser Serie behandelt) haben wir Telemetrie- und Logging-Systeme eingerichtet. Weil wir all diese Telemetriedaten zur Verfügung haben, können wir Toleranzschwellenwerte erstellen, die uns bei gefährlichen Zuständen alarmieren.\nEine gute Benachrichtigungsstrategie ist hier unverzichtbar. Wir sollten nicht bei allem alarmieren. Die Schwellenwerte müssen sorgfältig evaluiert werden, damit wir nur bei wirklich gefährlichen Zuständen Benachrichtigungen erzeugen. Andernfalls riskieren wir eine Alert-Müdigkeit, bei der das Team aufhört aufzupassen, weil es zu viele Fehlalarme gibt.\nDisaster Recovery üben # Katastrophen werden in der Produktion immer eintreten. Deshalb müssen wir Disaster-Recovery-Verfahren regelmässig üben. Wenn ein echter Incident eintritt, muss das Team die Verfahren bereits kennen und schnell ausführen können.\nTeamübergreifende Zusammenarbeit # Was wir nicht wollen, ist das Schwarze-Peter-Spiel: Der Kunde ruft den Service Desk an, der Service Desk schickt das Problem zum Entwickler, der Entwickler zeigt auf den Product Owner, der Product Owner schickt es zum Tester, und alle zeigen mit dem Finger aufeinander.\nWas wir stattdessen wollen, ist teamübergreifende Zusammenarbeit. Wenn etwas in der Produktion passiert, arbeiten alle gemeinsam daran, das Problem zu erkennen, zu analysieren und zu lösen. Nach jedem Incident führen wir ein Incident-Post-Mortem-Meeting durch, bei dem alle Beteiligten identifizieren, was verbessert werden kann, damit der Incident entweder nie wieder auftritt oder beim nächsten Mal deutlich schneller gelöst werden kann.\nImmutable Infrastructure # Eine unveränderliche Infrastruktur in der Produktion ist sehr hilfreich. Bei einer unveränderlichen Infrastruktur kann niemand direkte Änderungen an der Produktion vornehmen. Alle Änderungen müssen durch die Continuous-Delivery-Pipeline gehen.\nInfrastructure as Code unterstützt diesen Ansatz, weil die gesamte Umgebungskonfiguration als Konfigurationsdateien in der Versionskontrolle gespeichert wird. Das stellt sicher, dass jede Änderung nachvollziehbar und reproduzierbar ist.\nAlles unter Versionskontrolle # Um effektiv auf Incidents reagieren zu können, muss alles unter Versionskontrolle stehen: der gesamte Code, die gesamte Infrastrukturkonfiguration, alle Tests, alle Testdaten, alle Anforderungen. Nur so können wir Incidents analysieren, sehen was sich geändert hat, wann und warum. Und nur so können wir bei Bedarf schnelle Rollbacks durchführen.\nRollback vs. Fix Forward # Wenn ein Produktionsproblem auftritt, haben wir zwei Hauptstrategien:\nRollback: Die vorherige funktionierende Version aus der Versionskontrolle holen und erneut in der Produktion installieren. Das ist schnell und stellt die Stabilität sofort wieder her. Fix Forward: Das Problem so schnell wie möglich analysieren, einen Fix erstellen und diesen Fix durch die gesamte Continuous-Delivery-Pipeline in die Produktion liefern. Beide Strategien haben ihre Berechtigung, und die richtige Wahl hängt von der Schwere des Problems ab und davon, wie schnell ein Fix entwickelt werden kann.\nSession Recording # Systeme werden immer komplexer, und Nutzer durchlaufen viele verschiedene Workflows. Session Recording ermöglicht es, alles zu speichern, was ein Nutzer tut, damit wir die gesamte Sitzung in einer Test- oder Entwicklungsumgebung abspielen können, um Probleme nachzustellen und zu debuggen.\nBei der Nutzung von Session Recording muss man besonders auf Datensicherheit, Datenschutz und Aufbewahrungsrichtlinien achten, da man eine grosse Menge an Nutzerdaten aufzeichnet.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Respond:\nSit: Kunden finden Probleme vor uns. Die Behebung von hochprioritären Problemen ist zeitaufwändig und reaktiv. Kunden haben wenig Vertrauen in unsere Fähigkeit, uns von Produktionsproblemen zu erholen. Crawl: Der Betrieb ist für Produktionsprobleme verantwortlich. Die Einbindung der Entwicklung erfordert erhebliche Eskalation. Teams beschuldigen sich gegenseitig in Krisenzeiten. Walk: Entwicklung und Betrieb tragen gemeinsam die Verantwortung für den Incident-Resolution-Prozess. Die Wiederherstellung nach grösseren Incidents ist reaktiv, aber eine Teamleistung. Run: Unsere Monitoring-Systeme erkennen die meisten Probleme, bevor unsere Kunden sie bemerken. Dev und Ops arbeiten proaktiv zusammen, um sich von grösseren Incidents zu erholen. Fly: Unsere Monitoring-Systeme warnen uns vor gefährlichen Zuständen auf Basis sorgfältig definierter Toleranzschwellenwerte. Entwickler sind verantwortlich für den Support ihres eigenen Codes und liefern proaktiv Fixes durch die Pipeline, bevor Nutzer betroffen sind. Was Respond produziert # Das Ergebnis des Respond-Schritts ist:\nEine stabile Produktionsumgebung, die Geschäftskontinuität sicherstellt Ein Benachrichtigungs- und Alarmsystem auf Basis sorgfältig evaluierter Schwellenwerte, das das Team bei gefährlichen Zuständen warnt Die Fähigkeit zum Release on Demand, was im nächsten Video dieser Serie behandelt wird Wichtige Erkenntnisse # Produktionsprobleme sind unvermeidlich. Selbst die grössten Unternehmen haben Ausfälle. Bereiten Sie sich darauf vor. Proaktive Erkennung einrichten. Nutzen Sie Telemetriedaten und sorgfältig definierte Schwellenwerte, um bei gefährlichen Zuständen zu warnen, nicht bei allem. Disaster Recovery üben. Warten Sie nicht auf einen echten Incident, um Ihre Wiederherstellungsverfahren zu testen. Teamübergreifend zusammenarbeiten. Ersetzen Sie das Schwarze-Peter-Spiel durch teamübergreifende Incident-Behebung und Post-Mortem-Meetings. Unveränderliche Infrastruktur nutzen. Alle Änderungen sollten durch die Continuous-Delivery-Pipeline gehen, niemals direkt in der Produktion. Alles in der Versionskontrolle halten. Code, Konfiguration, Tests und Anforderungen müssen alle versioniert sein, um schnelle Analyse und Rollbacks zu ermöglichen. ","date":"9. January 2022","externalUrl":null,"permalink":"/de/blogs/was-ist-respond-safe-devops-health-radar/","section":"Blogs","summary":"Wie erkennt und behebt man proaktiv Produktionsprobleme, bevor sie zu einer Geschäftsunterbrechung führen? Respond ist die Aktivität im SAFe DevOps Health Radar, die genau diese Frage beantwortet. In diesem Video erkläre ich, was Respond umfasst und warum es für die Aufrechterhaltung einer stabilen Produktionsumgebung unverzichtbar ist.\n","title":"Was ist Respond? | SAFe DevOps Health Radar","type":"blogs"},{"content":"How do you proactively detect and fix production issues before they cause a business disruption? Respond is the SAFe DevOps Health Radar activity that answers exactly this question. In this video, I walk through what Respond involves and why it is essential for maintaining a stable production environment.\nWhere Respond Fits in the Pipeline # The SAFe DevOps Health Radar starts with the customer. Bright ideas are turned into hypothesis statements and epics. In Collaborate and Research we identify the real customer need. We create the minimal architecture needed, break epics into features, develop user stories, commit code, build deployable artifacts, test end-to-end, deploy to staging, and then deploy continuously to production. After verifying the production deployment and monitoring the environment, we arrive at Respond.\nIn the Respond step, we want to proactively detect and resolve production issues before they can cause any business disruption.\nWhy Respond Matters # Production issues happen. Even the big players like Google, Facebook, and Amazon experience outages. Production problems always affect the customer, and they bind resources. When something breaks, your team has to create fixes, patches, redeploy, and retest. All of that reduces the flow of future value into production.\nThat is why proactively responding to incidents is critical.\nProactive Detection # In the Monitoring step (covered earlier in this series), we set up telemetry and logging systems. Because we have all of this telemetry data in place, we can create tolerance thresholds that alert us to dangerous conditions.\nA good notification strategy is essential here. We should not alert for everything. The thresholds must be carefully evaluated so that we create notifications only for truly dangerous conditions. Otherwise, we risk alert fatigue, where the team stops paying attention because there are too many false alarms.\nDisaster Recovery Rehearsal # Disaster will always strike in production. That is why we need to rehearse disaster recovery procedures on a regular basis. When a real incident occurs, the team must already know the procedures and be able to execute them quickly.\nCross-Team Collaboration # What we do not want is the blame game: the customer calls the service desk, the service desk sends the issue to the developer, the developer points to the product owner, the product owner sends it to the tester, and everyone is finger-pointing.\nWhat we want instead is cross-team collaboration. When something happens in production, everybody works together to detect, analyze, and resolve the issue. After each incident, we conduct an incident post-mortem meeting where everyone involved identifies what can be improved so the incident either never recurs or can be resolved much faster next time.\nImmutable Infrastructure # Having an immutable infrastructure in production is very helpful. In an immutable infrastructure, no one can make direct changes to production. All changes must go through the continuous delivery pipeline.\nInfrastructure as Code supports this approach because all environment configuration is stored in version control as configuration files. This ensures that every change is traceable and reproducible.\nEverything Under Version Control # To respond effectively to incidents, everything must be under version control: all code, all infrastructure configuration, all tests, all test data, all requirements. Only then can we analyze incidents, see what changed, when, and why. And only then can we make fast rollbacks when needed.\nRollback vs. Fix Forward # When a production issue occurs, we have two main strategies:\nRollback: Get the previous working version from source control and install it again in production. This is fast and restores stability immediately. Fix Forward: Analyze the problem as fast as possible, create a fix, and deliver that fix through the full continuous delivery pipeline into production. Both strategies have their place, and the right choice depends on the severity of the issue and how quickly a fix can be developed.\nSession Recording # Systems are getting more and more complex, and users go through many different workflows. Session recording allows us to store everything a user does, so we can replay the entire session in a test or development environment to reproduce and debug issues.\nWhen using session recording, you must pay close attention to data security, privacy, and retention policies, as you are recording a lot of user data.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for Respond:\nSit: Customers find issues before we do. Resolving high priority issues is time-consuming and reactive. Customers have low confidence in our ability to recover from production issues. Crawl: Operations owns production issues. Development involvement requires significant escalation. Teams blame each other in times of crisis. Walk: Development and Operations collectively own the incident resolution process. Recovering from major incidents is reactive but a team effort. Run: Our monitoring systems detect most issues before our customers do. Dev and Ops work proactively to recover from major incidents. Fly: Our monitoring systems alert us to dangerous conditions based on carefully designed tolerance thresholds. Developers are responsible for supporting their own code and proactively issue fixes through the pipeline before users are affected. What Respond Produces # The output of the Respond step is:\nA stable production environment that ensures business continuity A notification and alerting system based on carefully evaluated thresholds that alerts the team to dangerous conditions The ability to release on demand, which is covered in the next video in this series Key Takeaways # Production issues are inevitable. Even the biggest companies experience outages. Prepare for it. Set up proactive detection. Use telemetry data and carefully designed thresholds to alert on dangerous conditions, not on everything. Rehearse disaster recovery. Do not wait for a real incident to test your recovery procedures. Collaborate across teams. Replace the blame game with cross-team incident resolution and post-mortem meetings. Use immutable infrastructure. All changes should go through the continuous delivery pipeline, never directly in production. Keep everything in version control. Code, configuration, tests, and requirements must all be versioned to enable fast analysis and rollbacks. ","date":"9 January 2022","externalUrl":null,"permalink":"/en/blogs/what-is-respond-safe-devops-health-radar/","section":"Blogs","summary":"How do you proactively detect and fix production issues before they cause a business disruption? Respond is the SAFe DevOps Health Radar activity that answers exactly this question. In this video, I walk through what Respond involves and why it is essential for maintaining a stable production environment.\n","title":"What is Respond? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Value stream mapping is a lean management method for improving the flow of value from idea to production. It offers insight into the efficiency of an organisation and can help to identify bottlenecks and improve value flow. The primary goal is to eliminate any waste.\nBut how does this kind of process work? In our guide, we will show you how to get it going in seven steps.\nDownload the complete guide here\nValue stream mapping is an outstanding technique for gaining a clear view of the value creation in a company, project or product and a tool for ongoing improvement: evolution rather than revolution.\nFor proper value stream mapping, you will need to put aside about one working day. Using the list of measures, you can start working on improvements to achieve your desired value stream.\nSeven steps to value stream mapping # Identifying the process steps Finding the right people Focused measures Data analysis Creating a new target value stream map Defining specific measures Repeat You can find details and examples on how to execute these process steps in our guide.\nOriginal Post: Zühlke | Medium\n","date":"7 January 2022","externalUrl":null,"permalink":"/en/blogs/devops-how-can-we-improve-value-streams/","section":"Blogs","summary":"Value stream mapping is a lean management method for improving the flow of value from idea to production. It offers insight into the efficiency of an organisation and can help to identify bottlenecks and improve value flow. The primary goal is to eliminate any waste.\n","title":"DevOps: How can we improve value streams?","type":"blogs"},{"content":"Value Stream Mapping ist eine Lean-Management-Methode, um den Wertfluss von der Idee bis zur Produktion zu verbessern. Sie bietet Einblick in die Effizienz einer Organisation und kann helfen, Engpässe zu identifizieren und den Wertfluss zu verbessern. Das primäre Ziel besteht darin, jegliche Verschwendung zu eliminieren.\nAber wie funktioniert ein solcher Prozess? In unserem Leitfaden zeigen wir Ihnen, wie Sie ihn in sieben Schritten in Gang bringen.\nDen vollständigen Leitfaden hier herunterladen\nValue Stream Mapping ist eine hervorragende Technik, um einen klaren Blick auf die Wertschöpfung in einem Unternehmen, Projekt oder Produkt zu erhalten – und ein Werkzeug für kontinuierliche Verbesserung: Evolution statt Revolution.\nFür ein ordentliches Value Stream Mapping sollten Sie etwa einen Arbeitstag einplanen. Mit der Liste der Massnahmen können Sie beginnen, an Verbesserungen zu arbeiten, um Ihren gewünschten Wertstrom zu erreichen.\nSieben Schritte zum Value Stream Mapping # Identifizieren der Prozessschritte Die richtigen Personen finden Fokussierte Massnahmen Datenanalyse Erstellen einer neuen Soll-Wertstromkarte Definieren konkreter Massnahmen Wiederholen Details und Beispiele zur Durchführung dieser Prozessschritte finden Sie in unserem Leitfaden.\nOriginalbeitrag: Zühlke | Medium\n","date":"7. January 2022","externalUrl":null,"permalink":"/de/blogs/devops-wie-koennen-wir-wertstroeme-verbessern/","section":"Blogs","summary":"Value Stream Mapping ist eine Lean-Management-Methode, um den Wertfluss von der Idee bis zur Produktion zu verbessern. Sie bietet Einblick in die Effizienz einer Organisation und kann helfen, Engpässe zu identifizieren und den Wertfluss zu verbessern. Das primäre Ziel besteht darin, jegliche Verschwendung zu eliminieren.\n","title":"DevOps: Wie können wir Wertströme verbessern?","type":"blogs"},{"content":"","date":"7 January 2022","externalUrl":null,"permalink":"/en/tags/efficiency/","section":"Tags","summary":"","title":"Efficiency","type":"tags"},{"content":"","date":"7. January 2022","externalUrl":null,"permalink":"/de/tags/effizienz/","section":"Tags","summary":"","title":"Effizienz","type":"tags"},{"content":"","date":"7 January 2022","externalUrl":null,"permalink":"/en/tags/lean-management/","section":"Tags","summary":"","title":"Lean Management","type":"tags"},{"content":"","date":"7. January 2022","externalUrl":null,"permalink":"/de/tags/optimierung/","section":"Tags","summary":"","title":"Optimierung","type":"tags"},{"content":"","date":"7 January 2022","externalUrl":null,"permalink":"/en/tags/optimization/","section":"Tags","summary":"","title":"Optimization","type":"tags"},{"content":"","date":"7 January 2022","externalUrl":null,"permalink":"/en/tags/process-improvement/","section":"Tags","summary":"","title":"Process Improvement","type":"tags"},{"content":"","date":"7. January 2022","externalUrl":null,"permalink":"/de/tags/prozessverbesserung/","section":"Tags","summary":"","title":"Prozessverbesserung","type":"tags"},{"content":"","date":"7. January 2022","externalUrl":null,"permalink":"/de/tags/verschwendungsreduktion/","section":"Tags","summary":"","title":"Verschwendungsreduktion","type":"tags"},{"content":"","date":"7 January 2022","externalUrl":null,"permalink":"/en/tags/waste-reduction/","section":"Tags","summary":"","title":"Waste Reduction","type":"tags"},{"content":"","date":"3 January 2022","externalUrl":null,"permalink":"/en/tags/2022/","section":"Tags","summary":"","title":"2022","type":"tags"},{"content":"","date":"3 January 2022","externalUrl":null,"permalink":"/en/tags/finops/","section":"Tags","summary":"","title":"FinOps","type":"tags"},{"content":"","date":"3 January 2022","externalUrl":null,"permalink":"/en/tags/gitops/","section":"Tags","summary":"","title":"GitOps","type":"tags"},{"content":"","date":"3 January 2022","externalUrl":null,"permalink":"/en/tags/observability/","section":"Tags","summary":"","title":"Observability","type":"tags"},{"content":"A year ago I called DevSecOps, continuous delivery, cloud and AIOps as the trends for 2021. Most of those landed. For 2022 the picture gets more interesting because DevOps is no longer a single wave — different parts of the market are at very different stages of adoption. To make sense of that, I map the 2022 trends onto the technology adoption lifecycle: late majority, early majority and early adopters.\nQuick Review of 2021 # Before looking forward, a quick look back. DevOps adoption did accelerate, security genuinely started shifting left, continuous delivery pipelines matured, cloud became the default, and AIOps stayed early but real. None of those trends are finished. They just move into different segments of the adoption curve in 2022.\nThe Technology Adoption Lifecycle # Geoffrey Moore\u0026rsquo;s adoption lifecycle — innovators, early adopters, early majority, late majority, laggards — is the right lens for DevOps trends in 2022. The same trend means very different things depending on where your organisation sits on that curve. A late-majority enterprise still rolling out CI is in a different conversation from an early adopter wiring up AIOps.\nLate Majority: Continuing DevOps Adoption # The late majority is finally getting serious about the foundations. In 2022 that means continuous integration done properly, monitoring and logging across distributed systems, infrastructure as code, containerization, orchestration with Kubernetes, and cloud as the default deployment target. None of this is new. What is new is that organisations that resisted for years are now executing on it because they can no longer compete without it.\nEarly Majority: DevSecOps, Observability, GitOps, FinOps, Continuous Testing # The early majority is where most of the interesting movement happens in 2022.\nDevSecOps is huge, driven by the growing volume and severity of cyber-attacks. Security tools wired into the pipeline, security owned by the product team, and security gates that do not block delivery.\nObservability moves beyond traditional monitoring. Metrics, logs and traces combined to answer questions you did not know you would have to ask. The shift is from \u0026ldquo;is the system up?\u0026rdquo; to \u0026ldquo;why did this user request behave the way it did?\u0026rdquo;\nGitOps uses Git as the single source of truth for infrastructure and deployment state. It pairs naturally with Kubernetes and gives you auditable, reversible operations.\nEnterprise continuous delivery pipelines scale CD beyond a single team to portfolios and product groups. Standardisation, golden paths, and platform teams that own the pipeline as a product.\nFinOps brings financial accountability to cloud spend. As cloud becomes the default, the bill becomes the conversation. FinOps is the practice that keeps it honest.\nContinuous testing moves test automation from a CI checkbox to a strategic capability. Shift-left testing, contract testing, performance and resilience testing as part of the pipeline.\nEarly Adopters: AIOps # AIOps is where the early adopters are investing in 2022. The promise is leverage: machine learning helping operations teams find anomalies, correlate alerts, and automate incident response. The reality is still messy — data quality, model drift, and tool sprawl. But the leaders are no longer asking whether AIOps is real; they are asking how to roll it out.\nKey Takeaways # Map trends onto the adoption lifecycle. The right trend depends on where your organisation actually is. Do not chase early-adopter trends if your foundations are not in place.\nLate majority: nail the basics. CI, monitoring, IaC, containers, cloud. Boring, foundational, and still where most of the value sits if you have not done it.\nEarly majority: this is where 2022 is happening. DevSecOps, observability, GitOps, enterprise CD, FinOps and continuous testing are the active edge for most enterprises.\nFinOps is the new conversation. Cloud bills are the new ops cost. Without financial accountability, cloud spend gets out of hand fast.\nObservability is more than monitoring. Build for the questions you have not asked yet.\nAIOps is for early adopters. The leverage is real, but so are the data and tooling problems. Pilot before you scale.\n","date":"3 January 2022","externalUrl":null,"permalink":"/en/blogs/top-devops-trends-2022/","section":"Blogs","summary":"A year ago I called DevSecOps, continuous delivery, cloud and AIOps as the trends for 2021. Most of those landed. For 2022 the picture gets more interesting because DevOps is no longer a single wave — different parts of the market are at very different stages of adoption. To make sense of that, I map the 2022 trends onto the technology adoption lifecycle: late majority, early majority and early adopters.\n","title":"What Are the Top DevOps Trends in 2022?","type":"blogs"},{"content":"","date":"14 December 2021","externalUrl":null,"permalink":"/en/tags/monitoring/","section":"Tags","summary":"","title":"Monitoring","type":"tags"},{"content":"","date":"14. December 2021","externalUrl":null,"permalink":"/de/tags/telemetrie/","section":"Tags","summary":"","title":"Telemetrie","type":"tags"},{"content":"","date":"14 December 2021","externalUrl":null,"permalink":"/en/tags/telemetry/","section":"Tags","summary":"","title":"Telemetry","type":"tags"},{"content":"Sobald unsere Features in der Produktion deployed und verifiziert sind, müssen wir genau beobachten, wie sie sich verhalten. Monitor ist die Aktivität im SAFe DevOps Health Radar, die sich darauf konzentriert, Systemleistung, Endnutzerverhalten, Incidents und den Geschäftswert zu verfolgen. In diesem Video erkläre ich, was Monitoring umfasst und warum es für die richtigen Entscheidungen über unsere Features unverzichtbar ist.\nWo Monitor in die Pipeline passt # Der SAFe DevOps Health Radar beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren eine Hypothese, erstellen ein Epic, forschen gemeinsam nach dem echten Kundenbedürfnis, entwerfen die minimale Architektur und brechen das Epic in Features herunter. Wir entwickeln User Stories, committen Code, bauen deploybare Pakete, testen sie, deployen in die Staging-Umgebung und dann in die Produktionsumgebung. Nachdem wir verifiziert haben, dass alles in der Produktion funktioniert, müssen wir überwachen, was dort passiert.\nWarum wir überwachen # Monitoring in der Produktion bedeutet, dass wir Features verfolgen können, um die Systemleistung zu verstehen, Incidents zu identifizieren, das Endnutzerverhalten zu beobachten und den gelieferten Geschäftswert zu messen. Wir überwachen, weil wir sicherstellen wollen, dass die Produktion so reibungslos wie möglich läuft. Aber es geht um mehr: Wir wollen auch die Geschäftshypothese validieren. Im Hypothesis-Schritt haben wir definiert, welchen Geschäftswert wir erwarten. Im Monitor-Schritt messen wir, ob wir diesen Wert tatsächlich liefern.\nFull-Stack-Telemetrie # Für effektives Monitoring nutzen wir Full-Stack-Telemetrie. Im Architect-Schritt dieser Serie haben wir die Architektur für Betriebsfähigkeit entworfen und entschieden, welche Daten geloggt werden müssen. Im Develop-Schritt haben wir das gesamte Logging implementiert. Im Monitor-Schritt sammeln wir diese Log-Einträge und speisen sie in ein Telemetriesystem ein, damit wir sie durchsuchen und analysieren können.\nEs ist wichtig, verschiedene Arten von Daten zu loggen:\nApplikationsdaten, um technische Probleme und Fehler nachzuverfolgen Geschäftsdaten, um zu validieren, ob die Geschäftshypothese zutrifft Dashboards und visuelle Darstellungen # Rohe Telemetriedaten sind schwer zu lesen. Deshalb nutzen wir Dashboards, um alles zu visualisieren. Diese visuellen Darstellungen machen es einfach, die Informationen auf einen Blick zu interpretieren.\nIn diesen Dashboards können wir zeigen:\nDevOps-Metriken wie letztes Deployment, letzter Ausfall und durchschnittliche Lead Time Endnutzerverhalten, um zu verstehen, wie Features genutzt werden Geschäftswert-Trends, um zu verfolgen, ob wir liefern, was wir versprochen haben Es ist wichtig, dass die gesamte Organisation Zugang zu diesen Dashboards hat, nicht nur das Entwicklungsteam. Transparenz über die gesamte Organisation hinweg ermöglicht bessere Entscheidungen.\nFederated Monitoring # Eine einzelne Applikation isoliert zu überwachen reicht nicht aus. Applikationen haben Abhängigkeiten zu anderen Applikationen und zur darunterliegenden Infrastruktur. Wir müssen alle Telemetriedaten in einer Federated-Monitoring-Plattform konsolidieren, die eine ganzheitliche Sicht bietet.\nNur mit Federated Monitoring können wir Leistungsprobleme und Incidents über Applikationen und Infrastruktur hinweg nachverfolgen. Diese konsolidierte Sicht ist entscheidend, um das Gesamtbild zu verstehen.\nAIOps: Künstliche Intelligenz für den IT-Betrieb # Wenn wir mehrere Applikationen und die Infrastruktur überwachen, wird die Menge an Datenpunkten, Events und Alerts überwältigend. Wir stehen vor einem Big-Data-Problem.\nAIOps hilft, indem es:\nDaten aggregiert aus allen Quellen Events korreliert über die gesamte Applikationslandschaft Muster analysiert, um aussagekräftige Erkenntnisse zu gewinnen Ursachen vorhersagt, damit wir Probleme schneller beheben können Anomalien erkennt, bevor sie zu Incidents werden AIOps-Tools visualisieren alle Abhängigkeiten in der Applikationslandschaft und ermöglichen es, Probleme durch die gesamte Kette zu verfolgen.\nWas Monitoring liefert # Wenn wir effektiv überwachen, gewinnen wir mehrere Fähigkeiten:\nFeature-Tracking: Wir können sehen, ob Features genutzt werden und wie Endnutzer mit ihnen interagieren Systemleistung: Wir beobachten, wie das System in der Produktion performt, einschliesslich API-Antwortzeiten und Ressourcenverbrauch Incident-Prävention und -Analyse: Monitoring hilft uns, Incidents zu verhindern und sie zu analysieren, wenn sie auftreten Messung des Geschäftswerts: Wir können messen, ob die Hypothese vom Anfang der Pipeline zutrifft, und dem Business ermöglichen zu entscheiden, ob mehr in ein Feature investiert, es beibehalten oder entfernt werden soll Die Reifegrade # Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Monitor:\nSit: Kein Feature-Level-Monitoring in der Produktion vorhanden. Nur Infrastruktur-Monitoring ist implementiert. Crawl: Features loggen nur Fehler und Exceptions. Die Analyse von Events erfordert das manuelle Korrelieren von Logs aus mehreren Systemen. Walk: Features loggen Fehler, Benutzeraktivitäten und andere Events. Daten werden manuell analysiert, um Incidents zu untersuchen und den Geschäftswert von Features zu messen. Run: Full-Stack-Monitoring ist implementiert. Events können über die gesamte Architektur korreliert werden. Daten werden über systemspezifische Dashboards dargestellt. Fly: Eine Federated-Monitoring-Plattform bietet zentralen Zugang zu Full-Stack-Einblicken. Daten werden genutzt, um Systemleistung und Geschäftswert zu bewerten. Den Feedback-Loop schliessen # Der wichtigste Aspekt des Monitorings ist, dass es den Feedback-Loop schliesst. Im Hypothesis-Schritt haben wir den Geschäftswert definiert, den wir schaffen wollen. Indem wir diesen Geschäftswert in der Produktion verfolgen, ermöglichen wir dem Business, die richtigen Entscheidungen zu treffen: Sollen wir mehr in dieses Feature investieren oder weniger? Sollen wir dieses Feature für alle Nutzer aktivieren oder es komplett deaktivieren?\nMonitoring ist das entscheidende Element, das es uns ermöglicht, das Richtige richtig zu bauen.\nWichtige Erkenntnisse # Full-Stack-Telemetrie nutzen. Sowohl Applikationsdaten als auch Geschäftsdaten loggen, um ein vollständiges Bild zu erhalten. Mit Dashboards visualisieren. Monitoring-Daten für die gesamte Organisation zugänglich und leicht interpretierbar machen. Federated Monitoring implementieren. Die Sicht auf eine einzelne Applikation reicht nicht aus. Man braucht den Überblick über alle Applikationen und die Infrastruktur. AIOps einsetzen. Wenn das Datenvolumen die menschliche Kapazität übersteigt, KI nutzen, um zu aggregieren, zu korrelieren und Anomalien zu erkennen. Geschäftswert messen. Monitoring dreht sich nicht nur um Verfügbarkeit. Es geht darum zu validieren, ob die Geschäftshypothese zutrifft. Den Feedback-Loop schliessen. Monitoring-Erkenntnisse nutzen, um fundierte Entscheidungen zu treffen, welche Features beibehalten, verbessert oder entfernt werden sollen. ","date":"14. December 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-monitor-safe-devops-health-radar/","section":"Blogs","summary":"Sobald unsere Features in der Produktion deployed und verifiziert sind, müssen wir genau beobachten, wie sie sich verhalten. Monitor ist die Aktivität im SAFe DevOps Health Radar, die sich darauf konzentriert, Systemleistung, Endnutzerverhalten, Incidents und den Geschäftswert zu verfolgen. In diesem Video erkläre ich, was Monitoring umfasst und warum es für die richtigen Entscheidungen über unsere Features unverzichtbar ist.\n","title":"Was ist Monitor? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Once our features are deployed and verified in production, we need to keep a close eye on how they perform. Monitor is the SAFe DevOps Health Radar activity that focuses on tracking system performance, end-user behavior, incidents, and business value. In this video, I walk through what monitoring involves and why it is essential for making the right decisions about your features.\nWhere Monitor Fits in the Pipeline # The SAFe DevOps Health Radar starts with bright ideas from the customer or business. We extract a hypothesis, create an epic, collaborate and research to identify the real customer need, architect the minimal amount of architecture needed, and break the epic into features. We develop user stories, commit code, build deployable packages, test them, deploy to staging, and then deploy to the production environment. After verifying that everything is working in production, we need to monitor what is happening.\nWhy We Monitor # Monitoring production means we can track features to understand system performance, identify incidents, observe end-user behavior, and measure the business value we deliver. We monitor because we want to ensure production runs as smoothly as possible. But there is more: we also want to validate the business hypothesis. Back in the hypothesis step, we defined what business value we expect. In the monitor step, we measure whether we actually deliver that value.\nFull-Stack Telemetry # To monitor effectively, we use full-stack telemetry. If you recall the architect step from this series, that is where we architect for operability. We decide what data needs to be logged. In the develop step, we implement all the logging. In the monitor step, we collect those log statements and feed them into a telemetry system so we can browse and analyze them.\nIt is important to log different types of data:\nApplication data to track down technical issues and errors Business data to validate whether the business hypothesis holds true Dashboards and Visual Displays # Raw telemetry data is hard to read. That is why we use dashboards to visualize everything. These visual displays make it easy to interpret the information at a glance.\nIn these dashboards we can show:\nDevOps metrics such as last deployment, last outage, and average lead time End-user behavior to understand how features are being used Business value trends to track whether we deliver what we promised It is important that the entire organization has access to these dashboards, not just the development team. Visibility across the organization enables better decisions.\nFederated Monitoring # Monitoring a single application in isolation is not enough. Applications have dependencies on other applications and on the underlying infrastructure. We need to consolidate all telemetry data into a federated monitoring platform that provides a holistic view.\nOnly with federated monitoring can we track down performance problems and issues across applications and across the infrastructure. This consolidated view is critical for understanding the full picture.\nAIOps: Artificial Intelligence for IT Operations # When we monitor multiple applications and infrastructure, the volume of data points, events, and alerts becomes overwhelming. We face a big data problem.\nAIOps helps by:\nAggregating data from all sources Correlating events across the entire application landscape Analyzing patterns to surface meaningful insights Predicting root causes so we can fix issues faster Detecting anomalies before they become incidents AIOps tools visualize all dependencies in your application landscape and let you trace issues through the entire chain.\nWhat Monitoring Produces # When we monitor effectively, we gain several capabilities:\nFeature tracking: We can see if features are used and how end users interact with them System performance: We observe how the system performs in production, including API response times and resource consumption Incident prevention and analysis: Monitoring helps us prevent incidents and analyze them when they occur Business value measurement: We can measure whether the hypothesis from the beginning of the pipeline holds true, enabling the business to decide whether to invest more in a feature, keep it, or remove it The Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for Monitor:\nSit: No feature-level production monitoring exists. Only infrastructure monitoring is in place. Crawl: Features only log faults and exceptions. Analyzing events involves manually correlating logs from multiple systems. Walk: Features log faults, user activity, and other events. Data is analyzed manually to investigate incidents and measure business value of features. Run: Full-stack monitoring is in place. Events can be correlated throughout the architecture. Data is presented through system-specific dashboards. Fly: Federated monitoring platform provides one-stop access to full-stack insights. Data is used to gauge system performance and business value. Closing the Feedback Loop # The most important aspect of monitoring is that it closes the feedback loop. Back in the hypothesis step, we defined the business value we wanted to create. By tracking this business value in production, we enable the business to make the right decisions: Should we invest more into this feature or less? Should we enable this feature for all users or disable it entirely?\nMonitoring is the crucial piece that allows us to build the right thing right.\nKey Takeaways # Use full-stack telemetry. Log both application data and business data to get a complete picture. Visualize with dashboards. Make monitoring data accessible and easy to interpret for the entire organization. Implement federated monitoring. A single application view is not enough. You need to see across all applications and infrastructure. Leverage AIOps. When data volume exceeds human capacity, use AI to aggregate, correlate, and detect anomalies. Measure business value. Monitoring is not just about uptime. It is about validating whether the business hypothesis is true. Close the feedback loop. Use monitoring insights to make informed decisions about which features to keep, improve, or remove. ","date":"14 December 2021","externalUrl":null,"permalink":"/en/blogs/what-is-monitor-safe-devops-health-radar/","section":"Blogs","summary":"Once our features are deployed and verified in production, we need to keep a close eye on how they perform. Monitor is the SAFe DevOps Health Radar activity that focuses on tracking system performance, end-user behavior, incidents, and business value. In this video, I walk through what monitoring involves and why it is essential for making the right decisions about your features.\n","title":"What is Monitor? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"12 December 2021","externalUrl":null,"permalink":"/en/tags/agile-framework/","section":"Tags","summary":"","title":"Agile Framework","type":"tags"},{"content":"","date":"12. December 2021","externalUrl":null,"permalink":"/de/tags/agiles-framework/","section":"Tags","summary":"","title":"Agiles Framework","type":"tags"},{"content":"","date":"12. December 2021","externalUrl":null,"permalink":"/de/tags/analytik/","section":"Tags","summary":"","title":"Analytik","type":"tags"},{"content":"","date":"12. December 2021","externalUrl":null,"permalink":"/de/tags/bewertung/","section":"Tags","summary":"","title":"Bewertung","type":"tags"},{"content":"","date":"12 December 2021","externalUrl":null,"permalink":"/en/tags/evaluation/","section":"Tags","summary":"","title":"Evaluation","type":"tags"},{"content":"","date":"12 December 2021","externalUrl":null,"permalink":"/en/tags/measurement/","section":"Tags","summary":"","title":"Measurement","type":"tags"},{"content":"","date":"12. December 2021","externalUrl":null,"permalink":"/de/tags/messung/","section":"Tags","summary":"","title":"Messung","type":"tags"},{"content":" In diesem Artikel erfahren Sie, was genau der SAFe® DevOps Health Radar ist und wofür Sie ihn einsetzen können.\nDer DevOps Health Radar ist ein Assessment, um Ihren aktuellen Stand zu bewerten und herauszufinden, wo Sie sich momentan in Bezug auf DevOps befinden. Er besteht aus vier Dimensionen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Jede dieser Dimensionen umfasst wiederum vier Aktivitäten. Bei Continuous Exploration sind das beispielsweise Hypothesize, Collaborate, Research \u0026amp; Architect und Synthesize.\nDer DevOps Health Radar wird als Assessment-Framework verwendet, mit dem Sie sich in jeder dieser Aktivitäten selbst bewerten können. Es gibt fünf Stufen, und das Scaled Agile Framework stellt ein Excel zur Verfügung, in das Sie die Werte eingeben und daraus ein Spinnendiagramm berechnen können.\nWenn ich den DevOps Health Radar ausfülle, füge ich normalerweise eine weitere Spalte hinzu. Der aktuelle Zustand zeigt, wo wir im Moment stehen, aber die neue Spalte sollte auch enthalten, wo wir in Zukunft sein wollen. In vielen Fällen ist es nicht notwendig, bei jeder Aktivität eine Fünf zu erreichen. Drei oder zwei ist völlig akzeptabel.\nDies ist ein perfektes Instrument, um herauszufinden, wo Sie gerade stehen und wo Ihre grössten Lücken sind. Es hilft Ihnen bei der DevOps-Transformation und bei der Visualisierung des aktuellen und zukünftigen Zustands.\nAssessment herunterladen\nOriginalbeitrag: Medium\n","date":"12. December 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-der-safe-devops-health-radar/","section":"Blogs","summary":" In diesem Artikel erfahren Sie, was genau der SAFe® DevOps Health Radar ist und wofür Sie ihn einsetzen können.\nDer DevOps Health Radar ist ein Assessment, um Ihren aktuellen Stand zu bewerten und herauszufinden, wo Sie sich momentan in Bezug auf DevOps befinden. Er besteht aus vier Dimensionen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Jede dieser Dimensionen umfasst wiederum vier Aktivitäten. Bei Continuous Exploration sind das beispielsweise Hypothesize, Collaborate, Research \u0026 Architect und Synthesize.\n","title":"Was ist der SAFe® DevOps Health Radar","type":"blogs"},{"content":" In this article, we will explore what exactly SAFe® DevOps is for health radar and what can you use it for.\nThe DevOps health radar is an assessment to assess your current state and where you are at the moment in regards to DevOps. Consisting of four dimensions: continuous exploration, continuous integration, continuous deployment, and release on demand. Furthermore, each of these dimensions encompasses four activities. For example, in continuous exploration this is hypothesize, collaborate, research architect, and synthesize.\nThe DevOps health radar is used as an assessment framework with that you can assess yourself in each of these or each of these activities. We have five levels in there and the Scaled Agile framework provides you with an excel where you can input the values and calculate out of that the spider diagram.\nWhen I fill out DevOps health radar, I usually add another column. The current state is where we are at the moment, but your new column should also consist of where you will be in the future. In many cases, it is not necessary that you need to reach a five in every one of these activities. Three or two is completely acceptable.\nThis is a perfect instrument to identify where you are at the moment and where your biggest gaps are. It will help you with DevOps transformation and for visualization of current and future state.\nDownload the assessment\nOriginal Post: Medium\n","date":"12 December 2021","externalUrl":null,"permalink":"/en/blogs/what-is-the-safe-devops-health-radar/","section":"Blogs","summary":" In this article, we will explore what exactly SAFe® DevOps is for health radar and what can you use it for.\n","title":"What is the SAFe® DevOps Health Radar","type":"blogs"},{"content":"","date":"6 December 2021","externalUrl":null,"permalink":"/en/tags/production-testing/","section":"Tags","summary":"","title":"Production Testing","type":"tags"},{"content":"Verify ist ein entscheidender Schritt im SAFe for DevOps Health Radar. Nachdem wir unser Paket in die Produktionsumgebung deployed haben, müssen wir sicherstellen, dass die neue Funktionalität korrekt funktioniert und die Integrität und Robustheit des bestehenden Systems nicht beeinträchtigt. Erst nach dieser Verifikation können wir die neuen Features bedenkenlos für die Endbenutzer freigeben. In diesem Video erkläre ich, was der Verify-Schritt umfasst und wie er sich in die gesamte Continuous Delivery Pipeline einfügt.\nWo Verify in der Pipeline steht # Bevor wir den Verify-Schritt erreichen, haben wir Continuous Exploration und Continuous Integration durchlaufen. Wir haben gute Ideen vom Kunden und Business in Hypothesenaussagen umgewandelt, gemeinsam geforscht, die Lösung architekturiert und Epics in Features und User Stories heruntergebrochen. Der Code wurde gebaut, getestet und in ein deploybare Artefakt verpackt. Dieses Artefakt wurde zuerst in eine Staging-Umgebung und dann in die Produktionsumgebung deployed.\nJetzt, da der Code in der Produktion mit dem Feature Toggle ausgeschaltet liegt, ist es an der Zeit zu verifizieren, dass alles wie erwartet funktioniert, bevor wir den Feature Toggle einschalten und die Funktionalität für die Nutzer freigeben.\nTrennung von Deployment und Release # Einer der Grundpfeiler von DevOps ist die Trennung von Deployment und Release. Deployment ist das Einbringen des kompilierten Codes in die Produktion mit dem Feature Toggle ausgeschaltet. Release ist das Einschalten des Feature Toggles, damit die neue Funktionalität von den Endbenutzern genutzt werden kann.\nDiese Trennung macht den Verify-Schritt erst möglich. Da der Code in der Produktion liegt, aber noch nicht für die Nutzer sichtbar ist, haben wir die Möglichkeit, ihn gründlich in der echten Produktionsumgebung zu testen, ohne ein Risiko für die Endbenutzer einzugehen.\nProduction Testing # Die Kernaktivität im Verify-Schritt ist das Production Testing. Wir führen Tests, die wir bereits in niedrigeren Umgebungen ausgeführt haben, erneut in der Produktionsumgebung aus. Dies geschieht durch die Simulation von Endbenutzerverhalten mit synthetischen Transaktionen. Diese synthetischen Transaktionen ermöglichen es uns, zwei Dinge zu verifizieren:\nDie bestehende Funktionalität verhält sich weiterhin wie erwartet. Die neue Funktionalität tut, was sie soll, und ist bereit für das Release. Dieser Ansatz gibt uns die Sicherheit, dass das Deployment keine Regressionen verursacht hat und die neuen Features in der echten Produktionsumgebung korrekt funktionieren.\nBuild-, Test- und Deployment-Automatisierung # Um das neue Paket in der Produktion zu verifizieren, benötigen wir eine solide Build-, Test- und Deployment-Automatisierung. Mit dieser Automatisierung können wir bei jedem Commit einen Build auslösen, alle Unit Tests ausführen, Codeanalyse und Security-Checks durchführen und das Paket automatisch in Staging- und Produktionsumgebungen deployen.\nWichtig ist hier die schnelle Feedback-Schleife. Entwickler müssen schnell erfahren, ob ihre Änderungen alle Verifikationsprüfungen bestehen. Je schneller dieses Feedback, desto schneller können Probleme behoben werden.\nTestdatenmanagement # Gutes Testdatenmanagement ist entscheidend für den Verify-Schritt. Wir benötigen einen gut gepflegten Satz synthetischer Testdaten, damit wir unsere Tests zuverlässig ausführen können. Diese Testdaten müssen in der Versionskontrolle gespeichert sein.\nWas wir nicht tun wollen, ist Produktionsdaten oder eine anonymisierte Produktionsdatenbank für Tests zu verwenden. Produktionsdaten ändern sich ständig, und diese Änderungen führen zu flaky Tests. Ein flaky Test hat null Wert, weil er das Vertrauen in die Testsuite untergräbt und es unmöglich macht, echte Fehler von Rauschen zu unterscheiden.\nNicht-funktionale Anforderungen # Bei der Verifikation der Funktionalität in der Produktion müssen wir auch die nicht-funktionalen Anforderungen verifizieren. Das sind Systemeigenschaften wie Sicherheit, Zuverlässigkeit, Performance, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Nicht-funktionale Anforderungen sind eine Randbedingung für das gesamte Backlog. Das bedeutet, dass jede User Story, jedes Feature und jedes Epic diesen Anforderungen entsprechen muss.\nWir verifizieren die nicht-funktionalen Anforderungen zuerst in der Staging-Umgebung, müssen aber auch bestätigen, dass sie in der Produktionsumgebung erfüllt werden. Die Produktionsumgebung kann andere Eigenschaften als Staging aufweisen, weshalb diese Verifikation unerlässlich ist.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Verify-Schritt:\nSit: Deployments werden in der Produktion nicht verifiziert, bevor sie für Endbenutzer freigegeben werden. Crawl: Deployments werden mit manuellen Smoke Tests und User Acceptance Testing (UAT) verifiziert. Deployment-Probleme werden innerhalb eines definierten Triage-Zeitraums behandelt. Probleme werden häufig direkt in der Produktion behoben. Walk: Deployments werden vor der Freigabe für Endbenutzer mit manuellen Tests verifiziert. Rollbacks sind schmerzhaft oder unmöglich. Änderungen werden nicht direkt in der Produktion vorgenommen. Run: Deployments werden mit automatisierten Production Tests verifiziert. Rollbacks sind schmerzhaft oder unmöglich. Änderungen werden nicht direkt in der Produktion vorgenommen. Fly: Automatisierte Production Tests laufen kontinuierlich und speisen Monitoring-Systeme. Fehlgeschlagene Deployments können sofort zurückgerollt oder durch die gesamte Pipeline vorwärts behoben werden. Kernaussagen # Vor dem Release verifizieren. Nach dem Deployment in die Produktion die neue und bestehende Funktionalität testen, bevor der Feature Toggle für Endbenutzer eingeschaltet wird. Synthetische Transaktionen verwenden. Endbenutzerverhalten in der Produktion simulieren, um zu bestätigen, dass alles wie erwartet funktioniert, ohne echte Nutzer zu beeinflussen. Gute Testdaten pflegen. Synthetische Testdaten in der Versionskontrolle verwenden. Niemals auf Produktionsdaten für Tests zurückgreifen, da sie zu flaky Tests führen. Nicht-funktionale Anforderungen verifizieren. Sicherheit, Performance, Zuverlässigkeit und andere Systemeigenschaften müssen in der Produktionsumgebung geprüft werden, nicht nur im Staging. Die Verifikation automatisieren. Build-, Test- und Deployment-Automatisierung ist essenziell für schnelles Feedback und zuverlässige Production-Verifikation. Deployment von Release trennen. Diese Trennung ist die Grundvoraussetzung für eine sichere Verifikation in der Produktion. ","date":"6. December 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-verify-safe-devops-health-radar/","section":"Blogs","summary":"Verify ist ein entscheidender Schritt im SAFe for DevOps Health Radar. Nachdem wir unser Paket in die Produktionsumgebung deployed haben, müssen wir sicherstellen, dass die neue Funktionalität korrekt funktioniert und die Integrität und Robustheit des bestehenden Systems nicht beeinträchtigt. Erst nach dieser Verifikation können wir die neuen Features bedenkenlos für die Endbenutzer freigeben. In diesem Video erkläre ich, was der Verify-Schritt umfasst und wie er sich in die gesamte Continuous Delivery Pipeline einfügt.\n","title":"Was ist Verify? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Verify is a critical step in the SAFe for DevOps Health Radar. After deploying our package into the production environment, we need to confirm that the new functionality works correctly and does not negatively affect the integrity or robustness of the existing system. Only after this verification is complete can we confidently release the new features to end-users. In this video, I walk through what the Verify step involves and how it fits into the overall continuous delivery pipeline.\nWhere Verify Fits in the Pipeline # Before reaching the Verify step, we have gone through continuous exploration and continuous integration. We transformed bright ideas from the customer and the business into hypothesis statements, collaborated on research, architected the solution, and broke down epics into features and user stories. The code was built, tested, and packaged into a deployable artifact. This artifact was deployed first to a staging environment and then to the production environment.\nNow that the code is deployed to production with the feature toggle off, it is time to verify that everything works as expected before we switch the feature toggle on and release it to users.\nSeparating Deployment from Release # One of the cornerstones of DevOps is separating deployment from release. Deployment is the act of bringing the compiled code into production with the feature toggle turned off. Release is the act of switching the feature toggle on so that the new functionality can be used by the end-users.\nThis separation is what makes the Verify step possible. Because the code is in production but not yet visible to users, we have the opportunity to test it thoroughly in the real production environment without any risk to end-users.\nProduction Testing # The core activity in the Verify step is production testing. We execute tests that we have already run in lower stages again in the production environment. We do this by simulating end-user behavior with synthetic transactions. These synthetic transactions allow us to verify two things:\nThe existing functionality still behaves as expected. The new functionality does what it should do and is ready to be released. This approach gives us confidence that the deployment has not introduced any regressions and that the new features are working correctly in the real production environment.\nBuild, Test, and Deployment Automation # To verify the new package in production, we need solid build, test, and deployment automation. With this automation in place, we can trigger a build on every commit, execute all unit tests, run code analysis and security checks, and automatically deploy the package into staging and production environments.\nWhat is important here is the fast feedback loop. Developers need to know quickly whether their changes pass all verification checks. The faster this feedback, the faster issues can be resolved.\nTest Data Management # Proper test data management is crucial for the Verify step. We need a well-maintained set of synthetic test data so that we can execute our tests reliably. This test data must be stored in version control.\nWhat we do not want to do is use production data or an anonymized production database for testing. Production data changes constantly, and those changes lead to flaky tests. A flaky test has zero value because it erodes confidence in the test suite and makes it impossible to distinguish real failures from noise.\nNon-Functional Requirements # When verifying functionality in production, we also need to verify non-functional requirements. These are system attributes like security, reliability, performance, maintainability, scalability, and usability. Non-functional requirements are a constraint on the entire backlog, which means that every user story, every feature, and every epic must comply with them.\nWe verify non-functional requirements first in the staging environment, but we also need to confirm that they are met in the production environment. The production environment may have different characteristics than staging, so this verification is essential.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Verify step:\nSit: Deployments are not verified in production before being released to end-users. Crawl: Deployments are verified with manual smoke tests and user acceptance testing (UAT). Deployment issues are addressed within a stated triage warranty period. Issues are often corrected directly in production. Walk: Deployments are verified with manual tests prior to releasing to end-users. Rolling back is painful or impossible. No changes are made directly in production. Run: Deployments are verified with automated production tests. Rolling back is painful or impossible. No changes are made directly in production. Fly: Automated production tests run on an ongoing basis and feed monitoring systems. Failed deployments can be rolled back instantly or fixed forward through the entire pipeline. Key Takeaways # Verify before releasing. After deploying to production, test the new functionality and existing functionality before switching the feature toggle on for end-users. Use synthetic transactions. Simulate end-user behavior in production to confirm that everything works as expected without affecting real users. Maintain good test data. Use synthetic test data stored in version control. Never rely on production data for testing because it leads to flaky tests. Verify non-functional requirements. Security, performance, reliability, and other system attributes must be checked in the production environment, not just in staging. Automate the verification. Build, test, and deployment automation is essential for fast feedback and reliable production verification. Separate deployment from release. This separation is what makes safe production verification possible in the first place. ","date":"6 December 2021","externalUrl":null,"permalink":"/en/blogs/what-is-verify-safe-devops-health-radar/","section":"Blogs","summary":"Verify is a critical step in the SAFe for DevOps Health Radar. After deploying our package into the production environment, we need to confirm that the new functionality works correctly and does not negatively affect the integrity or robustness of the existing system. Only after this verification is complete can we confidently release the new features to end-users. In this video, I walk through what the Verify step involves and how it fits into the overall continuous delivery pipeline.\n","title":"What is Verify? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Many organizations still rely on annual planning cycles with large upfront budgets, waterfall-style gate reviews, and business cases that are written solely to secure funding. The result is often a massive overload of initiatives, poor quality, delayed projects, and a fundamental disconnect between output and actual business impact. In this talk, my colleague and I share how we introduced Lean Portfolio Management at Zühlke Engineering, what we achieved in our first MVP after six months, and where we plan to go next.\nWhy Lean Portfolio Management? # When we look at traditional enterprise planning, we see a familiar pattern: planning for an entire year starts in summer, departments request 25% more budget than they need (because they know it will be cut), and organizations pile on more features than their capacity can handle. This leads to massive quality problems, project delays, and longer delivery cycles.\nOn top of that, traditional gate reviews with milestones are supposed to reduce risk. In practice, they often increase project duration and risk, because teams end up telling each other what they want to hear rather than what is actually happening. The classic \u0026ldquo;watermelon\u0026rdquo; problem: green on the outside, red on the inside.\nThe deeper issue is a focus on output instead of impact. Too often, organizations measure how many tasks were completed or how many features were delivered. What really matters is whether user behavior actually changed, whether real value was created. Lean Portfolio Management addresses exactly this problem.\nSAFe Portfolio Level: Where We Operate # In the SAFe framework, Lean Portfolio Management sits at the top layer, the portfolio level. Below it are the Large Solution and Essential levels, but for this talk we focus exclusively on the portfolio layer.\nA SAFe portfolio consists of one or more value streams. Each value stream has a pipeline with steps, and at the end it delivers value, typically in the form of products or solutions that reach customers. A large enterprise may have multiple SAFe portfolios, while a smaller company may have just one. At Zühlke, we identified multiple portfolios, but in this talk we concentrate on one specific portfolio that handles strategic change initiatives at the group level.\nPortfolio Kanban: Making the Flow Visible # The portfolio Kanban board is the central tool for managing the flow of strategic initiatives. Every large initiative (or \u0026ldquo;epic\u0026rdquo; in SAFe terminology) enters the board through a funnel. Here is how the flow works:\nFunnel: All ideas are collected here. Behind each idea there is always a hypothesis. For example, if the idea is \u0026ldquo;we want to sell cat food,\u0026rdquo; the hypothesis might be \u0026ldquo;we will increase revenue by 10% if we sell cat food.\u0026rdquo; This hypothesis statement defines the target customer, the proposed solution, and the expected business outcome.\nAnalyzing: In this stage, we write a lean business case. Not a 50-page document, but two pages that define the scope (what is in scope, what is out of scope), the MVP, the full solution, and a rough cost estimate using T-shirt sizing.\nBacklog: Analyzed epics are prioritized using WSJF (Weighted Shortest Job First), an economic prioritization method.\nImplementing: When a value stream has capacity, it pulls an epic into implementation. Here we apply the lean startup cycle: build the MVP, validate the hypothesis. If the hypothesis is validated, we continue building. If it is falsified, we either pivot (adjust the hypothesis and try again) or stop entirely. This is the core principle: quick feedback loops and evidence-based decisions rather than sunk-cost thinking.\nThe WIP limits on each column ensure that the organization does not take on more work than it can handle.\nZühlke\u0026rsquo;s Context # Zühlke is an innovation service provider helping customers across Europe and Asia drive innovation, especially where technology is involved. Founded in 1968, the company is partner-owned and has around 1,300 employees across offices in Switzerland, Germany, the UK, Austria, Eastern Europe, and Asia (Singapore, Hong Kong, Ho Chi Minh City).\nThis international, multi-country setup makes coordinating strategic initiatives a real challenge, which is precisely why a structured portfolio management approach was needed.\nWhat We Set Out to Achieve # Our MVP goals for Lean Portfolio Management were straightforward:\nBetter decisions: Enable the group executive to make more informed decisions about which initiatives to start, continue, or stop. Lean approach: Run strategic change initiatives in a lean way, with hypothesis validation and fast feedback. Transparency: Gain a clear overview of all running initiatives across the group. Even though Zühlke is not a huge corporation, it is large enough that the full picture of strategic initiatives was not always visible. Strategic alignment: Ensure that the initiatives we pursue actually support the company\u0026rsquo;s strategy. State of the art: Use an industry-standard approach, which led us to SAFe\u0026rsquo;s Lean Portfolio Management. We also chose SAFe because Zühlke offers SAFe consulting to clients. By implementing it internally, we could learn from our own experience and apply those learnings in customer projects.\nOur Extension: Goals alongside Initiatives # One interesting extension we made to the standard SAFe portfolio Kanban was adding goals, not just strategic initiatives, to the board. For example, we introduced \u0026ldquo;sustainability\u0026rdquo; as a goal for 2022. This goal entered the Kanban board and eventually became both a goal to track and a concrete initiative to pursue.\nThis dual nature, goals and initiatives on the same board, gave the portfolio team the ability to support both goal-setting and initiative tracking in a unified way.\nTracking with OKRs # For tracking both goals and strategic initiatives, we used OKRs (Objectives and Key Results). This was not new to Zühlke, as OKRs were already in use across the organization. But we extended their application to the portfolio level.\nThe structure looks like this:\nVision at the top 5-year strategic goals formulated as OKRs Annual goals for the group, also as OKRs Strategic initiatives (shown linked to the goals they support) This created full traceability from individual initiatives all the way up to the company vision. The group executive and even the board of directors found this view valuable, because it made the strategic alignment (or lack thereof) immediately visible.\nThe Portfolio Roadmap # Within six months, we built a portfolio roadmap that showed all strategic initiatives with their timelines. Each initiative had:\nA clearly formulated hypothesis A lean business case (for the larger initiatives) Leading indicators (not lagging indicators like \u0026ldquo;ROI in five years,\u0026rdquo; but near-term measures like \u0026ldquo;within one month we have gained X customers\u0026rdquo;) A monthly status update The roadmap was stored in Confluence, accessible to every employee. Dark green indicated running initiatives, light green indicated initiatives scheduled to start in the coming year. This gave the entire organization, from the group executive to individual contributors, a clear picture of the strategic change portfolio.\nWhat the Group Executive Said # After six months, we asked the group executive for feedback. The key themes:\nWhat worked well:\nTransparency was the most cited benefit. Seeing all initiatives with their hypotheses, lean business cases, and status in one place was considered very valuable. Cross-group visibility enabled better decision-making about new initiatives. Goal integration through OKRs was seen as highly useful. The portfolio team essentially became a support function for the group executive\u0026rsquo;s annual strategic goal-setting process. Traceability from initiatives to 1-year and 5-year strategic goals was appreciated. What needed improvement:\nSome initiatives needed more rigorous lean execution. Not all initiatives were truly running with hypothesis validation and pivot-or-persevere decisions. Development value streams were not yet established, which limited the ability to pull work from the backlog in a truly demand-driven way and to implement value-stream-based funding. Highlights and Lowlights # Highlight: Strategic Goals. I cannot stress this enough. If you want to implement Lean Portfolio Management, make sure the strategic goals at the top level of your organization are clearly defined. Without them, the portfolio lacks its North Star. At Zühlke, having well-articulated 5-year goals was one of the biggest enablers for the entire initiative.\nLowlight: Missing Development Value Streams. Without clearly identified development value streams, several SAFe portfolio practices could not be fully implemented, including demand-driven backlog pulling, value-stream-based funding, and a complete WIP view. This was our most significant gap.\nPositive Surprise: Goal Integration. Combining goal tracking (OKRs) with initiative management in a single portfolio view was not part of the original SAFe playbook, but it turned out to be one of the most valuable additions.\nWhat Comes Next # After the first six months, our roadmap for the next phase included:\nMore rigorous lean execution: Enforce hypothesis validation at regular intervals (monthly or quarterly). When results do not match expectations, pivot or stop the initiative, even at the group level. This requires discipline, because large strategic initiatives tend to develop momentum that makes them hard to stop.\nEstablish development value streams: This is the key structural change needed to unlock the full potential of Lean Portfolio Management. With identified value streams, we can implement pull-based work allocation, value-stream funding, and much better WIP visibility.\nContinue the feedback loop: Apply the same lean principles to the portfolio management process itself. Learn from each cycle and improve.\nKey Takeaways # Lean Portfolio Management is not just a framework exercise. It is a fundamental shift from annual, output-focused planning to continuous, impact-focused portfolio steering. Here is what I recommend based on our experience:\nStart with transparency. Just making all strategic initiatives visible in one place already creates enormous value. Define your strategic goals first. Without a clear North Star, portfolio management has no anchor. Use hypotheses and lean business cases, not traditional business cases written to secure budgets. Focus on leading indicators, not lagging ones. You need to know within weeks or months whether an initiative is on track, not after years. Limit WIP aggressively. Organizations almost always have more initiatives running than they can handle. The portfolio Kanban makes this visible. Be willing to stop. The hardest part of lean portfolio management is actually stopping initiatives that are not delivering value. This requires organizational courage. Adapt the framework to your context. We used SAFe as a toolbox and took what fit our situation. Do the same for your organization. ","date":"30 November 2021","externalUrl":null,"permalink":"/en/blogs/lean-portfolio-management-zuehlke-kanban-okrs/","section":"Blogs","summary":"Many organizations still rely on annual planning cycles with large upfront budgets, waterfall-style gate reviews, and business cases that are written solely to secure funding. The result is often a massive overload of initiatives, poor quality, delayed projects, and a fundamental disconnect between output and actual business impact. In this talk, my colleague and I share how we introduced Lean Portfolio Management at Zühlke Engineering, what we achieved in our first MVP after six months, and where we plan to go next.\n","title":"How Zühlke Implemented Lean Portfolio Management with Kanban and OKRs","type":"blogs"},{"content":"","date":"30 November 2021","externalUrl":null,"permalink":"/en/tags/kanban/","section":"Tags","summary":"","title":"Kanban","type":"tags"},{"content":"How can strategy be translated into execution in a transparent, lean, and scalable way?\nWhat This Talk Covers # In this session, we share how Zühlke introduced Lean Portfolio Management (LPM) based on SAFe and adapted it to the organizational context. We show how we built an MVP for LPM by combining a portfolio kanban, transparent epic and roadmap management, and group-wide OKRs to improve strategic alignment and decision-making.\nKey Messages # 1. From Strategy to Execution Lean Portfolio Management provides a transparent, lean, and scalable way to translate strategy into execution using portfolio kanban and OKRs.\n2. Building an MVP for LPM The talk covers the initial challenges, the setup implemented, and feedback from group executives. Starting with an MVP allowed rapid learning and adaptation.\n3. Learnings and Next Steps Key learnings from the MVP and the next steps toward a more mature lean portfolio model. Practical insights for organizations looking to adopt a similar approach.\n","date":"29 November 2021","externalUrl":null,"permalink":"/en/speaking/lean-portfolio-management-with-kanban-and-okrs/","section":"Speaking","summary":"How can strategy be translated into execution in a transparent, lean, and scalable way?\nWhat This Talk Covers # In this session, we share how Zühlke introduced Lean Portfolio Management (LPM) based on SAFe and adapted it to the organizational context. We show how we built an MVP for LPM by combining a portfolio kanban, transparent epic and roadmap management, and group-wide OKRs to improve strategic alignment and decision-making.\n","title":"How Zühlke Implemented Lean Portfolio Management with Kanban and OKRs","type":"speaking"},{"content":"","date":"22. November 2021","externalUrl":null,"permalink":"/de/tags/berufliche-entwicklung/","section":"Tags","summary":"","title":"Berufliche Entwicklung","type":"tags"},{"content":"Ist DevOps wirklich der Grund dafür, dass Testing- und Quality-Assurance-Mitarbeitende (QA) zunehmend durch Automatisierung ihren Job verlieren? Pia Wiedermayer, Head of QA, und Romano Roth, Head of DevOps, diskutieren verschiedene Wege, den reichen Erfahrungsschatz von Testing- und QA-Spezialisten in die agile Teamkultur einzubringen.\nZusammenfassung # DevOps wird oft mit Automatisierung gleichgesetzt Was bedeutet das für Personen in diesen Rollen und mit diesen Verantwortlichkeiten? Tester bringen einen reichen Erfahrungsschatz mit, der in die agile Teamkultur eingebracht werden kann Softwaretesting und Qualitätssicherung verändern sich. Themen wie Agilität, DevOps und Automatisierung beeinflussen bestehende Rollen und Verantwortungsbereiche in der Softwarequalitätssicherung sowie im gesamten Softwarelebenszyklus stark. Standardmässige Testing- und QA-Rollen existieren in vielen (Projekt-)Organisationen nicht mehr. Dedizierte Testteams gehören zunehmend der Vergangenheit an.\nWas bedeutet das für Personen in diesen Rollen und mit diesen Verantwortlichkeiten? Gibt es keinen Platz mehr für sie? Werden ihre Fähigkeiten und Expertise nicht mehr gebraucht?\nDevOps wird oft mit Automatisierung gleichgesetzt. Ist DevOps dafür verantwortlich, Mitarbeitende durch Automatisierung überflüssig zu machen? Was steckt hinter dem Hype, und wer oder was ist DevOps eigentlich?\nPia Wiedermayer, Head of Quality Assurance, und Romano Roth, Head of DevOps, bei Zühlke Schweiz gehen diesen Fragen nach. Sie sprechen über die Herausforderungen in ihren Projekten, untersuchen Rollen und Aufgaben und zeigen neue Wege für die berufliche und persönliche Entwicklung auf. Sie diskutieren auch Möglichkeiten, den reichen Erfahrungsschatz von Testern in die agile Teamkultur einzubringen, und ob Automatisierung das neue Testen ist.\nOriginalbeitrag: Zühlke | Medium\n","date":"22. November 2021","externalUrl":null,"permalink":"/de/blogs/hey-devops-du-vernichtest-meinen-job/","section":"Blogs","summary":"Ist DevOps wirklich der Grund dafür, dass Testing- und Quality-Assurance-Mitarbeitende (QA) zunehmend durch Automatisierung ihren Job verlieren? Pia Wiedermayer, Head of QA, und Romano Roth, Head of DevOps, diskutieren verschiedene Wege, den reichen Erfahrungsschatz von Testing- und QA-Spezialisten in die agile Teamkultur einzubringen.\n","title":"Hey DevOps, du vernichtest meinen Job!","type":"blogs"},{"content":"Is DevOps really the reason why testing and quality assurance (QA) employees are being increasingly automated out of a job? Pia Wiedermayer, Head of QA, and Romano Roth, Head of DevOps, discuss different ways to incorporate the wealth of experience of testing and QA specialists into the agile team culture.\nInsight in brief # DevOps is often equated with automation What does this mean for people in these roles and with these responsibilities? Testers offer a wealth of experience that can be incorporated into the agile team culture Software testing and quality assurance are changing. Topics such as agility, DevOps and automation strongly influence existing roles and areas of responsibility in software quality assurance as well as during the entire software life cycle. Standard testing and QA roles no longer exist in many (project) organisations. Dedicated testing teams are increasingly a thing of the past.\nWhat does this mean for people in these roles and with these responsibilities? Is there no room for them anymore? Are their skills and expertise no longer needed?\nDevOps is often equated with automation. Is DevOps responsible for automating employees out of a job? What is behind the hype and who or what is DevOps actually?\nPia Wiedermayer, Head of Quality Assurance, and Romano Roth, Head of DevOps, at Zühlke Switzerland tackle these questions. They talk about the challenges in their projects, examine roles and tasks and reveal new paths for professional and personal development. They also discuss ways to incorporate the wealth of experience of testers into the agile team culture and whether automation is the new testing.\nOriginal Post: Zühlke | Medium\n","date":"22 November 2021","externalUrl":null,"permalink":"/en/blogs/hey-devops-you-re-killing-my-job/","section":"Blogs","summary":"Is DevOps really the reason why testing and quality assurance (QA) employees are being increasingly automated out of a job? Pia Wiedermayer, Head of QA, and Romano Roth, Head of DevOps, discuss different ways to incorporate the wealth of experience of testing and QA specialists into the agile team culture.\n","title":"Hey DevOps, you're killing my job!","type":"blogs"},{"content":"","date":"22. November 2021","externalUrl":null,"permalink":"/de/tags/kompetenzentwicklung/","section":"Tags","summary":"","title":"Kompetenzentwicklung","type":"tags"},{"content":"","date":"22 November 2021","externalUrl":null,"permalink":"/en/tags/qa/","section":"Tags","summary":"","title":"QA","type":"tags"},{"content":"","date":"22 November 2021","externalUrl":null,"permalink":"/en/tags/skills-development/","section":"Tags","summary":"","title":"Skills Development","type":"tags"},{"content":"","date":"22 November 2021","externalUrl":null,"permalink":"/en/tags/team-roles/","section":"Tags","summary":"","title":"Team Roles","type":"tags"},{"content":"","date":"22. November 2021","externalUrl":null,"permalink":"/de/tags/teamrollen/","section":"Tags","summary":"","title":"Teamrollen","type":"tags"},{"content":"","date":"21 November 2021","externalUrl":null,"permalink":"/en/tags/blue-green-deployment/","section":"Tags","summary":"","title":"Blue-Green Deployment","type":"tags"},{"content":"Deploy ist ein kritischer Schritt im SAFe for DevOps Health Radar. Nachdem wir ein deploybare Paket erstellt und es in einer Staging-Umgebung getestet haben, wollen wir nun unsere Änderungen kontinuierlich in die Produktionsumgebung deployen. Das Ziel ist es, mit hoher Frequenz und niedrigem Risiko zu deployen. In diesem Video erkläre ich, wie wir das erreichen und welche Praktiken Continuous Deployment ermöglichen.\nDie bisherige Reise # Bevor wir den Deploy-Schritt erreichen, haben wir bereits mehrere Schritte im SAFe DevOps Health Radar durchlaufen. Alles begann mit einer Hypothese, in der wir gute Ideen in Epic-Form erfasst haben. Dann haben wir kollaboriert und recherchiert, um Kunden- und Marktbedürfnisse zu verstehen. Im Architect-Schritt haben wir die minimale Architektur entworfen, um unsere Hypothese zu beweisen. Wir haben synthetisiert, indem wir das Epic in Features für das Program Backlog heruntergebrochen haben. Im Develop-Schritt haben wir das Feature durch Aufteilen in User Stories codiert. Wir haben den Code committet und ein deploybare Paket gebaut. Danach haben wir das Paket in eine Staging-Umgebung für End-to-End-Tests deployed.\nJetzt, im Deploy-Schritt, bringen wir unsere Änderungen in die Produktionsumgebung.\nWarum Continuous Deployment? # Der Grund, warum wir unsere Änderungen kontinuierlich in die Produktion deployen wollen, ist einfach: Kleine Änderungen bergen ein geringeres Risiko als grosse Änderungen. Wenn wir kleine Änderungen häufig deployen, hat jedes Deployment eine geringere Wahrscheinlichkeit zu scheitern. Wenn sich hingegen Änderungen über drei Monate ansammeln, wird das Deployment viel grösser und das Risiko steigt erheblich.\nContinuous Deployment bedeutet: Mit hoher Frequenz und niedrigem Risiko in das Produktionssystem deployen.\nDeployment von Release trennen # Um kontinuierlich in die Produktion deployen zu können, müssen wir Deployment von Release trennen. Ein Deployment bringt den kompilierten Code in die Produktion mit dem Feature Switch ausgeschaltet. Ein Release schaltet den Feature Switch in der Produktionsumgebung ein.\nDiese Unterscheidung ist grundlegend. Wir haben dieses Konzept bereits im Architect-Schritt besprochen, denn es ist wichtig, Systeme von Anfang an so zu architekturieren, dass Deployment und Release getrennt werden können.\nFeature Toggles # Feature Toggles (auch Feature Switches genannt) ermöglichen es uns, Features ein- und auszuschalten. Im Kern ist ein Feature Toggle nichts anderes als eine If-Anweisung. Wenn das Flag gesetzt ist, ist das neue Verhalten aktiv. Wenn das Flag nicht gesetzt ist, bleibt das alte Verhalten bestehen.\nEs gibt wichtige Regeln beim Umgang mit Feature Toggles:\nJeder Toggle erzeugt einen Testfall. Mehrere Feature Toggles erzeugen eine kombinatorische Explosion von Szenarien, die getestet werden müssen. Toggles nach dem Release entfernen. Ein Feature Toggle ist temporär. Sobald das Feature released und stabil ist, muss der Toggle aus dem Code entfernt werden. Toggles nicht mit Applikationskonfiguration verwechseln. Applikationskonfiguration ist langlebig und ermöglicht die Konfiguration des Applikationsverhaltens. Ein Feature Toggle ist kurzlebig und existiert nur, um Continuous Deployment zu ermöglichen. Dark Launches # Die Trennung von Deployment und Release sowie der Einsatz von Feature Toggles ermöglichen Dark Launches. Bei einem Dark Launch deployen wir neuen Code in die Produktion mit dem Feature Toggle ausgeschaltet. Das erlaubt uns, Monitoring und Alerting in der Produktionsumgebung zu testen. Wir können beobachten, wie sich der neu deployed Code mit echten Produktionsdaten verhält, ganz ohne Auswirkungen auf die Endbenutzer.\nVersionskontrolle für alles # Wenn wir kontinuierlich in die Produktion deployen wollen, müssen wir alles in der Versionskontrolle haben. Nicht nur den Code, sondern auch die Infrastrukturkonfiguration, Testdaten, Anforderungen und Architekturdokumentation. Alles in der Versionskontrolle zu haben ermöglicht schnelle Rollbacks und eine rasche Untersuchung von Produktionsproblemen, da wir genau wissen, was deployed wurde und was sich gegenüber der vorherigen Version geändert hat.\nInfrastructure as Code # Infrastructure as Code ermöglicht ein automatisiertes Umgebungs-Setup. Wir definieren, wie unsere Infrastruktur aussehen soll, in Konfigurationsdateien, und diese Konfigurationsdateien werden in der Versionskontrolle gespeichert. Mit Tools wie Chef, Puppet und anderen können wir unsere Infrastruktur automatisch provisionieren und konfigurieren. Dieser Ansatz spart Kosten, erhöht die Geschwindigkeit und senkt das Risiko, da das Infrastruktur-Setup jedes Mal konsistent und wiederholbar ist.\nDeployment-Automatisierung # Um kontinuierlich in die Produktion zu deployen, müssen wir alle Schritte automatisieren, die nötig sind, um kompilierten Code in die Produktion zu bringen. Das ist die Deployment-Automatisierung. Es ist wichtig, dass Entwickler immer Feedback erhalten, ob ein Deployment erfolgreich war oder fehlgeschlagen ist.\nWenn vollständige Automatisierung nicht erlaubt ist (zum Beispiel in regulierten Umgebungen mit Anforderungen an die Funktionstrennung), können wir Self-Service Deployment einsetzen. Dies wird auch als Push-the-Button Deployment bezeichnet. Der Deployment-Prozess ist weiterhin vollständig automatisiert, aber eine Person löst ihn durch Knopfdruck aus.\nSelektive Deployments # Selektive Deployments geben uns Flexibilität beim Releasing. Mit selektiven Deployments können wir in eine einzelne geografische Region, ein einzelnes Rechenzentrum, einen Server-Cluster oder ein Netzwerksegment deployen. Das senkt das Risiko und ermöglicht flexiblere Releases.\nBlue-Green Deployments # Blue-Green Deployments sind eine weitere leistungsstarke Praktik für Deployments. Wir unterhalten zwei identische Produktionsumgebungen: eine ist live (grün) und eine ist inaktiv (blau). Alle Benutzer arbeiten auf der Live-Umgebung. Währenddessen deployen wir die nächste Version in die inaktive Umgebung.\nSobald das Deployment in die inaktive Umgebung abgeschlossen ist, können wir die neue Version dort testen, ohne Benutzer zu beeinträchtigen. Wenn alles gut aussieht, schalten wir den Load Balancer um, sodass die blaue Umgebung live wird und die grüne Umgebung inaktiv. Falls etwas schiefgeht, können wir schnell zur vorherigen Version zurückwechseln.\nBlue-Green Deployments haben Kompromisse. Man benötigt zwei vollständige Produktionsumgebungen, was die Kosten erhöht. Der Ansatz ist unkompliziert für zustandslose Anwendungen, wird aber komplexer, wenn Datenbanken oder andere zustandsbehaftete Komponenten beteiligt sind. Das erfordert sorgfältige Architektur und Design.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Deploy-Schritt:\nSit: Features werden alle drei oder mehr Monate in die Produktion deployed. Deployments sind manuell und schmerzhaft. Deployed bedeutet gleichzeitig released. Crawl: Features werden am PI-Boundary (Dreimonatszyklus) in die Produktion deployed. Deployments sind grösstenteils manuell. Deployed bedeutet gleichzeitig released. Walk: Features werden jede Iteration in die Produktion deployed. Deployments sind grösstenteils automatisiert. Einige Features können deployed werden, ohne released zu werden. Run: Features werden jede Iteration vollständig automatisiert durch die Pipeline in die Produktion deployed. Dark Releases sind üblich. Fly: Features werden kontinuierlich während jeder Iteration deployed. Entwicklungsteams initiieren Deployments direkt über Pipeline-Tools. Release ist vollständig vom Deployment entkoppelt. Dark Releases sind die Norm. Kernaussagen # Mit hoher Frequenz und niedrigem Risiko deployen. Kleine, häufige Deployments sind sicherer als grosse, seltene. Deployment von Release trennen. Deployment bringt Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Feature Toggles klug einsetzen. Sie ermöglichen Continuous Deployment, aber denken Sie daran, sie nach dem Release des Features zu entfernen. Dark Launches nutzen. In die Produktion deployen, ohne für Benutzer freizugeben, um den neuen Code zu überwachen und zu validieren. Alles automatisieren. Von der Infrastruktur bis zum Deployment ist Automatisierung die Grundlage von Continuous Deployment. Blue-Green Deployments in Betracht ziehen. Sie ermöglichen Deployments ohne Ausfallzeit und schnelles Rollback, erfordern aber sorgfältige Planung für zustandsbehaftete Komponenten. ","date":"21. November 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-deploy-safe-devops-health-radar/","section":"Blogs","summary":"Deploy ist ein kritischer Schritt im SAFe for DevOps Health Radar. Nachdem wir ein deploybare Paket erstellt und es in einer Staging-Umgebung getestet haben, wollen wir nun unsere Änderungen kontinuierlich in die Produktionsumgebung deployen. Das Ziel ist es, mit hoher Frequenz und niedrigem Risiko zu deployen. In diesem Video erkläre ich, wie wir das erreichen und welche Praktiken Continuous Deployment ermöglichen.\n","title":"Was ist Deploy? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Deploy is a critical step in the SAFe for DevOps Health Radar. After we have built a deployable package and tested it in a staging environment, we now want to continuously deploy our changes into the production environment. The goal is to deploy with high frequency and low risk. In this video, I explain how we achieve this and what practices enable continuous deployment.\nThe Journey So Far # Before we reach the Deploy step, we have already completed several steps in the SAFe DevOps Health Radar. It started with a hypothesis where we captured bright ideas in epic form. We then collaborated and researched to understand customer and market needs. In the architect step, we designed the minimal architecture to prove our hypothesis. We synthesized by breaking down the epic into features for the program backlog. In the develop step, we coded the feature by breaking it into user stories. We committed the code and built a deployable package. After that, we deployed the package into a staging environment for end-to-end testing.\nNow, in the deploy step, we bring our changes into the production environment.\nWhy Continuous Deployment? # The reason we want to continuously deploy our changes into production is simple: small changes carry lower risk than large changes. When we deploy small changes frequently, each deployment has a lower chance of failure. In contrast, if changes accumulate over three months, the deployment becomes much larger and the risk increases significantly.\nContinuous deployment means deploying with high frequency and low risk into the production system.\nSeparating Deployment from Release # To continuously deploy into production, we need to separate deployment from release. A deployment is bringing the compiled code into production with the feature switch turned off. A release is switching the feature switch on in the production environment.\nThis distinction is fundamental. We already discussed this concept in the architect step, because it is important to architect systems so that deployment and release can be separated from the start.\nFeature Toggles # Feature toggles (also called feature switches) enable us to switch features on and off. At its core, a feature toggle is nothing more than an if-statement. If the flag is set, the new behavior is active. If the flag is not set, the old behavior continues.\nThere are important rules to follow when working with feature toggles:\nEach toggle adds a test case. Multiple feature toggles create a combinatorial explosion of scenarios that need testing. Remove toggles after release. A feature toggle is temporary. Once the feature is released and stable, remove the toggle from the code. Do not confuse toggles with application configuration. Application configuration is long-lived and allows you to configure application behavior. A feature toggle is short-lived and only exists to enable continuous deployment. Dark Launches # Separating deployment from release and using feature toggles enables dark launches. In a dark launch, we deploy new code to production with the feature toggle turned off. This lets us test monitoring and alerting in the production environment. We can observe how the newly deployed code behaves with real production data, all without any impact on end users.\nVersion Control for Everything # When we want to continuously deploy into production, we need to have everything in version control. Not just the code, but also the infrastructure configuration, test data, requirements, and architecture documentation. Having everything in version control enables fast rollbacks and rapid investigation of production problems, because we know exactly what was deployed and what changed compared to the previous version.\nInfrastructure as Code # Infrastructure as code enables automated environment setup. We define how our infrastructure should look in configuration files, and these configuration files are stored in version control. Using tools like Chef, Puppet, and others, we can automatically provision and configure our infrastructure. This approach saves costs, increases speed, and lowers risk because the infrastructure setup is consistent and repeatable every time.\nDeployment Automation # To continuously deploy to production, we need to automate all the steps required to bring compiled code into production. This is deployment automation. It is important that developers always receive feedback about whether a deployment succeeded or failed.\nIf full automation is not permitted (for example, in regulated environments with segregation of duty requirements), we can use self-service deployment. This is also known as push-the-button deployment. The deployment process is still fully automated, but a person triggers it by pressing a button.\nSelective Deployments # Selective deployments give us flexibility when releasing. With selective deployments, we can deploy to a single geographic region, a single data center, one server cluster, or one network segment. This lowers risk and enables more flexible releases.\nBlue-Green Deployments # Blue-green deployments are another powerful practice for deployment. We maintain two identical production environments: one is live (green) and one is idle (blue). All users work on the live environment. While they do, we deploy the next version to the idle environment.\nOnce the deployment to the idle environment is complete, we can test the new version there without affecting any users. When everything looks good, we switch the load balancer so the blue environment becomes live and the green environment becomes idle. If something goes wrong, we can quickly switch back to the previous version.\nBlue-green deployments come with trade-offs. You need two full production environments, which increases cost. The approach is straightforward for stateless applications, but becomes more complex when databases or other stateful components are involved, requiring careful architecture and design.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Deploy step:\nSit: Features are deployed to production every three or more months. Deployments are manual and painful. Deployed implies released. Crawl: Features are deployed to production at the PI boundary (three-month cycle). Deployments are mostly manual. Deployed implies released. Walk: Features are deployed to production every iteration. Deployments are mostly automated. Some features can be deployed without being released. Run: Features are deployed to production every iteration, fully automated through the pipeline. Dark releases are common. Fly: Features are deployed continuously throughout each iteration. Dev teams initiate deployments directly via pipeline tools. Release is completely decoupled from deployment. Dark releases are the norm. Key Takeaways # Deploy with high frequency and low risk. Small, frequent deployments are safer than large, infrequent ones. Separate deployment from release. Deployment brings code into production with the feature toggle off. Release switches the feature toggle on. Use feature toggles wisely. They enable continuous deployment, but remember to remove them after the feature is released. Leverage dark launches. Deploy to production without releasing to users so you can monitor and validate the new code. Automate everything. From infrastructure to deployment, automation is the foundation of continuous deployment. Consider blue-green deployments. They enable zero-downtime deployments and fast rollback, but require careful planning for stateful components. ","date":"21 November 2021","externalUrl":null,"permalink":"/en/blogs/what-is-deploy-safe-devops-health-radar/","section":"Blogs","summary":"Deploy is a critical step in the SAFe for DevOps Health Radar. After we have built a deployable package and tested it in a staging environment, we now want to continuously deploy our changes into the production environment. The goal is to deploy with high frequency and low risk. In this video, I explain how we achieve this and what practices enable continuous deployment.\n","title":"What is Deploy? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"17 October 2021","externalUrl":null,"permalink":"/en/tags/agile-finance/","section":"Tags","summary":"","title":"Agile Finance","type":"tags"},{"content":"","date":"17 October 2021","externalUrl":null,"permalink":"/en/tags/participatory-budgeting/","section":"Tags","summary":"","title":"Participatory Budgeting","type":"tags"},{"content":"This is the English-language version of our talk on participatory budgeting at Zühlke. Nadine Broghammer and I describe how we coached a portfolio team through a participatory budgeting (PB) event based on SAFe, and how the value stream leads collectively allocated the budget for the second half of the year. A separate post covers the German version of the same talk.\nWhat Is Participatory Budgeting? # Participatory budgeting is a process within the Scaled Agile Framework (SAFe) that lives at the portfolio level. Instead of a committee distributing money top-down with a watering can, the people who actually run the value streams sit down together and decide where the money goes.\nA portfolio represents a unit or division of the company and contains several value streams. Each value stream owns a specific solution end to end, from concept to customer. It includes everyone who contributes to the solution, all the systems they use, and the flow of information and materials. The shift is fundamental: from project funding to value stream funding, and from top-down allocation to bottom-up consensus.\nCoaching the \u0026ldquo;Fruitmix\u0026rdquo; Portfolio # In the talk, we walk through a real example from Zühlke Switzerland (anonymised as the \u0026ldquo;Fruitmix\u0026rdquo; portfolio with value streams named after fruits like Banana and Date). The portfolio management team had set a budget of CHF 100,000 for the second half of the year and wanted to allocate it across ten value streams. The first half had been turbulent because of COVID, and the team needed to invest where it would have the most impact while still keeping the lights on.\nWe ran a two-hour preparation workshop with the ten value stream leads to introduce the PB concept. They then had about two weeks to describe their initiatives as Epics using the SAFe epic template, split between Run-the-Business (RTB) and Grow-the-Business (GTB). Epics are anchored in a hypothesis statement (for whom, what problem, what outcome, what leading indicators), which makes it possible to validate them quickly rather than waiting for lagging indicators. As coaches we adapted the SAFe Excel template to Zühlke\u0026rsquo;s needs and prepared the agenda, breakout rooms, and calculation logic.\nRunning the Forum in Two Rounds # For the event itself we split the value stream leads into two groups of five, each with a coach. Both groups always represented half of the value streams, but they made decisions for the whole portfolio.\nRound 1 – Run-the-Business. Each value stream pitched its ongoing activities. Both groups independently allocated the full CHF 100,000 across all ten value streams, including those not represented at their table. Coaches kept time, surfaced the OKRs, and helped the groups stay focused on portfolio-level outcomes. In plenary the two proposals were merged into a single agreed RTB allocation.\nRound 2 – Grow-the-Business. The remaining budget (CHF 100,000 minus RTB) was now visible to everyone — and it was tight. What happened next was the most striking part of the event: value stream leads voluntarily reduced their own RTB budgets to free up more space for innovation. Partnerships were proposed, joint epics emerged across value streams, and the GTB discussions became intense. Both groups proposed a GTB allocation, and the plenary worked through the differences toward a shared decision.\nOutcomes and Lessons Learned # The outcome was a budget that the value stream leads owned themselves, not one imposed on them. Transparency increased dramatically — everyone now understood why each value stream got what it got. Cross-value-stream learning was significant, and entrepreneurial thinking emerged naturally once people had real budget responsibility. Participants rated the event 3.5 out of 5 with no score below 3, which we considered a strong result for a first attempt.\nA few practical lessons: do not underestimate preparation, run a simulation before the real event, work in pairs (one coach per breakout group), and consider splitting the epic pitches into a separate alignment meeting so participants have more time to absorb them.\nWhen to Use Participatory Budgeting # Participatory budgeting works well when you have a portfolio of value streams that is too complex for any single committee to evaluate well, when you want to move from project funding to value stream funding, and when you want to grow entrepreneurial ownership inside the organisation. It is less suited to environments where decisions must remain centralised or where value streams are not yet stable enough to take budget responsibility.\nKey Takeaways # Participatory budgeting replaces watering-can allocation. The people closest to the work decide together where the money goes. Fund value streams, not projects. Combined with epic hypotheses, this directs money to validated ideas instead of fixed project plans. Two rounds, RTB then GTB. Showing the remaining budget after RTB makes the cost of \u0026ldquo;business as usual\u0026rdquo; visible and unlocks entrepreneurial moves. Transparency is the biggest benefit. Everyone sees the trade-offs, so frustration drops and buy-in goes up. Entrepreneurial thinking emerges naturally. When leads own the budget, they invest where the portfolio benefits most — even if that means giving up their own share. Preparation and facilitation make or break the event. Good templates, a simulation run, two coaches, and tight moderation are essential. Co-author: Nadine Broghammer\n","date":"17 October 2021","externalUrl":null,"permalink":"/en/blogs/participatory-budgeting-21st-century-english-talk/","section":"Blogs","summary":"This is the English-language version of our talk on participatory budgeting at Zühlke. Nadine Broghammer and I describe how we coached a portfolio team through a participatory budgeting (PB) event based on SAFe, and how the value stream leads collectively allocated the budget for the second half of the year. A separate post covers the German version of the same talk.\n","title":"Participatory Budgeting: Financing in the 21st Century (English Talk)","type":"blogs"},{"content":"","date":"26 September 2021","externalUrl":null,"permalink":"/en/tags/staging/","section":"Tags","summary":"","title":"Staging","type":"tags"},{"content":"","date":"26 September 2021","externalUrl":null,"permalink":"/en/tags/user-acceptance-testing/","section":"Tags","summary":"","title":"User Acceptance Testing","type":"tags"},{"content":"Stage ist der Schritt im SAFe for DevOps Health Radar, in dem wir die finale Validierung vor dem Produktionsgang durchführen. In der Staging-Umgebung führen wir User Acceptance Tests durch, zeigen System Demos für unsere Stakeholder und verifizieren, dass alles wirklich produktionsbereit ist. In diesem Video erkläre ich, was der Stage-Schritt umfasst und warum er für eine zuverlässige Delivery Pipeline unverzichtbar ist.\nDer Weg zum Stage # Bevor wir zum Stage-Schritt gelangen, haben wir die gesamte vorgelagerte Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Diese Ideen werden in Epics mit einem klaren Hypothesis Statement überführt. Wir forschen gemeinsam, um Kundenbedürfnisse zu identifizieren und Marktforschung durchzuführen. Wir entwerfen die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen. Dann synthetisieren wir, indem wir das Epic in Features herunterbrechen, die wir auf eine Roadmap und in unser Backlog aufnehmen.\nVon dort aus entwickeln wir User Stories, committen Quellcode, reintegrieren unsere Änderungen, bauen ein deploybare Artefakt und führen statische Codeanalyse sowie Unit Tests aus. Das deploybare Artefakt wird dann in eine Testumgebung deployed, wo wir Integrationstests und End-to-End-Tests durchführen. Danach sind wir bereit für die Staging-Umgebung.\nWas passiert im Stage # In der Staging-Umgebung führen wir die finale Validierung durch, um festzustellen, ob wir produktionsbereit sind. Die zentrale Aktivität ist das User Acceptance Testing (UAT). Dies ist die Gelegenheit für das Business, das Ergebnis zu prüfen und zu bestätigen, dass es ihren Erwartungen entspricht.\nEine Staging-Umgebung ist per Definition eine Eins-zu-eins-Kopie der Produktionsumgebung. Während wir bereits im Test-Schritt besprochen haben, dass Testumgebungen so nah wie möglich an der Produktion sein sollten, brauchen wir im Stage wirklich diese Übereinstimmung. Nur mit einer produktionsgleichen Umgebung können wir zuverlässig End-to-End-Tests und User Acceptance Testing durchführen.\nBlue-Green Deployments # Um Stakeholdern kontinuierliches Testen in einer Staging-Umgebung zu ermöglichen, können wir Blue-Green Deployments einsetzen. Dieser Ansatz verwendet zwei produktionsgleiche Umgebungen. Eine Umgebung ist live, die andere ist idle. Vor beiden Umgebungen sitzt ein Load Balancer, der zwischen ihnen wechseln kann.\nWenn wir eine neue Version unserer Software haben, deployen wir sie in die idle Umgebung. Sobald das Deployment abgeschlossen ist, schalten wir den Load Balancer auf die neue Umgebung um. Alle Nutzer arbeiten dann mit der neuen Version auf der nun aktiven Umgebung. Die andere Umgebung wird idle und steht für das nächste Deployment bereit.\nDer grosse Vorteil dieses Ansatzes ist zweifach. Erstens: Wenn es ein Problem mit der neuen Version gibt, können wir es in der idle Umgebung untersuchen, ohne die Nutzer der aktiven Umgebung zu beeinträchtigen. Zweitens: Wenn wir nach dem Umschalten ein Problem entdecken, können wir schnell zur vorherigen Version zurückwechseln.\nSystem Demos # Die Staging-Umgebung ist auch der Ort, an dem wir System Demos durchführen. Alle zwei Wochen integrieren wir mit dem Rest der Software und zeigen unseren Stakeholdern, was wir während des Sprints erreicht haben. Stakeholder können uns Feedback geben und entscheiden, ob das Ergebnis bereit für die Produktion ist oder Nacharbeit benötigt.\nDiese regelmässige Feedbackschleife ist eine Kernpraktik in SAFe und stellt sicher, dass das Entwicklungsteam mit den Geschäftserwartungen im Einklang bleibt.\nDas Ergebnis des Stage-Schritts # Das Ergebnis des Stage-Schritts umfasst drei Dinge:\nEin produktionsbereites Artefakt. Das deploybare Artefakt wurde validiert und ist bereit für das Produktions-Deployment. Testnachweis. Dies ist besonders wichtig, wenn Regulierungen dokumentierte Testnachweise erfordern. Stakeholder-Feedback. Gesammelt durch die System Demo und das User Acceptance Testing in der Staging-Umgebung. Die Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Stage-Schritt:\nSit: Keine Staging-Umgebung vorhanden, oder eine Testumgebung wird für das Staging verwendet. Crawl: Features werden manuell einmal pro PI oder alle drei Monate in eine Staging-Umgebung deployed. Walk: Features werden einmal pro Monat in eine Staging-Umgebung deployed und dem Product Management demonstriert. Run: Features und Infrastruktur werden automatisch jede Iteration oder jeden Sprint in eine Staging-Umgebung deployed und vom Product Management akzeptiert. Fly: Stories, Änderungen und Infrastruktur werden automatisch in eine Staging-Umgebung deployed, validiert und gehen sofort weiter zum Deployment. Kernaussagen # Stage ist das finale Validierungstor. Es stellt sicher, dass alles produktionsbereit ist, bevor die Software in die Produktion geht. Die Staging-Umgebung muss der Produktion entsprechen. Sie ist eine Eins-zu-eins-Kopie der Produktionsumgebung, nicht nur eine Annäherung. User Acceptance Testing ist die zentrale Aktivität. Das Business validiert, dass die Software ihren Erwartungen entspricht. Blue-Green Deployments ermöglichen kontinuierliches Testen. Zwei produktionsgleiche Umgebungen mit einem Load Balancer erlauben nahtloses Umschalten und schnelle Rollbacks. System Demos liefern Stakeholder-Feedback. Jeden Sprint prüfen Stakeholder den Fortschritt und geben ihre Freigabe oder fordern Nacharbeit an. So viel wie möglich automatisieren. Im besten Fall sind das Deployment auf Stage, automatisierte Tests und die Übernahme in die Produktion vollständig automatisiert. ","date":"26. September 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-stage-safe-devops-health-radar/","section":"Blogs","summary":"Stage ist der Schritt im SAFe for DevOps Health Radar, in dem wir die finale Validierung vor dem Produktionsgang durchführen. In der Staging-Umgebung führen wir User Acceptance Tests durch, zeigen System Demos für unsere Stakeholder und verifizieren, dass alles wirklich produktionsbereit ist. In diesem Video erkläre ich, was der Stage-Schritt umfasst und warum er für eine zuverlässige Delivery Pipeline unverzichtbar ist.\n","title":"Was ist Stage? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Stage is the step in the SAFe for DevOps Health Radar where we perform the final validation before going to production. In the staging environment, we run user acceptance tests, conduct system demos for our stakeholders, and verify that everything is truly production-ready. In this video, I walk through what the Stage step involves and why it is essential for a reliable delivery pipeline.\nThe Journey to Stage # Before we reach the Stage step, we have gone through the entire upstream pipeline. It starts with bright ideas from the customer or the business. These ideas are transferred into epics with a clear hypothesis statement. We collaborate and research to identify customer needs and perform market research. We architect the minimal architecture needed to prove the hypothesis. Then we synthesize by breaking down the epic into features, which we place on a roadmap and into our backlog.\nFrom there, we develop user stories, commit source code, reintegrate our changes, build a deployable artifact, and run static code analysis and unit tests. The deployable artifact is then deployed to a test environment where we perform integration tests and end-to-end tests. After that, we are ready for the staging environment.\nWhat Happens in Stage # In the staging environment, we perform the final validation to determine if we are production-ready. The primary activity is user acceptance testing (UAT). This is the chance for the business to review what we have built and confirm it meets their expectations.\nA staging environment, by definition, matches the production environment. It is a one-to-one copy. While we already discussed in the test step that test environments should be as close to production as possible, in stage we truly need this match. Only with a production-like environment can we reliably run end-to-end tests and user acceptance testing.\nBlue-Green Deployments # To enable stakeholders to test continuously in a staging environment, we can use blue-green deployments. This approach uses two production-like environments. One environment is live, and the other is idle. In front of both environments sits a load balancer that can switch between them.\nWhen we have a new version of our software, we deploy it into the idle environment. Once the deployment is complete, we switch the load balancer to point to the new environment. All users then work with the new version on the now-live environment. The other environment becomes idle and is available for the next deployment.\nThe big benefit of this approach is twofold. First, if there is a problem with the new version, we can investigate it on the idle environment without affecting the people using the live environment. Second, if we discover a problem after switching, we can quickly switch back to the previous version.\nSystem Demos # The staging environment is also where we conduct system demos. Every two weeks, we integrate with the rest of the software and show our stakeholders what we have achieved during the sprint. Stakeholders can give us feedback and decide whether the result is ready for production or needs rework.\nThis regular feedback loop is a core practice in SAFe and ensures that the development team stays aligned with business expectations.\nThe Output of Stage # The output of the Stage step includes three things:\nA production-ready artifact. The deployable artifact has been validated and is ready for production deployment. Test evidence. This is especially important when regulations are in place that require documented proof of testing. Stakeholder feedback. Gathered through the system demo and user acceptance testing on the staging environment. The Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Stage step:\nSit: No staging environment exists, or a test environment is used for staging. Crawl: Features are deployed manually to a staging environment once every PI or every three months. Walk: Features are deployed to a staging environment once per month and demonstrated to product management. Run: Features and infrastructure are auto-deployed to a staging environment every iteration or sprint and accepted by product management. Fly: Stories, changes, and infrastructure are auto-deployed to a staging environment, validated, and immediately proceed to deployment. Key Takeaways # Stage is the final validation gate. It ensures that everything is production-ready before the software moves to production. The staging environment must match production. It is a one-to-one copy of the production environment, not just a close approximation. User acceptance testing is the primary activity. The business validates the software meets their expectations. Blue-green deployments enable continuous testing. Two production-like environments with a load balancer allow seamless switching and quick rollbacks. System demos provide stakeholder feedback. Every sprint, stakeholders review the progress and give their approval or request rework. Automate as much as possible. In the best case, deployment to stage, automated testing, and promotion to production are all fully automated. ","date":"26 September 2021","externalUrl":null,"permalink":"/en/blogs/what-is-stage-safe-devops-health-radar/","section":"Blogs","summary":"Stage is the step in the SAFe for DevOps Health Radar where we perform the final validation before going to production. In the staging environment, we run user acceptance tests, conduct system demos for our stakeholders, and verify that everything is truly production-ready. In this video, I walk through what the Stage step involves and why it is essential for a reliable delivery pipeline.\n","title":"What is Stage? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"19 September 2021","externalUrl":null,"permalink":"/en/tags/end-to-end-testing/","section":"Tags","summary":"","title":"End-to-End Testing","type":"tags"},{"content":"In diesem Artikel erkläre ich, was Test End to End innerhalb des SAFe® DevOps Health Radars bedeutet und warum es für die Lieferung hochwertiger Software unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\nWo Test End to End in der Pipeline einzuordnen ist # In der SAFe DevOps Pipeline entstehen grosse Ideen auf Kunden- und Geschäftsseite und werden in Epics mit einer klaren Hypothese überführt. Danach arbeiten wir in der Collaborate-and-Research-Phase mit dem Kunden zusammen, führen Interviews und Marktforschung durch. Anschliessend definieren wir im Architect-Schritt die minimale Architektur, um die Hypothese zu beweisen. Im Synthesize-Schritt brechen wir das Epic in Features herunter und erstellen eine Roadmap und Vision. Im Develop-Schritt werden Features in User Stories zerlegt, entwickelt und in die Versionsverwaltung eingecheckt. Der Build-Server integriert den Quellcode, kompiliert ihn und führt Unit-Tests durch. Das Ergebnis des Build-Schritts ist ein deploybares Artefakt, das wir nun End-to-End testen.\nWas im Test End to End Schritt passiert # Im Test End to End Schritt validieren wir die Lösung gegen die Akzeptanzkriterien in einer produktionsnahen Umgebung. Während des Build-Schritts haben wir bereits Unit- und Komponententests ausgeführt. Jetzt im Test End to End Schritt führen wir Tests auf Feature-Ebene durch, also System- oder Integrationstests.\nUm diese Integrationstests zuverlässig auszuführen, benötigen wir eine Umgebung, die der Produktionsumgebung so nahe wie möglich kommt. Nur so können wir den Testergebnissen vertrauen. Alles muss in der Versionsverwaltung sein, einschliesslich der Konfigurationen der Testumgebungen.\nTestdaten # Um Tests in einer Testumgebung auszuführen, benötigen wir Testdaten. Dieses Thema beginnt im Architect-Schritt, wo wir das System testbar gestalten, und setzt sich im Develop-Schritt fort, wo wir die Testdaten erstellen.\nEs ist essenziell, synthetische, produktionsnahe Testdaten zu verwenden. In vielen Projekten sehe ich, dass Produktionsdaten oder anonymisierte Produktionsdaten zum Testen verwendet werden. Das ist zwar möglich, aber nicht empfehlenswert. Wenn Sie Produktionsdaten verwenden, erhalten Sie instabile Tests, weil sich die Daten jederzeit ändern oder entfernt werden können. Ein instabiler Test hat null Wert. Alle Testdaten müssen in der Versionsverwaltung gespeichert sein.\nService-Virtualisierung # In der Regel hängt Ihr System über Schnittstellen von anderen Systemen ab. Um schnell voranzukommen, müssen Sie von diesen anderen Systemen entkoppelt sein und unabhängig testen können. Das erreichen wir durch Service-Virtualisierung: Wir erstellen Simulatoren für externe Systeme, um unabhängig von deren Release-Zyklen testen zu können.\nDas hat den grossen Vorteil, dass wir unsere synthetischen Testdaten auch für die anderen Systeme verwenden können. Wir reichern die Simulatoren mit den korrekten synthetischen Testdaten an, und auch diese Simulatoren müssen in der Versionsverwaltung gepflegt werden.\nNicht-funktionales Testen # Wir müssen nicht nur funktionale Tests durchführen, sondern auch nicht-funktionale Tests. Nicht-funktionale Anforderungen sind Systemeigenschaften wie Sicherheit, Zuverlässigkeit, Performance, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Das sind die sogenannten \u0026ldquo;-ilities\u0026rdquo; unseres Systems.\nEine wichtige Unterscheidung: Eine nicht-funktionale Anforderung ist kein Backlog-Item, keine User Story und kein Feature. Sie ist eine Einschränkung auf unserem Backlog, die für alle Backlog-Items gilt.\nDie agile Testmatrix # Um ein klareres Bild der Testautomatisierung zu bekommen, verwende ich die agile Testmatrix, die aus vier Quadranten besteht:\nQ1: Unit- und Komponententests # Das sind die Tests, die wir während des Build-Schritts ausführen. Sie lassen sich leicht automatisieren, und wir verwenden in diesem Bereich testgetriebene Entwicklung.\nQ2: Funktionale Tests (User Acceptance Tests) # Hier führen wir die Akzeptanztests aus, die in Features und User Stories definiert wurden. Wir verwenden Behaviour-Driven Development, um gute Akzeptanzkriterien zu erstellen. Die Tests in diesem Bereich werden vorzugsweise automatisiert.\nQ3: Akzeptanztests auf Systemebene # In diesem Quadranten validieren wir das Verhalten des gesamten Systems, einschliesslich der Interaktionen mit anderen Systemen. Wir verwenden explorative Tests oder Workflow-Tests. Automatisierung ist in diesem Bereich schwierig, und die Wartung dieser Tests ist aufwendig, daher gibt es meist viele manuelle Tests.\nQ4: Nicht-funktionale Tests # Hier führen wir die nicht-funktionalen Anforderungstests gegen unser System aus. Es gibt spezialisierte Tools für Sicherheitstests, Performancetests und mehr. Dank der guten Toolunterstützung lassen sich diese Tests leicht automatisieren, was zu einem hohen Automatisierungsgrad führt.\nDas Ergebnis # Das Ergebnis des Test End to End Schritts ist eine verifizierte Lösung. Wir haben funktionale Tests, Integrationstests, Regressionstests, Performancetests und explorative Tests durchgeführt. Zudem haben wir Testnachweise, die üblicherweise in regulierten Umgebungen benötigt werden.\nSAFe DevOps Health Radar Assessment # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für Test End to End:\nSit: Tests werden manuell in Umgebungen durchgeführt, die die Produktion nicht nachbilden. Tests finden in grossen Batches während einer geplanten Testphase statt. Crawl: Tests sind grösstenteils manuell in nicht-produktionsnahen Umgebungen. Stories werden innerhalb eines einzelnen PI (Drei-Monats-Zyklus) unabhängig implementiert und getestet. Walk: Die Hälfte der Tests ist automatisiert und wird in produktionsnahen oder produktionssimulierten Umgebungen pro PI durchgeführt. Run: Die Mehrheit der Tests ist automatisiert und läuft in produktionsnahen Umgebungen. Stories werden pro Iteration (Zwei-Wochen-Sprint) implementiert und vollständig getestet. Fly: Erfolgreiche Builds lösen automatische Deployments in produktionsnahe Testumgebungen aus. Alle Tests sind automatisiert, laufen parallel, und Änderungen werden nach jedem Commit vollständig validiert. Test End to End bedeutet, unser System end-to-end in einer produktionsnahen Umgebung zu validieren, und zwar sowohl funktional als auch nicht-funktional. Es ist ein kritischer Schritt in der Continuous Integration Pipeline, der sicherstellt, dass wir verifizierte, hochwertige Lösungen liefern.\n","date":"19. September 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-test-end-to-end-safe-devops-health-radar/","section":"Blogs","summary":"In diesem Artikel erkläre ich, was Test End to End innerhalb des SAFe® DevOps Health Radars bedeutet und warum es für die Lieferung hochwertiger Software unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\n","title":"Was ist Test End to End? | SAFe® DevOps Health Radar","type":"blogs"},{"content":"In this article, I explain what Test End to End means within the SAFe® DevOps Health Radar and why it is essential for delivering high-quality software. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out what fits your needs or what solves your problem.\nWhere Test End to End Fits in the Pipeline # In the SAFe DevOps pipeline, big ideas come from customers and the business side and get transferred into epics with a clear hypothesis statement. After that, we collaborate and research with the customer, do interviews, and conduct market research. Then we architect the minimal architecture to prove the hypothesis. In the synthesize step, we break down the epic into features and create a roadmap and a vision. In the develop step, we break features into user stories, develop them, and commit the source code into the version control system. The build server integrates the source code, compiles it, and runs unit tests. The output of the build step is a deployable artifact, which we now test end to end.\nWhat Happens in the Test End to End Step # In the Test End to End step, we validate the solution against the acceptance criteria in a production-like environment. During the build step, we already executed unit and component tests. Now in the Test End to End step, we perform tests on a feature level, which are system-level or integration tests.\nTo run these integration tests reliably, we need an environment that is as close as possible to the production system. This ensures we can trust the test results. Everything needs to be in version control, including the configurations of the test environments.\nTest Data # To execute tests in a test environment, we need test data. This topic starts in the architect step, where we design the system to be testable, and continues into the develop step, where we create the test data.\nIt is essential to use synthetic, production-like test data. In many projects I see people using production data or anonymized production data for testing. This is possible but not recommended. When you use production data, you get flaky tests because the data can always change or be removed. A flaky test has zero value. All test data needs to be stored in version control.\nService Virtualization # Usually, your system depends on other systems through interfaces. To move fast, you need to be decoupled from these other systems and test independently. We achieve this through service virtualization: creating simulators for external systems so we can test independently of their release cycles.\nThis has the great benefit that we can use our synthetic test data for the other systems as well. We enrich the simulators with the correct synthetic test data, and these simulators also need to be maintained under version control.\nNon-Functional Testing # We not only need to do functional testing but also non-functional testing. Non-functional requirements are system attributes such as security, reliability, performance, maintainability, scalability, and usability. These are the \u0026ldquo;-ilities\u0026rdquo; of our system.\nAn important distinction: a non-functional requirement is not a backlog item, not a user story, and not a feature. It is a constraint on our backlog that applies to all backlog items.\nThe Agile Test Matrix # To get a clearer picture of test automation, I use the agile test matrix, which consists of four quadrants:\nQ1: Unit and Component Tests # These are the tests we execute during the build step. They can easily be automated, and we use test-driven development in this area.\nQ2: Functional Tests (User Acceptance Tests) # Here we execute acceptance tests defined in features and user stories. We use behaviour-driven development to create a good set of acceptance criteria. The tests in this area are preferably automated.\nQ3: System-Level Acceptance Tests # In this quadrant, we validate the behaviour of the whole system, including interactions with other systems. We use exploratory testing or workflow testing. Automation is hard in this area, and maintaining these tests is expensive, so there are usually many manual tests.\nQ4: Non-Functional Tests # Here we execute the non-functional requirements tests against our system. There are specialized tools for security testing, performance testing, and more. Because of the strong tool support, it is easy to automate these tests, resulting in a high degree of automation.\nThe Output # The output of the Test End to End step is a verified solution. We have executed functional tests, integration tests, regression tests, performance tests, and exploratory testing. We also have test evidence, which is usually needed in regulated environments.\nSAFe DevOps Health Radar Assessment # The SAFe DevOps Health Radar provides a maturity model for Test End to End:\nSit: Testing is performed manually in environments that do not mimic production. Testing occurs in large batches during a scheduled testing phase. Crawl: Testing is mostly manual in non-production-like environments. Stories are implemented and tested independently within a single PI (three-month cycle). Walk: Half the testing is automated and performed in production-like or production-simulated environments every PI. Run: The majority of tests are automated and run in production-like environments. Stories are implemented and fully tested every iteration (two-week sprint). Fly: Successful builds trigger automatic deployments to production-like test environments. All tests are automated, tests run in parallel, and changes are fully validated after every commit. Test End to End means validating our system end to end in a production-like environment, covering both functional and non-functional testing. It is a critical step in the Continuous Integration pipeline that ensures we deliver verified, high-quality solutions.\n","date":"19 September 2021","externalUrl":null,"permalink":"/en/blogs/what-is-test-end-to-end-safe-devops-health-radar/","section":"Blogs","summary":"In this article, I explain what Test End to End means within the SAFe® DevOps Health Radar and why it is essential for delivering high-quality software. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out what fits your needs or what solves your problem.\n","title":"What is Test End to End? | SAFe® DevOps Health Radar","type":"blogs"},{"content":"","date":"12 September 2021","externalUrl":null,"permalink":"/en/tags/build-automation/","section":"Tags","summary":"","title":"Build Automation","type":"tags"},{"content":"Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.\nVom committed Code zum deploybaren Artefakt # Bevor wir den Build-Schritt erreichen, haben wir die früheren Stufen des SAFe for DevOps Health Radar durchlaufen. Alles beginnt mit Ideen vom Kunden oder Business. Wir formulieren Hypothesen, forschen gemeinsam, um das echte Kundenbedürfnis zu identifizieren, definieren die minimale Architektur und entwickeln eine Vision mit Roadmap und Features. Im Develop-Schritt brechen wir Features in User Stories herunter und implementieren sie.\nSobald der Code committed ist, beginnt der Build-Schritt. Das Ziel ist es, den committed Code mit dem Rest der Codebasis zu reintegrieren, Tests und Code-Analysen durchzuführen und ein deploybares Artefakt mit eingebauter Qualität zu erzeugen.\nContinuous Integration # Jeder Commit in die Versionskontrolle sollte einen automatisierten Prozess auslösen. Der Continuous Integration Server nimmt den neu committed Code, reintegriert ihn mit dem Rest der Codebasis und führt dann eine Reihe von Prüfungen durch:\nBuild/Kompilieren des Codes zusammen mit dem Rest der Codebasis Unit Tests ausführen, um die Korrektheit auf Komponentenebene zu überprüfen Code-Analyse durchführen, um die Codequalität zu prüfen Sicherheits-Code-Analyse ausführen (statische Analyse), um Schwachstellen zu erkennen Das zentrale Prinzip ist schnelles Feedback. Entwickler müssen so schnell wie möglich wissen, ob ihr committed Code in Ordnung war oder ob er Probleme eingeführt hat.\nDas Problem mit langlebigen Branches # Eine der häufigsten Problemquellen sind langlebige Branches. Teams arbeiten oft einen ganzen Sprint auf einem Branch und versuchen dann am letzten Tag, alles zu reintegrieren. Dieser Ansatz verursacht viele Probleme und ist selten erfolgreich.\nDie Lösung ist, so schnell wie möglich zurückzumergen, damit es immer einen Branch gibt, der die aktuelle Version der Software enthält. Ob das Team Trunk-Based Development oder Git Flow verfolgt, ist seine Entscheidung. Wichtig ist, dass Code schnell zurückgemergt wird, damit Continuous Integration seine Aufgabe erfüllen kann.\nBroken Builds und Gated Commits # Ein Broken Build betrifft nicht nur das eigene Team, sondern auch andere Teams, die an derselben Codebasis arbeiten. Deshalb hat ein Broken Build immer die höchste Priorität und muss sofort behoben werden.\nEine Strategie, um Broken Builds von vornherein zu vermeiden, ist der Gated Commit. Bei Gated Commits nimmt der Build Server den neu committed Code und reintegriert ihn mit dem Rest der Codebasis, ohne ihn bereits in die Versionskontrolle zu committen. Dann wird der Code kompiliert, die Unit Tests ausgeführt, die Code-Analyse durchgeführt und die Sicherheitsanalyse ausgeführt. Nur wenn alles erfolgreich ist, committet der Build Server den Code in die Versionskontrolle. Falls etwas fehlschlägt, kommt der Code zurück mit einer Benachrichtigung. Diese Technik verhindert, dass Defekte jemals in die Haupt-Codebasis gelangen.\nApplication Security # Statische Sicherheitsprüfungen sind ein wesentlicher Bestandteil des Build-Schritts. Unter dem Oberbegriff Application Security analysieren wir statisch nicht nur unseren eigenen Quellcode, sondern auch die Pakete und Bibliotheken, von denen wir abhängen. Eine Schwachstelle in irgendeiner Bibliothek in der Abhängigkeitskette kann zu einer Schwachstelle in unserer Anwendung werden. Automatisierte Sicherheits-Scan-Tools erkennen diese Probleme frühzeitig, bevor das Artefakt in die Produktion gelangt.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Build-Schritt:\nSit: Builds werden weniger als einmal pro Iteration oder Sprint ausgeführt und sind komplett manuell. Crawl: Builds werden einmal pro Iteration oder Sprint ausgeführt und sind teilweise automatisiert. Dev-Branches sind über Monate oder länger offen und Builds brechen häufig. Walk: Automatisierte Builds laufen einmal täglich. Broken Builds werden in zwei bis vier Stunden behoben. Manuelle Unit Tests werden gegen jeden Build ausgeführt. Dev-Branches sind zwei bis vier Wochen offen. Run: Builds laufen automatisch bei jedem Code-Commit. Broken Builds werden innerhalb einer Stunde behoben. Automatisierte Unit Tests werden gegen jeden Build ausgeführt. Dev-Branches werden in jedem Sprint in den Trunk gemergt. Fly: Builds laufen bei jedem Commit. Builds beinhalten statische Code-Analyse und Sicherheitsanalyse. Gated Commits verhindern, dass Defekte in die Versionskontrolle gelangen. Dev-Branches werden bei jedem Commit in den Trunk gemergt. Kernaussagen # Das Ziel von Build ist ein deploybares Artefakt mit eingebauter Qualität. Committed Code muss reintegriert, kompiliert, getestet und analysiert werden, bevor er zu einem Artefakt wird. Continuous Integration ist essenziell. Jeder Commit sollte automatisch einen Build, Unit Tests, Code-Analyse und Sicherheitsanalyse auslösen. Langlebige Branches vermeiden. So schnell wie möglich in den Haupt-Branch zurückmergen, um die Integration reibungslos zu halten. Broken Builds sofort beheben. Ein Broken Build hat die höchste Priorität, weil er das gesamte Team und andere Teams betrifft. Gated Commits nutzen, um Broken Builds zu verhindern. Der Build Server validiert den Code, bevor er in die Versionskontrolle gelangt. Application Security in den Build einbinden. Eigenen Code und alle Abhängigkeiten bei jedem Build auf Schwachstellen scannen. ","date":"12. September 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-build-safe-devops-health-radar/","section":"Blogs","summary":"Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.\n","title":"Was ist Build? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Build is the step in the SAFe for DevOps Health Radar where committed code is continuously integrated, tested, and turned into a deployable artifact with built-in quality. In this video, I walk through what the Build step involves, why continuous integration matters, and how techniques like gated commits and static security analysis help you maintain quality at speed.\nFrom Committed Code to Deployable Artifact # Before we reach the Build step, we have gone through the earlier stages of the SAFe for DevOps Health Radar. It starts with ideas from the customer or business. We formulate hypotheses, collaborate and research to identify the real customer need, define the minimal architecture, and synthesize a vision with a roadmap and features. In the Develop step, we break features into user stories and implement them.\nOnce the code is committed, the Build step begins. The goal is to take the committed code, reintegrate it with the rest of the codebase, run tests and code analysis, and produce a deployable artifact with built-in quality.\nContinuous Integration # Every commit to version control should trigger an automated process. The continuous integration server takes the newly committed code, reintegrates it with the rest of the codebase, and then executes a series of checks:\nBuild/Compile the code together with the rest of the codebase Run unit tests to verify component-level correctness Execute code analysis to check code quality Run security code analysis (static analysis) to detect vulnerabilities The key principle is fast feedback. Developers need to know as quickly as possible whether their committed code was good or whether it introduced problems.\nThe Problem with Long-Lived Branches # One of the most common sources of problems is long-lived branches. Teams often work on a branch for an entire sprint and then try to reintegrate everything on the last day. This approach causes a lot of issues and is rarely successful.\nThe solution is to merge back as fast as possible so that there is always one branch containing the current version of the software. Whether the team follows trunk-based development or Git Flow is their decision. The important thing is that code gets merged back quickly so that continuous integration can do its job.\nBroken Builds and Gated Commits # A broken build affects not only your own team but also other teams working on the same codebase. That is why a broken build always has the highest priority and needs to be fixed immediately.\nOne strategy to avoid broken builds altogether is the gated commit. With gated commits, the build server takes your newly committed code and reintegrates it with the rest of the codebase without committing it to version control yet. It then builds the code, runs the unit tests, executes the code analysis, and performs the security analysis. Only if everything passes does the build server commit your code into version control. If something fails, your code comes back to you with a notification. This technique prevents defects from ever entering the main codebase.\nApplication Security # Static security checks are an essential part of the Build step. Under the umbrella of application security, we statically analyse not only our own source code but also the packages and libraries we depend on. A vulnerability in any library in the dependency chain can become a vulnerability in our application. Automated security scanning tools catch these issues early, before the artifact reaches production.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Build step:\nSit: Builds are run fewer than once per iteration or sprint and are completely manual. Crawl: Builds are run once per iteration or sprint and are partially automated. Dev branches are open for months or more and builds break often. Walk: Automated builds run once a day. Broken builds are corrected in two to four hours. Manual unit tests are run against each build. Dev branches are open two to four weeks. Run: Builds run automatically upon code commit. Broken builds are corrected within one hour. Automated unit tests are run against each build. Dev branches are merged to trunk every iteration. Fly: Builds run on every commit. Builds include static code analysis and security analysis. Gated commits prevent defects from entering version control. Dev branches are merged to trunk on every commit. Key Takeaways # The goal of Build is a deployable artifact with built-in quality. Committed code must be reintegrated, compiled, tested, and analysed before it becomes an artifact. Continuous integration is essential. Every commit should trigger a build, unit tests, code analysis, and security analysis automatically. Avoid long-lived branches. Merge back to the main branch as quickly as possible to keep integration smooth. Fix broken builds immediately. A broken build has the highest priority because it affects the entire team and other teams. Use gated commits to prevent broken builds. The build server validates your code before it enters version control. Include application security in your build. Scan your own code and all dependencies for vulnerabilities as part of every build. ","date":"12 September 2021","externalUrl":null,"permalink":"/en/blogs/what-is-build-safe-devops-health-radar/","section":"Blogs","summary":"Build is the step in the SAFe for DevOps Health Radar where committed code is continuously integrated, tested, and turned into a deployable artifact with built-in quality. In this video, I walk through what the Build step involves, why continuous integration matters, and how techniques like gated commits and static security analysis help you maintain quality at speed.\n","title":"What is Build? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"5 September 2021","externalUrl":null,"permalink":"/en/tags/behavior-driven-development/","section":"Tags","summary":"","title":"Behavior-Driven Development","type":"tags"},{"content":"","date":"5 September 2021","externalUrl":null,"permalink":"/en/tags/built-in-quality/","section":"Tags","summary":"","title":"Built-in Quality","type":"tags"},{"content":"","date":"5. September 2021","externalUrl":null,"permalink":"/de/tags/eingebaute-qualit%C3%A4t/","section":"Tags","summary":"","title":"Eingebaute Qualität","type":"tags"},{"content":"Im SAFe DevOps Health Radar ist Develop der Schritt, in dem wir die Features aus der Continuous Exploration in funktionierenden Code umwandeln. Wir teilen Features in User Stories auf, implementieren sie mit starkem Fokus auf eingebaute Qualität und committen alles in die Versionskontrolle. In diesem Video erkläre ich den Develop-Schritt und warum Qualitätspraktiken wie TDD und BDD so wichtig sind.\nWo Develop in die Pipeline passt # In den vorherigen Videos haben wir Continuous Exploration betrachtet: Ideen von Business und Kunden sammeln, sie in Epics mit klaren Hypothesenaussagen transformieren, diese Hypothesen durch Kundeninterviews und Marktforschung in Collaborate and Research validieren, die minimale Architektur in Architect definieren und alles in Features für unser Backlog und unsere Roadmap zusammenführen.\nMit diesen Features gehen wir nun in den Develop-Schritt. Hier teilen wir Features in Stories auf, implementieren diese Stories und committen den Code in die Versionskontrolle.\nFeatures in Stories aufteilen # Ein Feature ist typischerweise grösser als eine einzelne Iteration oder ein Sprint. Deshalb müssen wir Features in kleinere User Stories herunterbrechen. Das Ziel ist es, das minimale Stück zu identifizieren, das dem Business oder dem Kunden Wert liefert und sofort gebaut werden kann.\nZum Beispiel: Wenn wir eine Website mit mehreren Eingabeformularen bauen müssen, könnte die kleinste wertvolle Story sein: das Website-Gerüst bauen, es mit dem Backend und einem externen System oder einer Datenbank verbinden und etwas auf dem Bildschirm anzeigen. Das beweist, dass wir integrieren können, und liefert bereits Wert.\nGute User Stories schreiben # Features aufzuteilen allein reicht nicht aus. Wir müssen die Stories ordentlich schreiben. Eine User Story folgt einer klaren Vorlage:\nTitel, der die Story beschreibt Satz in der Form: \u0026ldquo;Als [Nutzer] möchte ich [Aktion], damit [Geschäftswert]\u0026rdquo; Akzeptanzkriterien im Given/When/Then-Format (Behavior Driven Development) Zum Beispiel: \u0026ldquo;Als Fahrer möchte ich den Geldbetrag vor dem Tanken begrenzen, damit ich meine Ausgaben kontrollieren kann.\u0026rdquo; Die Akzeptanzkriterien spezifizieren dann: \u0026ldquo;Gegeben, dass der Fahrer einen Höchstbetrag angibt, wenn die Tankkosten den Betrag erreichen, dann stoppt der Tankvorgang automatisch.\u0026rdquo;\nMit BDD erhalten wir direkt aus den Akzeptanzkriterien eine ausführbare Spezifikation. Das gibt uns Testfälle, die wir sofort implementieren können.\nTest Driven Development # Für die Implementierung verwenden wir einen Test-First-Ansatz: Test Driven Development (TDD). Der Zyklus ist einfach:\nEinen Test schreiben. Ausführen. Er schlägt fehl (rot), weil die Implementierung fehlt. Gerade genug Code schreiben, um den Test zu bestehen (grün). Refactoring durchführen, da alle Tests weiterhin bestehen. Wiederholen mit dem nächsten Test. Der Vorteil ist klar: Wir bekommen Tests für jeden Teil unserer Implementierung und wissen, dass die Implementierung genau das tut, was spezifiziert ist. Wenn die User Story bereits mit BDD-Akzeptanzkriterien im Given/When/Then-Format geschrieben ist, wird das Erstellen der Tests noch einfacher.\nEingebaute Qualität und der Shift-Left-Ansatz # Wir wollen Qualität von Anfang an einbauen, anstatt sie nachträglich hineinzutesten. Das ist der Shift-Left-Ansatz: Statt des traditionellen V-Modells, bei dem Tests nach dem Coding stattfinden, verschieben wir das Testen nach links.\nMit Shift Left:\nFeatures werden direkt mit BDD geschrieben (Tests im Given/When/Then-Format) User Stories haben ausführbare Akzeptanzkriterien Code wird mit TDD geschrieben (Test First) Pair Work (z.B. Pair Programming) verbessert sowohl Qualität als auch Geschwindigkeit Das bedeutet, dass Tests auf jeder Ebene direkt von Anfang an geschrieben werden. Qualität wird eingebaut, nicht nachträglich aufgesetzt.\nAlles in die Versionskontrolle # Sobald der Code geschrieben ist, committen wir ihn in die Versionskontrolle. Aber nicht nur den Code. Alles sollte in der Versionskontrolle sein: Code, Infrastrukturkonfiguration, Tests, Testdaten, Anforderungen und Architekturdokumentation.\nIndem wir alles unter Versionskontrolle haben, gewinnen wir volle Rückverfolgbarkeit. Für jede gegebene Version können wir genau sehen, welcher Code, welche Konfiguration, welche Tests und welche Anforderungen Teil dieses Deployments waren.\nApplication Telemetry # Im Architect-Schritt haben wir für Betriebsfähigkeit entworfen. Jetzt im Develop-Schritt implementieren wir dieses Design. Wir fügen Logging-Anweisungen und Application Telemetry hinzu, um die Informationen zu sammeln, die für den effizienten Betrieb des Systems in der Produktion nötig sind, ohne sich auf dem Produktionsserver einzuloggen und nach Fehlern zu suchen.\nApplication Telemetry dient zwei Zwecken:\nBetriebsdaten: Systemgesundheit überwachen und Probleme schnell diagnostizieren Geschäftsdaten: unsere Hypothese evaluieren und den gelieferten Wert messen Sicherheitsanforderungen umsetzen # Im Architect-Schritt haben wir Threat Modelling durchgeführt, um Bedrohungen, Angreifer und Angriffsvektoren zu identifizieren. Im Develop-Schritt schreiben wir den Code, der genau diese Sicherheitsanforderungen adressiert. Sicherheit ist kein nachträglicher Gedanke. Sie wird als Teil der Entwicklungsarbeit implementiert.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für Develop:\nSit: Das Team-Backlog existiert nicht oder wird nicht zur Steuerung der täglichen Arbeit verwendet. Crawl: Stories sind entweder unvollständig oder zu ausführlich. Unit Tests werden in der Regel nicht geschrieben. Peer Reviews werden nicht durchgeführt. Walk: Stories sind vollständig. Die meisten Änderungen haben Unit Tests. Peer Reviews werden meistens durchgeführt. Run: Code wird täglich eingecheckt. Die Unit-Test-Abdeckung liegt über 80%. Peer Reviews werden immer durchgeführt. Fly: Code wird mehrmals täglich eingecheckt. Tests werden vor dem Code geschrieben (TDD). Pair Work und andere Praktiken für eingebaute Qualität sind die Norm. Eine Anmerkung zur Unit-Test-Abdeckung: Eine Abdeckungsmetrik ist als Indikator für das Entwicklungsteam nützlich. Sie kann Bereiche aufzeigen, die Verbesserung brauchen. Es ist jedoch eine Entscheidung des Entwicklers oder des Teams, wo hohe Abdeckung sinnvoll ist. Es gibt Bereiche im Code, in denen null Prozent Abdeckung völlig in Ordnung ist.\nWas Develop produziert # Das Ergebnis des Develop-Schritts ist:\nUser Stories, die verfeinert und bereit für die Implementierung sind Code, der in das Source-Code-Repository committet wurde Tests (Unit Tests, Integrationstests, End-to-End-Tests), die den committeten Code verifizieren Dieser Code geht dann zum nächsten Schritt in der Pipeline: Build. Dort wird der committete Quellcode kompiliert und in deploybare Artefakte verpackt.\nWichtige Erkenntnisse # Features in kleine, wertvolle Stories aufteilen. Jede Story sollte innerhalb einer einzelnen Iteration etwas Bedeutsames liefern. Stories mit BDD schreiben. Given/When/Then-Akzeptanzkriterien liefern ausführbare Spezifikationen und fertige Testfälle. TDD für die Implementierung nutzen. Zuerst Tests schreiben, dann Code. Das baut Qualität von Anfang an ein. Pair Work praktizieren. Zwei Personen, die gemeinsam an einer Story arbeiten, verbessern sowohl Qualität als auch Geschwindigkeit. Alles in die Versionskontrolle. Code, Konfiguration, Tests, Anforderungen, Architektur. Volle Rückverfolgbarkeit hängt davon ab. Application Telemetry implementieren. Im Architect-Schritt entwerfen, im Develop-Schritt einbauen. Sie wird für den Betrieb und die Hypothesenvalidierung benötigt. Sicherheitsanforderungen im Code umsetzen. Threat Modelling identifiziert die Risiken; Develop ist der Ort, an dem sie adressiert werden. ","date":"5. September 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-develop-safe-devops-health-radar/","section":"Blogs","summary":"Im SAFe DevOps Health Radar ist Develop der Schritt, in dem wir die Features aus der Continuous Exploration in funktionierenden Code umwandeln. Wir teilen Features in User Stories auf, implementieren sie mit starkem Fokus auf eingebaute Qualität und committen alles in die Versionskontrolle. In diesem Video erkläre ich den Develop-Schritt und warum Qualitätspraktiken wie TDD und BDD so wichtig sind.\n","title":"Was ist Develop? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In the SAFe DevOps Health Radar, Develop is where we take the features from continuous exploration and turn them into working code. We split features into user stories, implement them with a strong focus on built-in quality, and commit everything to version control. In this video, I walk through the Develop step and explain why quality practices like TDD and BDD are so important.\nWhere Develop Fits in the Pipeline # In previous videos we looked at Continuous Exploration: gathering ideas from the business and customers, transforming them into epics with clear hypothesis statements, validating those hypotheses through client interviews and market research in Collaborate and Research, defining the minimal architecture in Architect, and synthesizing everything into features for our backlog and roadmap.\nWith those features in hand, we now enter the Develop step. Here we split features into stories, implement those stories, and commit the code into version control.\nSplitting Features into Stories # A feature is typically bigger than a single iteration or sprint. That is why we need to break features down into smaller user stories. The goal is to identify the minimum piece that delivers value to the business or the customer and can be built right now.\nFor example, if we need to build a website with multiple input forms, the smallest valuable story might be: build the website skeleton, connect it to the backend and an external system or database, and display something on the screen. This proves we can integrate and already delivers value.\nWriting Good User Stories # Splitting features alone is not enough. We need to write the stories properly. A user story follows a clear template:\nTitle that describes the story Sentence in the form: \u0026ldquo;As a [user], I want to [action], so that [business value]\u0026rdquo; Acceptance criteria written in the Given/When/Then format (Behavior Driven Development) For example: \u0026ldquo;As a driver, I want to limit the amount of money before I fuel, so that I can control my expenditure.\u0026rdquo; The acceptance criteria then specify: \u0026ldquo;Given that the driver indicates a maximum amount of money, when the fuel costs reach the amount, then the fuelling process stops automatically.\u0026rdquo;\nWith BDD we get an executable specification directly from the acceptance criteria. This gives us test cases we can implement straight away.\nTest Driven Development # For implementation we use a test first approach: Test Driven Development (TDD). The cycle is simple:\nWrite a test. Run it. It fails (red) because the implementation is missing. Write just enough code to make the test pass (green). Refactor safely, because all tests still pass. Repeat with the next test. The benefit is clear: we get tests for every piece of our implementation, and we know the implementation does exactly what is specified. When the user story is already written with BDD acceptance criteria in Given/When/Then form, creating the tests becomes even easier.\nBuilt-in Quality and the Shift Left Approach # We want to build quality in from the beginning instead of testing it in afterwards. This is the shift left approach: instead of the traditional V-model where testing happens after coding, we move testing to the left.\nWith shift left:\nFeatures are written directly with BDD (tests in Given/When/Then form) User stories have executable acceptance criteria Code is written using TDD (test first) Pair work (e.g. pair programming) improves both quality and speed This means tests are written at every level, right from the start. Quality is built in, not bolted on afterwards.\nEverything in Version Control # Once the code is written, we commit it to version control. But not just the code. Everything should be in version control: code, infrastructure configuration, tests, test data, requirements, and architecture documentation.\nBy having everything under version control, we gain full traceability. For any given version, we can see exactly what code, configuration, tests, and requirements were part of that deployment.\nApplication Telemetry # In the Architect step, we designed for operability. Now in Develop, we implement that design. We add logging statements and application telemetry to collect the information needed to operate the system efficiently in production, without logging into the production server to hunt for bugs.\nApplication telemetry serves two purposes:\nOperational data: monitoring system health and diagnosing issues quickly Business data: evaluating our hypothesis and measuring the value we deliver Addressing Security Concerns # In the Architect step, we performed threat modelling to identify threats, attackers, and attack vectors. In the Develop step, we write the code that addresses exactly those security concerns. Security is not an afterthought. It is implemented as part of the development work.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for Develop:\nSit: The team backlog does not exist or is not used to manage daily work. Crawl: Stories are either incomplete or too verbose. Unit tests are generally not written. Peer reviews are not conducted. Walk: Stories are complete. Most changes have unit tests. Peer reviews are usually conducted. Run: Code is checked in daily. Unit test coverage is above 80%. Peer reviews are always conducted. Fly: Code is checked in multiple times per day. Tests are written before code (TDD). Pair work and other built-in quality practices are the norm. A note on unit test coverage: having a coverage metric is useful as an indicator for the development team. It can highlight areas that need improvement. However, it is a decision of the developer or team where high coverage makes sense. There are areas in the code where zero percent coverage is perfectly acceptable.\nWhat Develop Produces # The output of the Develop step is:\nUser stories that are refined and ready for implementation Code committed to the source code repository Tests (unit tests, integration tests, end-to-end tests) that verify the committed code This code then moves to the next step in the pipeline: Build. There, the committed source code is compiled and packaged into deployable artifacts.\nKey Takeaways # Split features into small, valuable stories. Each story should deliver something meaningful within a single iteration. Write stories with BDD. Given/When/Then acceptance criteria give you executable specifications and ready-made test cases. Use TDD for implementation. Write tests first, then code. This builds quality in from the start. Embrace pair work. Two people working together on a story improves both quality and speed. Put everything in version control. Code, configuration, tests, requirements, architecture. Full traceability depends on it. Implement application telemetry. Design it in the Architect step, build it in the Develop step. You need it for operations and hypothesis validation. Address security concerns in code. Threat modelling identifies the risks; Develop is where you mitigate them. ","date":"5 September 2021","externalUrl":null,"permalink":"/en/blogs/what-is-develop-safe-devops-health-radar/","section":"Blogs","summary":"In the SAFe DevOps Health Radar, Develop is where we take the features from continuous exploration and turn them into working code. We split features into user stories, implement them with a strong focus on built-in quality, and commit everything to version control. In this video, I walk through the Develop step and explain why quality practices like TDD and BDD are so important.\n","title":"What is Develop? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"2. September 2021","externalUrl":null,"permalink":"/de/tags/finanzen/","section":"Tags","summary":"","title":"Finanzen","type":"tags"},{"content":" Zühlke hat das Konzept der partizipativen Budgetierung übernommen Mehr Innovation und Zusammenarbeit dank Workshops, Coaching und SAFe-Methodik Die Ergebnisse des ersten Versuchs sind positiv Wie sieht moderne Budgetierung aus? In diesem Artikel zeigen Nadine und Romano, wie sie ein Portfolioteam gecoacht und partizipative Budgetierung bei Zühlke angewendet haben, um die Initiativen der verschiedenen Value Streams des Unternehmens zu finanzieren.\nDie Vorbereitungen zur Jahresmitte für die verschiedenen Portfolios von Zühlke Schweiz fielen in eine Zeit grosser Unsicherheit. Unsere Pläne und Massnahmen sind nach wie vor stark von der COVID-19-Pandemie betroffen. Wir müssen jetzt in die richtigen Bereiche investieren und Stabilität schaffen, aber gleichzeitig sicherstellen, dass wir keine neuen Chancen verpassen. Eines dieser Portfolios ist «Fruitmix»*.\nFür das Portfolio «Fruitmix» war das erste Halbjahr ereignisreich und brachte viele neue Anfragen und Möglichkeiten. Aber es blieb auch wenig Zeit und Ressourcen, um sich auf grössere, strategische Themen zu konzentrieren. Und die COVID-Einschränkungen bedeuteten, dass wir auch keine Veranstaltungen durchführen konnten. Das Gesamtbild unterscheidet sich je nach strategischem Fokus und Branche.\nAber das Portfoliomanagement-Team ist sich in einem Punkt einig: Im zweiten Halbjahr muss einen Gang hochgeschaltet werden. Die Situation in Kürze: Das Portfoliomanagement-Team hat ein Budget von CHF 100'000* für das zweite Halbjahr festgelegt. Die 10 Value Streams, darunter einige der grossen wie der Banana Value Stream* und der Date Value Stream*, haben sich inhaltlich und strukturell kaum verändert und bleiben für das zweite Halbjahr bestehen. Die Hauptprioritäten sind gleich, aber die Initiativen sind neu.\nEs wurden viele spannende Initiativen vorgeschlagen, und alle Value Streams im Portfolio können sich auf neue Möglichkeiten freuen. Es ist die Rede von blauen Bananen*, neuen Kombinationen aus Datteln und Beeren* und sogar Experimenten mit Froschfrucht*. Aber um sicherzustellen, dass sie erfolgreich und nicht nur anders sind, braucht es kluge Investitionsentscheidungen. Genau hier kommt die neue Methode der partizipativen Budgetierung (PB) ins Spiel.\nPB ist ein Prozess innerhalb des Scaled Agile Framework (SAFe) und wird auf der übergreifenden Portfolioebene angewendet. Ein solches Portfolio ist eine gute Sache. Es repräsentiert einen bestimmten Abschnitt eines Unternehmens, etwa eine Einheit oder eine Division. In unserem Fall sind das die Früchte*. Das Portfolio verwaltet mehrere Value Streams, die bestimmte Lösungen end-to-end vorantreiben, vom Konzept bis zum Kunden.\nEin Value Stream umfasst alle Personen, die zur Lösung beitragen, alle genutzten Systeme sowie den Informationsfluss und die benötigten Materialien. Im ersten Halbjahr hat der Banana Value Stream beispielsweise ein neues Whitepaper über zukünftiges Bananenwachstum* geschrieben, und der Date Value Stream* hat die Prozesse für seine wichtigsten Liefergegenstände angepasst.\nOKRs, Epics und SAFe # Wir sind nun im zweiten Halbjahr, und das Portfoliomanagement-Team plant, einen Gang hochzuschalten. Um maximalen Mehrwert für die Kunden zu schaffen, setzt das Team auf zwei Dinge: effektive Zusammenarbeit zwischen den Value Streams und unternehmerisches Denken. Ausserdem veranstalten sie zusammen mit uns als Coaches einen Vorbereitungsworkshop. Im Verlauf von zwei Stunden werden wir den 10 Value-Stream-Leads das Konzept der PB erklären, und sie lernen, wie sie es in die Praxis umsetzen. Das hilft bei den Vorbereitungen.\nDer erste Schritt «Inhalte vorbereiten» beginnt sofort und befasst sich bereits mit Leitplanken und Prinzipien. Das Portfolio ist auf die Ziele, OKRs (Objectives \u0026amp; Key Results) und die Strategie von Zühlke ausgerichtet. Dies umfasst alle Portfolio-Initiativen und treibt das Unternehmen voran. Aber nur die besten können umgesetzt werden, da das Budget für die 10 Value Streams* auf CHF 100'000* festgelegt ist. Die Value Streams haben nun Zeit, ihre Grow-the-Business-Initiativen (GTB) in Form eines «Epic» zu beschreiben.\nEpics sind Schlüsselinitiativen, die Auswirkungen auf einen oder mehrere Value Streams haben können. Sie müssen in einem schlanken Business Case analysiert werden, und die notwendige Finanzierung muss verfügbar sein. Genau das erhalten die besten Epics durch das PB-Event. Das SAFe-Epic-Template hilft, die verschiedenen Initiativen zu strukturieren und erleichtert den Vergleich. Zusätzlich zum Grow-the-Business-Teil müssen wir für jeden Value Stream eine Run-the-Business-Bewertung (RTB) durchführen, um das selbstverwaltete Budget festzulegen und die Value Streams am Laufen zu halten.\nAls PB-Coaches haben auch wir viel Vorbereitung zu leisten. Neben den allgemeinen PB-Informationen, der Agenda und den Forum-Diskussionsräumen müssen wir auch eine Berechnungsgrundlage bereitstellen. Das SAFe Excel Template für das PB-Event ist hier hilfreich. Und da wir zertifizierte SAFe® 5 Program Consultants sind, haben wir Zugang zu allen notwendigen Ressourcen. Das PB-Excel wurde an die Bedürfnisse von Zühlke Schweiz angepasst. Beispielsweise werden Berechnungsoptionen anstelle einzelner Elemente verwendet. Das erleichtert die notwendigen Änderungen.\nPartizipative Budgetierung im Plenum # Im zweiten Schritt, «Teilnehmer zusammenstellen», werden die Value-Stream-Leads in zwei Gruppen aufgeteilt. Jede Gruppe besteht aus fünf Teilnehmern und einem Coach. So ist immer die Hälfte der Value Streams in den Gruppen vertreten.\nNach zwei Wochen ist es dann Zeit für Schritt drei, «Foren durchführen», bei dem das Budget in zwei Runden festgelegt wird: zuerst RTB, dann GTB.\nDie RTB-Vorschläge werden von den Value Streams im Plenum in einem kurzen Pitch vorgestellt. Die beiden Gruppen diskutieren dann die Vorschläge und einigen sich auf die Budgetverteilung. Diese erste Runde beginnt mit dem vollen Portfoliobudget (CHF 100'000*) für jede Gruppe. Während der Diskussionen muss jede Gruppe die Pitches aller 10 Value Streams* berücksichtigen, mit dem Ziel, das bestmögliche Ergebnis für das Fruitmix*-Portfolio zu erzielen.\nJede Gruppe hat fünf Vertreter, aber sie berücksichtigen auch die Perspektive der fünf Value Streams, die nicht in der Gruppe vertreten sind. Die Coaches unterstützen und beaufsichtigen die Gruppendiskussionen, behalten die Zeit im Auge und verweisen gelegentlich auf die OKRs und die Strategie. Zurück im Plenum gibt es eine kurze Gruppenpräsentation, bevor eine endgültige Einigung über die RTB-Verteilung unter den 10 Value Streams erzielt wird.\nRaum für Innovation, Ideen für Zusammenarbeit # Die Value-Stream-Leads liefern dann in der zweiten Runde (GTB) einen weiteren Pitch. Die Epic-Präsentationen sind interessant und vielfältig und bieten viele neue Einblicke in die verschiedenen Themen der einzelnen Value Streams. Wer mehr erfahren oder ein Epic nachlesen möchte, kann das jederzeit tun, da alle Epic-Beschreibungen in digitaler Form verfügbar sind.\nIm nächsten Schritt präsentieren wir als Coaches die neue Situation: Das für die Verteilung verfügbare GTB-Budget hängt direkt vom vereinbarten RTB-Budget ab. Also: CHF 100'000 minus RTB. Diese neue Realität zeigt genau, wie viel für echte Innovation zur Verfügung steht. Können wir noch mehr herausholen? Ja!\nDie Value-Stream-Leads zeigen echtes unternehmerisches Denken, indem sie freiwillig ihre eigenen RTB-Budgets reduzieren, um mehr Spielraum für Innovation zu schaffen. Partnerschaften werden vorgeschlagen, Ideen für Zusammenarbeit eingebracht, und es gibt reichlich Denkanstösse für die bevorstehenden Diskussionen. Die GTB-Gruppendiskussionen sind besonders lebhaft und konzentrieren sich auf das reduzierte, aber immer noch beträchtliche GTB-Budget. Die Gespräche sind intensiv, die Zeit ist knapp, und die Entscheidungen sind schwierig. Nach Abschluss der Beratungen präsentieren beide Gruppen ihren Vorschlag für das GTB-Budget und welche Epics damit finanziert werden sollen. Wir begleiten auch die abschliessenden Diskussionen im Plenum. Wir sprechen zunächst über die Gemeinsamkeiten der beiden Gruppenlösungen, und die Value-Stream-Leads arbeiten dann auf einen Konsens hin. Das Budget ist verteilt.\nCo-Autorin: Nadine Broghammer\nOriginalbeitrag: Zühlke | Medium\n","date":"2. September 2021","externalUrl":null,"permalink":"/de/blogs/partizipative-budgetierung-finanzierung-im-21-jahrhundert/","section":"Blogs","summary":" Zühlke hat das Konzept der partizipativen Budgetierung übernommen Mehr Innovation und Zusammenarbeit dank Workshops, Coaching und SAFe-Methodik Die Ergebnisse des ersten Versuchs sind positiv Wie sieht moderne Budgetierung aus? In diesem Artikel zeigen Nadine und Romano, wie sie ein Portfolioteam gecoacht und partizipative Budgetierung bei Zühlke angewendet haben, um die Initiativen der verschiedenen Value Streams des Unternehmens zu finanzieren.\n","title":"Partizipative Budgetierung: Finanzierung im 21. Jahrhundert","type":"blogs"},{"content":"In diesem Artikel erkläre ich, was Continuous Exploration innerhalb des SAFe DevOps Health Radars ist und warum es entscheidend dafür ist, das Richtige auf die richtige Weise zu bauen. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\nWas ist Continuous Exploration? # Continuous Exploration ist die erste Dimension in der SAFe DevOps Pipeline. Hier kommen all die guten Ideen von Kundenseite und aus dem Business herein. Wir transformieren diese Ideen in Epics mit einer klaren Hypothese, führen Markt- und Kundenforschung durch, um die echten Probleme zu verstehen, definieren eine minimale Architektur, die die Hypothese beweist, und erstellen schliesslich eine Vision, eine Roadmap und ein klares Set an Features, die die Kundenbedürfnisse adressieren.\nDas Ziel ist einfach: Wir brauchen eine echte Abstimmung zwischen allen Stakeholdern darüber, welche Hypothesen validiert und was tatsächlich gebaut werden soll.\nWarum Continuous Exploration wichtig ist # Eines der grössten Probleme, mit denen Organisationen konfrontiert sind, ist der Wunsch, zu viel zu bauen. Teams identifizieren oft nicht, welche Dinge echten Wert haben und was wirklich gebaut werden sollte. Das führt dazu, dass das gesamte System mit Arbeit überladen wird, die keinen signifikanten Wert liefert.\nContinuous Exploration löst dieses Problem, indem ein klarer Prozess definiert wird: wie Ideen in Epics transformiert werden, wie Kundenbedürfnisse identifiziert werden, wie eine minimale Architektur definiert wird und wie diese Ideen in Features aufgeteilt werden, die bereit für die Entwicklung sind. Das Ergebnis ist, dass wir in der Lage sind, das Richtige richtig zu bauen.\nDie vier Aktivitäten von Continuous Exploration # Continuous Exploration besteht aus vier Aktivitäten: Hypothesize, Collaborate and Research, Architect und Synthesize.\nHypothesize # Alles beginnt mit Ideen von Kunden und dem Business. In der Hypothesize-Aktivität nehmen wir diese Ideen und erstellen Epics mit einer klaren Hypothese dahinter. Diese Hypothese definiert, was wir glauben, dass Wert liefern wird, und was wir beweisen wollen.\nCollaborate and Research # Mit unseren definierten Epics und deren Hypothesen gehen wir in die Marktforschung und Kundenforschung über. Wir interviewen Kunden, identifizieren ihre echten Bedürfnisse und versuchen, das tatsächliche Problem zu verstehen, das gelöst werden soll. Dieser Schritt stellt sicher, dass wir nicht einfach das bauen, was jemand angefragt hat, sondern das echte zugrundeliegende Problem lösen.\nArchitect # Sobald wir die echten Kundenbedürfnisse verstehen, definieren wir die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen. Es geht hier nicht darum, die vollständige finale Architektur zu bauen. Es geht darum, den einfachsten architekturellen Ansatz zu identifizieren, der es uns ermöglicht, unsere Hypothese zu validieren.\nSynthesize # An diesem Punkt haben wir die echten Kundenbedürfnisse identifiziert, haben eine klare Hypothese und haben eine minimale Architektur definiert, um sie zu beweisen. In der Synthesize-Aktivität erstellen wir eine Vision, eine Roadmap und ein klares Set an Features, die in unser priorisiertes Program Backlog kommen. Dies ist der Output von Continuous Exploration und der Input für Continuous Integration.\nWie schnell ist dieser Prozess? # Eine der Fragen, die mir am häufigsten gestellt wird, ist: Wie lange dauert Continuous Exploration? Die Antwort ist einfach: Es kommt darauf an.\nManche Items können Continuous Exploration innerhalb von Stunden durchlaufen. Andere brauchen Tage, und einige werden Wochen dauern. Was falsch wäre: wenn Continuous Exploration Monate oder sogar Jahre dauert. Das wäre ein Problem.\nEs ist auch wichtig zu verstehen, dass Continuous Exploration kein Drei-Monats-Zyklus ist, nur weil es PI Planning gibt. Wir machen nicht drei Monate Continuous Exploration, haben dann alles im PI Planning und starten dann einen weiteren Drei-Monats-Zyklus. Es ist ein kontinuierlicher Prozess.\nKonkrete Beispiele # Eine einfache Kundenanfrage # Ein Kunde gibt Feedback, dass das Ändern eines kleinen Filters in der Anwendung, um die Reihenfolge umzukehren, massiven Wert für ihn hätte. Diese Anfrage geht sehr schnell durch Hypothesize (die Hypothese ist einfach), durch Collaborate and Research (wir überprüfen schnell das Kundenbedürfnis), durch Architect (die minimale Architektur ist simpel) und in Synthesize, wo sie auf dem Backlog landet. Dieser gesamte Prozess dauert vielleicht nur Stunden.\nEin Bug # Ein Bug kommt herein und wir gehen in Hypothesize. Hier ist es sehr wichtig, den Bug zu analysieren. Ein kleiner Bug wird sich schnell bewegen, aber ein grosser Bug, der die komplette Geschäftslogik verändert, erfordert eine sorgfältige Analyse. In Collaborate and Research müssen wir feststellen, ob dieser Bug mit einem fehlenden Kundenbedürfnis oder einem nicht adressierten Problem zusammenhängt. Wir könnten entdecken, dass es sich nicht wirklich um einen Bug handelt, sondern ein neues Feature erforderlich ist. In Architect analysieren wir die Auswirkungen der Bugbehebung und ob wir die Architektur ändern müssen. In Synthesize erstellen wir schliesslich entweder einen Bugfix oder ein neues Feature für das Backlog.\nEin grosses Epic # Stellen wir uns vor, wir stellen die Hypothese auf, dass ein neues Produkt auf unserer Website die Anzahl der Käufer um 10% steigern würde. Das ist ein grosses Epic mit einer bedeutenden Hypothese, und wir müssen das Minimum Viable Product definieren, um sie zu beweisen. In Collaborate and Research untersuchen wir Marktbedürfnisse, befragen Kunden und erstellen vielleicht Papierprototypen, um die Hypothese zu validieren. Wir analysieren den einfachsten Weg, sie zu beweisen. In Architect bestimmen wir die minimale Architektur, die benötigt wird. In Synthesize müssen wir möglicherweise die Vision und die Roadmap anpassen und erstellen neue Features für das Backlog. Dieser Prozess könnte Wochen dauern.\nDer Output von Continuous Exploration # Nach Continuous Exploration haben wir:\nEine klare Vision, oder eine angepasste bzw. unveränderte Vision Ein klares Set an Features in unserem priorisierten Program Backlog Enabler Features für die architekturelle Runway, die es uns ermöglichen, mehr Geschäftswert zu liefern Eine angepasste oder neue Roadmap Es ist auch erwähnenswert, dass Informationen, die während Continuous Integration, Continuous Deployment oder Release on Demand gesammelt werden, zurück in Continuous Exploration fliessen können. Neue Ideen, Bugs oder Erkenntnisse aus der Produktion speisen den Kreislauf erneut. Das ist die inkrementelle, kontinuierliche Natur der gesamten DevOps Pipeline.\nContinuous Exploration dreht sich darum, Alignment zwischen den Stakeholdern zu erreichen, damit wir identifizieren, welche Hypothese uns den grössten Wert bringt. So können wir bestimmen, was wir bauen müssen, und sicherstellen, dass wir das Richtige richtig bauen.\n","date":"30. August 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-continuous-exploration-safe-devops-health-radar/","section":"Blogs","summary":"In diesem Artikel erkläre ich, was Continuous Exploration innerhalb des SAFe DevOps Health Radars ist und warum es entscheidend dafür ist, das Richtige auf die richtige Weise zu bauen. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.\n","title":"Was ist Continuous Exploration? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In this article, I explain what Continuous Exploration is within the SAFe DevOps Health Radar and why it is essential for building the right thing in the right way. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out of this toolbox what fits your needs and what solves your problems.\nWhat Is Continuous Exploration? # Continuous Exploration is the first dimension in the SAFe DevOps pipeline. It is where all the bright ideas from customers and the business side come in. We transform these ideas into epics with a clear hypothesis statement, conduct market and customer research to understand the real problems, define a minimal architecture that proves the hypothesis, and finally create a vision, a roadmap, and a clear set of features that address customer needs.\nThe goal is simple: we need real alignment between all stakeholders about which hypotheses should be validated and what should actually be built.\nWhy Continuous Exploration Matters # One of the biggest problems organizations face is wanting to build too much. Teams often do not identify which things have real value and which things should truly be built. This leads to overloading the entire system with work that does not deliver significant value.\nContinuous Exploration solves this problem by defining a clear process for how ideas are transformed into epics, how customer needs are identified, how a minimal architecture is defined, and how those ideas are split into features ready for development. The result is that we are able to build the right thing right.\nThe Four Activities of Continuous Exploration # Continuous Exploration consists of four activities: Hypothesize, Collaborate and Research, Architect, and Synthesize.\nHypothesize # Everything starts with ideas from customers and the business. In the hypothesize activity, we take these ideas and create epics with a clear hypothesis statement behind them. This hypothesis defines what we believe will deliver value and what we want to prove.\nCollaborate and Research # With our epics and their hypotheses defined, we move into market research and customer research. We interview customers, identify their real needs, and try to understand the actual problem that should be solved. This step ensures we are not just building what someone asked for, but solving the real underlying problem.\nArchitect # Once we understand the real customer needs, we define the minimal architecture needed to prove the hypothesis. This is not about building the complete final architecture. It is about identifying the simplest architectural approach that allows us to validate our hypothesis.\nSynthesize # At this point, we have identified the real customer needs, have a clear hypothesis, and have defined a minimal architecture to prove it. In the synthesize activity, we create a vision, a roadmap, and a clear set of features that go into our prioritized program backlog. This is the output of Continuous Exploration and the input for Continuous Integration.\nHow Fast Is This Process? # One of the questions I get asked most frequently is: how long does Continuous Exploration take? The answer is simple: it depends.\nSome items may go through Continuous Exploration within hours. Others may take days, and some will take weeks. What would be wrong is if Continuous Exploration takes months or even years. That would be a problem.\nIt is also important to understand that Continuous Exploration is not a three-month cycle just because there is PI Planning. We do not do three months of Continuous Exploration, then have everything in PI Planning, and then start another three-month cycle. It is a continuous process.\nConcrete Examples # A Simple Customer Request # A customer gives feedback saying that changing a small filter in the application to reverse the order would have massive value for them. This request goes very quickly through hypothesize (the hypothesis is straightforward), through collaborate and research (we quickly verify the customer need), through architect (the minimal architecture is simple), and into synthesize where it lands on the backlog. This entire process might only take hours.\nA Bug # A bug comes in and we go into hypothesize. Here it is very important to analyze the bug. A small bug will move quickly, but a huge bug that changes the complete business logic requires careful analysis. In collaborate and research, we need to determine whether this bug relates to a missing customer need or an unaddressed problem. We might discover this is not really a bug but requires a new feature. In architect, we analyze the impact of fixing the bug and whether we need to change the architecture. Finally, in synthesize, we create either a bug fix or a new feature for the backlog.\nA Huge Epic # Imagine we hypothesize that creating a new product on our website would increase the number of users buying that product by 10%. This is a huge epic with a significant hypothesis, and we need to define the minimum viable product to prove it. In collaborate and research, we study market needs, ask customers, and perhaps create paper prototypes to validate the hypothesis. We analyze the simplest way to prove it. In architect, we determine the minimal architecture required. In synthesize, we may need to adapt the vision and roadmap, and we create new features for the backlog. This process could take weeks.\nThe Output of Continuous Exploration # After Continuous Exploration, we have:\nA clear vision, or an adapted or unchanged vision A clear set of features in our prioritized program backlog Enabler features for the architectural runway that enable us to deliver more business value An adapted or new roadmap It is also worth noting that information gathered during Continuous Integration, Continuous Deployment, or Release on Demand can flow back into Continuous Exploration. New ideas, bugs, or insights from production feed back into the cycle. This is the incremental, continuous nature of the entire DevOps pipeline.\nContinuous Exploration is all about getting alignment between stakeholders so that we identify which hypothesis brings us the biggest value. This way, we can determine what we need to build and ensure we build the right thing right.\n","date":"30 August 2021","externalUrl":null,"permalink":"/en/blogs/what-is-continuous-exploration-safe-devops-health-radar/","section":"Blogs","summary":"In this article, I explain what Continuous Exploration is within the SAFe DevOps Health Radar and why it is essential for building the right thing in the right way. Please note that everything discussed here is under the license of Scaled Agile, and that the Scaled Agile Framework is a framework to be used as a toolbox. Take out of this toolbox what fits your needs and what solves your problems.\n","title":"What is Continuous Exploration? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In diesem Video erkläre ich, was Synthesize ist und wie es innerhalb des SAFe DevOps Health Radars funktioniert. Synthesize ist der vierte und letzte Schritt der Continuous Exploration, in dem wir die Ergebnisse von Hypothesize, Collaborate and Research und Architect zu einem priorisierten Backlog mit einer klaren Vision und Roadmap zusammenführen.\nEine klare Vision erstellen # An diesem Punkt der Continuous Exploration haben wir eine Reihe von Epics mit Hypothesen, identifizierte Kundenbedürfnisse und eine minimale Architektur. Was uns fehlt, ist eine klare Vision dessen, was wir erreichen wollen. Synthesize schliesst diese Lücke.\nEine Vision muss sowohl Kunden- als auch Stakeholder-Bedürfnisse widerspiegeln und folgende Fragen beantworten:\nWas wird diese neue Lösung bewirken? Welches Problem wird sie lösen? Welche Features und Vorteile wird sie bieten? Für wen wird sie diese Features und Vorteile bieten? Welche nicht-funktionalen Anforderungen wird sie erfüllen? Epics in Features aufteilen # Aus dem Hypothesize-Schritt haben wir grosse Epics, die signifikante Initiativen darstellen und länger als drei Monate dauern. Diese Epics müssen wir nun in Features und Enabler Features aufteilen.\nEin Feature erfüllt ein Stakeholder-Bedürfnis. Ein Enabler Feature bereitet die architekturelle Runway vor, damit wir in Zukunft mehr Business-Features liefern können. Jedes Feature besteht aus:\nEinem Titel Einer Benefit-Hypothese Akzeptanzkriterien Nicht-funktionalen Anforderungen Ein Feature sollte immer grösser als ein einzelner Sprint oder eine Iteration sein, aber kleiner als ein Quartal oder ein Program Increment (PI). Zum Beispiel könnte ein Feature mit dem Titel \u0026ldquo;In-Service Software Update\u0026rdquo; die Benefit-Hypothese \u0026ldquo;Geplante Ausfallzeit signifikant reduzieren\u0026rdquo; haben, mit Akzeptanzkriterien wie automatischem und manuellem Update, Rollback-Fähigkeit und dem Betrieb aller Services nach dem Update.\nBehaviour-Driven Development (BDD) # Eine besonders effektive Methode zur Definition von Akzeptanzkriterien ist Behaviour-Driven Development (BDD). Anstatt Akzeptanzkriterien als einfache Sätze zu formulieren, verwendet BDD das Given-When-Then-Format:\nGiven: Die Ausgangsbedingung When: Die durchgeführte Aktion Then: Das erwartete Ergebnis Dieser Ansatz erzeugt ausführbare Spezifikationen. Traditionelle Spezifikationen in Jira, Word oder Confluence sind in dem Moment veraltet, in dem man sie speichert. Die einzige Wahrheit für eine Spezifikation liegt im Code. BDD ermöglicht es uns, Tests direkt aus den Akzeptanzkriterien zu schreiben und die Spezifikation immer synchron mit der Implementierung zu halten.\nPriorisierung mit WSJF # Sobald alle Features und Enabler Features definiert sind, kommen sie in ein Program Backlog. Die entscheidende Frage ist: Wie priorisieren wir sie?\nSAFe verwendet Weighted Shortest Job First (WSJF), eine Technik, die den wirtschaftlichen Nutzen maximiert. Die Formel lautet:\nWSJF = Cost of Delay / Job Size\nCost of Delay ist die Summe von drei Faktoren:\nUser-Business Value: Wie viel Wert liefert dieses Feature? Time Criticality: Wie dringend ist dieses Feature? Risk Reduction / Opportunity Enablement: Reduziert dieses Feature Risiken oder ermöglicht es neue Chancen? Für jeden Faktor vergleichen wir alle Features und vergeben Fibonacci-Zahlen (1, 2, 3, 5, 8, 13) relativ zum Feature mit dem niedrigsten Wert. Das Feature mit dem höchsten WSJF erhält die höchste Priorität. So wird sichergestellt, dass wir immer an den Elementen arbeiten, die den grössten wirtschaftlichen Wert in der kürzesten Zeit liefern.\nDie Roadmap erstellen # Mit einer klaren Vision und einem priorisierten Backlog können wir nun eine Roadmap erstellen, die den Weg zur Erreichung unserer Vision definiert. Roadmaps existieren auf mehreren Ebenen:\nTäglich: Sehr detailliert, was wir heute bearbeiten Sprint/Iteration: Rund zwei Wochen geplante Arbeit Quartal/PI: Eine Drei-Monats-Sicht mit Features und Enablern Jährlich: Ein breiterer strategischer Ausblick Drei-Jahres-Sicht: Ein übergeordneter Richtungsplan Die Roadmap ist für heute und den aktuellen Sprint sehr detailliert und wird progressiv weniger detailliert, je weiter wir in die Zukunft blicken.\nDer Output von Synthesize # Der Synthesize-Schritt produziert drei zentrale Ergebnisse:\nEine klare Vision dessen, was wir erreichen wollen und welche Kunden- und Stakeholder-Bedürfnisse wir erfüllen möchten Ein priorisiertes Program Backlog mit Features und Enabler Features Eine Roadmap, die zeigt, wie wir die Vision umsetzen wollen Mit diesen Ergebnissen sind wir bereit für den nächsten Quadranten des SAFe DevOps Health Radars: Continuous Integration. Jetzt beginnen wir mit der Entwicklung der Features, die wir identifiziert und priorisiert haben.\nDie Reifegrade # Sit: Das Program Backlog existiert nicht oder wird nicht geteilt. Crawl: Das Program Backlog existiert, aber die Features sind unvollständig und die Priorisierung erfolgt nachträglich. Walk: Das Program Backlog enthält vollständig definierte Features, die jedoch nicht mit WSJF priorisiert sind. Run: Features im Program Backlog sind vollständig, mit WSJF priorisiert und auf die Lieferkapazität eines Agile Release Trains (ART) kalibriert. Fly: Das Program Backlog ist eine Sammlung von Minimal Marketable Features (MMFs), die mit Behaviour-Driven Development erstellt und mit WSJF priorisiert sind. Kernaussagen # Vision zuerst. Bevor Sie etwas bauen, erstellen Sie eine klare Vision, die Kunden- und Stakeholder-Bedürfnisse widerspiegelt und definiert, welches Problem Sie für wen lösen und welche Vorteile Sie liefern. Epics in passende Features aufteilen. Features sollten grösser als ein Sprint, aber kleiner als ein Quartal sein. Jedes Feature braucht eine Benefit-Hypothese, Akzeptanzkriterien und nicht-funktionale Anforderungen. BDD für ausführbare Spezifikationen nutzen. Given-When-Then-Akzeptanzkriterien halten Ihre Spezifikation im Code lebendig, anstatt in Dokumenten zu veralten. Wirtschaftlich priorisieren mit WSJF. Weighted Shortest Job First stellt sicher, dass Ihr Team an den Elementen arbeitet, die den höchsten wirtschaftlichen Wert relativ zu ihrer Grösse liefern. Roadmaps auf mehreren Ebenen. Von Tagesplänen bis zu Drei-Jahres-Ausblicken bieten Roadmaps auf jedem Horizont Klarheit und werden dabei progressiv weniger detailliert. Synthesize verbindet Exploration mit Delivery. Es transformiert die Inputs aus Hypothesize, Collaborate and Research und Architect in umsetzbare, priorisierte Features, die bereit für Continuous Integration sind. ","date":"22. August 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-synthesize-safe-devops-health-radar/","section":"Blogs","summary":"In diesem Video erkläre ich, was Synthesize ist und wie es innerhalb des SAFe DevOps Health Radars funktioniert. Synthesize ist der vierte und letzte Schritt der Continuous Exploration, in dem wir die Ergebnisse von Hypothesize, Collaborate and Research und Architect zu einem priorisierten Backlog mit einer klaren Vision und Roadmap zusammenführen.\n","title":"Was ist Synthesize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In this video, I explain what Synthesize is and how it works within the SAFe DevOps Health Radar. Synthesize is the fourth and final step of Continuous Exploration, where we combine the outputs of Hypothesize, Collaborate and Research, and Architect into a prioritized backlog with a clear vision and roadmap.\nCreating a Clear Vision # At this point in Continuous Exploration, we have a set of epics with hypothesis statements, identified customer needs, and a minimal architecture. What we lack is a clear vision of what we want to achieve. Synthesize fills that gap.\nA vision needs to reflect both customer and stakeholder needs and should answer these questions:\nWhat will this new solution do? What problem will it solve? What are the features and benefits it will provide? For whom will it provide these features and benefits? What non-functional requirements will it deliver? Breaking Epics into Features # From the Hypothesize step, we have large epics that are significant initiatives lasting longer than three months. We now need to break these epics down into features and enabler features.\nA feature fulfils a stakeholder need. An enabler feature paves the architectural runway so that we can deliver more business features in the future. Each feature consists of:\nA title A benefit hypothesis Acceptance criteria Non-functional requirements A feature should always be bigger than a single sprint or iteration, but smaller than a quarter year or a Program Increment (PI). For example, a feature titled \u0026ldquo;In-Service Software Update\u0026rdquo; might have the benefit hypothesis \u0026ldquo;Significantly reduce the planned downtime,\u0026rdquo; with acceptance criteria such as automatic and manual updates, rollback capacity, and all enabled services running after the update.\nBehaviour-Driven Development (BDD) # One powerful way to define acceptance criteria is through Behaviour-Driven Development (BDD). Instead of writing acceptance criteria as plain sentences, BDD uses the Given-When-Then format:\nGiven: The initial condition When: The action being performed Then: The expected result This approach creates executable specifications. Traditional specifications in Jira, Word, or Confluence become outdated the moment you save them. The only truth for a specification lies within the code. BDD enables us to write tests directly from acceptance criteria, keeping our specification always in sync with the implementation.\nPrioritizing with WSJF # Once all features and enabler features are defined, they go into a program backlog. The critical question is: how do we prioritize them?\nSAFe uses Weighted Shortest Job First (WSJF), a technique that maximizes economic benefit. The formula is:\nWSJF = Cost of Delay / Job Size\nCost of Delay is the sum of three factors:\nUser-Business Value: How much value does this feature deliver? Time Criticality: How urgent is this feature? Risk Reduction / Opportunity Enablement: Does this feature reduce risk or enable new opportunities? For each factor, we compare all features and assign Fibonacci numbers (1, 2, 3, 5, 8, 13) relative to the feature with the lowest value. The feature with the highest WSJF gets the highest priority. This ensures we always work on items that deliver the most economic value in the shortest time.\nBuilding the Roadmap # With a clear vision and a prioritized backlog, we can now create a roadmap that defines the path to achieving our vision. Roadmaps exist at multiple levels:\nDaily: Very detailed, what we work on today Sprint/Iteration: Roughly two weeks of planned work Quarterly/PI: A three-month view with features and enablers Yearly: A broader strategic outlook Three-Year: A high-level directional plan The roadmap is very detailed for today and the current sprint, and progressively less detailed as we look further into the future.\nThe Output of Synthesize # The synthesize step produces three key outputs:\nA clear vision of what we are trying to achieve and which customer and stakeholder needs we want to fulfil A prioritized program backlog containing features and enabler features A roadmap showing how we plan to achieve the vision With these outputs, we are ready to move into the next quarter of the SAFe DevOps Health Radar: Continuous Integration. Now we begin developing the features we have identified and prioritized.\nThe Maturity Levels # Sit: The program backlog does not exist or is not shared. Crawl: The program backlog exists, but features are incomplete and prioritization is an afterthought. Walk: The program backlog contains fully defined features, but they are not prioritized using WSJF. Run: Features in the program backlog are complete, prioritized using WSJF, and calibrated to the delivery capacity of an Agile Release Train (ART). Fly: The program backlog is a collection of Minimal Marketable Features (MMFs) created using Behaviour-Driven Development and prioritized using WSJF. Key Takeaways # Vision first. Before building anything, create a clear vision that reflects customer and stakeholder needs and defines what problem you are solving, for whom, and what benefits you will deliver. Break epics into right-sized features. Features should be bigger than a sprint but smaller than a quarter. Each feature needs a benefit hypothesis, acceptance criteria, and non-functional requirements. Use BDD for executable specifications. Given-When-Then acceptance criteria keep your specification alive in code rather than outdated in documents. Prioritize economically with WSJF. Weighted Shortest Job First ensures your team works on the items that deliver the highest economic value relative to their size. Roadmaps at multiple levels. From daily plans to three-year outlooks, roadmaps provide clarity at every horizon while becoming progressively less detailed over time. Synthesize connects exploration to delivery. It transforms raw inputs from Hypothesize, Collaborate and Research, and Architect into actionable, prioritized features ready for Continuous Integration. ","date":"22 August 2021","externalUrl":null,"permalink":"/en/blogs/what-is-synthesize-safe-devops-health-radar/","section":"Blogs","summary":"In this video, I explain what Synthesize is and how it works within the SAFe DevOps Health Radar. Synthesize is the fourth and final step of Continuous Exploration, where we combine the outputs of Hypothesize, Collaborate and Research, and Architect into a prioritized backlog with a clear vision and roadmap.\n","title":"What is Synthesize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"15 August 2021","externalUrl":null,"permalink":"/en/tags/microservices/","section":"Tags","summary":"","title":"Microservices","type":"tags"},{"content":"","date":"15 August 2021","externalUrl":null,"permalink":"/en/tags/software-architecture/","section":"Tags","summary":"","title":"Software Architecture","type":"tags"},{"content":"Architect ist der dritte Schritt im SAFe DevOps Health Radar, Teil von Continuous Exploration. In diesem Video erkläre ich, wie wir die minimale Architektur definieren, die benötigt wird, um eine Hypothese zu beweisen und die kontinuierliche Wertlieferung an Kunden zu ermöglichen.\nWo Architect in die Pipeline passt # In den vorherigen Schritten haben wir Ideen von der Business- und Kundenseite gesammelt und sie in Epics mit Hypothesen umgewandelt (Hypothesize). Danach haben wir die echten Kundenbedürfnisse analysiert, Marktforschung betrieben und das Geschäftsmodell aktualisiert (Collaborate \u0026amp; Research). Nun definieren wir im Architect-Schritt die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen.\nWarum minimale Architektur? # Der Zweck dieses Schritts ist nicht, eine vollständige, finale Architektur zu entwerfen. Wir wollen gerade genug Architektur definieren, um die kontinuierliche Wertlieferung zu ermöglichen. Wenn sich eine Hypothese als wahr herausstellt, wollen wir bereit sein, kontinuierlich Wert zu liefern, ohne erst eine Continuous Delivery Pipeline aufbauen oder angesammelten Technical Debt beheben zu müssen.\nTrennung von Deployment und Release # Eines der grundlegenden Konzepte in DevOps ist die Trennung von Deployment und Release. Ein Deployment ist das Bringen von kompiliertem Code in die Produktion mit einem Feature Toggle, der ausgeschaltet ist. Ein Release ist das Einschalten dieses Feature Toggles in der Produktion. Durch die Trennung dieser beiden Aktivitäten ermöglichen wir das kontinuierliche Deployment von Code in die Produktion, was ein zentraler Enabler für die kontinuierliche Wertlieferung an unsere Kunden ist.\nArchitektur für Testbarkeit # Als Architekten und Entwickler müssen wir unsere Systeme so gestalten, dass sie ordentlich getestet werden können. Das bedeutet:\nOrdentliche Tests und ordentliche Testdaten haben Lose gekoppelte Architekturen mit kleinen Komponenten oder Services bauen, die jeweils einen einzelnen Zweck erfüllen Über die API-Schicht testen, die stabile und zuverlässige Test-Interfaces bietet Den Microservice-Architekturstil verwenden, bei dem kleine, unabhängige Services in separaten Containern laufen Lose gekoppelte Systeme sind nicht nur einfacher zu testen, sondern auch einfacher zu ändern, zu deployen und unabhängig zu skalieren.\nArchitektur für Releasefähigkeit # In einem grossen System hat man typischerweise mehrere Komponenten, Services oder Microservices. Jede davon sollte ihren eigenen Deployment- und Release-Zyklus haben. Zum Beispiel könnte eine Komponente alle zwei Wochen releasen, eine andere nur bei Bedarf für Sicherheits-Patches, und eine dritte etwa monatlich. Das Gesamtsystem könnte einen vierteljährlichen Release-Zyklus haben.\nDurch das Design für unabhängige Deployment- und Release-Zyklen können Teams in ihrem eigenen Tempo Wert liefern, ohne von anderen Teams oder Komponenten blockiert zu werden.\nArchitektur für den Betrieb # Beim Architekturdesign müssen wir die operativen Bedürfnisse von Anfang an berücksichtigen. Das bedeutet, darüber nachzudenken, wie das System in der Produktion überwacht und betrieben wird, ohne sich direkt auf dem Produktionsserver einzuloggen. Dafür brauchen wir:\nEin gutes Telemetrie- und Logging-System, das alle relevanten Daten aus der Produktionsumgebung extrahiert Nicht nur Applikationsdaten, sondern auch Geschäftsdaten, weil wir unsere Hypothese beweisen und den gelieferten Wert messen müssen Feature Toggles, mit denen wir problematische Features schnell abschalten können, was die Betreibbarkeit massiv verbessert Feature Toggles ermöglichen es uns auch, Features zunächst nur für eine Teilmenge der Benutzer einzuschalten, damit wir beobachten können, wie sich das System in der Produktion verhält, bevor wir einen vollständigen Rollout machen.\nArchitektur für schnelle Wiederherstellung # Wir brauchen einen Plan für den Fall, dass in der Produktion etwas schiefgeht. Dazu gehört:\nEin klarer Incident-Response-Plan zur Wiederherstellung nach schwerwiegenden Vorfällen Die Fähigkeit, Incidents schnell zu analysieren, um Grundursachen zu identifizieren Sicherstellen, dass die Geschäftskontinuität auch während Ausfällen aufrechterhalten werden kann Für schnelle Wiederherstellung zu designen bedeutet, dass die Architektur selbst schnelles Rollback, Isolierung von Fehlern und schnelle Wiederherstellung unterstützt.\nSicherheit: Threat Modelling # Sicherheit muss in der Architekturphase berücksichtigt werden. Wir wenden Threat Modelling an, was folgende Schritte umfasst:\nAlle Bedrohungen identifizieren, die Ihre Anwendung betreffen könnten Potenzielle Angreifer analysieren, die Ihr System ins Visier nehmen könnten Angriffsvektoren abbilden, die diese Angreifer nutzen könnten Die Sicherheitsbedenken adressieren, die aus dieser Analyse hervorgehen Dies gilt sowohl für internetfähige Anwendungen als auch für interne Anwendungen. Es ist wichtig, Sicherheitsexperten aus Ihrer Organisation einzubeziehen, weil sie die Bedrohungen, Angreifer und Angriffsvektoren am besten kennen.\nWas der Architect-Schritt produziert # Der Output dieses Schritts ist:\nEin Solution Intent (auch Solution Blueprint oder Solution Design genannt): eine architektonische Idee für die minimale Architektur, die benötigt wird, um die Hypothese zu beweisen Ein klares Set von nicht-funktionalen Anforderungen (die \u0026ldquo;-ilities\u0026rdquo;): Verfügbarkeit, Nutzbarkeit, Zuverlässigkeit, Testbarkeit, Releasefähigkeit und weitere Diese nicht-funktionalen Anforderungen sind Randbedingungen, die für jede User Story im Backlog gelten. Sie müssen zusammen mit den funktionalen Anforderungen getestet und verifiziert werden.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet eine Reifegradbeurteilung für den Architect-Schritt. Sie bewerten die Effektivität Ihres Teams beim Architekturdesign für Continuous Delivery:\nSit: Die Architektur ist monolithisch und fragil. Sie ist schwer zu ändern und erfordert das Management komplexer Abhängigkeiten über viele Komponenten und Systeme hinweg. Crawl: Die Architektur ist überwiegend monolithisch, aber einige Anwendungen und Systeme sind lose gekoppelt. Walk: Die Architektur ist grösstenteils entkoppelt, erlaubt aber kein Release on Demand. Run: Die Architektur ist auf Wertlieferung ausgerichtet, mit wenigen Abhängigkeiten zwischen Komponenten und Systemen. Fly: Die Architektur ist für Release on Demand und Betreibbarkeit gebaut. Kernaussagen # Nur die minimale Architektur definieren. Nicht über-architekturieren. Gerade genug bauen, um die Hypothese zu beweisen und Continuous Delivery zu ermöglichen. Deployment von Release trennen. Feature Toggles ermöglichen kontinuierliches Deployment und gleichzeitige Kontrolle darüber, wann Features für Benutzer sichtbar werden. Für Testbarkeit designen. Lose gekoppelte Architekturen mit API-Level-Testing und containerisierten Microservices machen die Verifikation einfach. Von Anfang an für den Betrieb designen. Telemetrie, Logging und Feature Toggles sind keine Nachgedanken. Sie sind Architekturentscheidungen. Für Ausfälle planen. Für schnelle Wiederherstellung architekturieren, damit schwerwiegende Vorfälle nicht zu langen Ausfällen werden. Threat Modelling früh anwenden. Bedrohungen, Angreifer und Angriffsvektoren in der Architekturphase identifizieren und Sicherheitsexperten einbeziehen. ","date":"15. August 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-architect-safe-devops-health-radar/","section":"Blogs","summary":"Architect ist der dritte Schritt im SAFe DevOps Health Radar, Teil von Continuous Exploration. In diesem Video erkläre ich, wie wir die minimale Architektur definieren, die benötigt wird, um eine Hypothese zu beweisen und die kontinuierliche Wertlieferung an Kunden zu ermöglichen.\n","title":"Was ist Architect? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Architect is the third step in the SAFe DevOps Health Radar, part of Continuous Exploration. In this video, I explain how we define the minimal architecture needed to prove a hypothesis and enable continuous delivery of value to customers.\nWhere Architect Fits in the Pipeline # In the previous steps, we gathered ideas from the business and customer side and transformed them into epics with hypothesis statements (Hypothesize). We then analyzed real customer needs, conducted market research, and updated the business model (Collaborate \u0026amp; Research). Now in the Architect step, we take these epics and define the minimal architecture needed to prove the hypothesis.\nWhy Minimal Architecture? # The purpose of this step is not to design a complete, final architecture. We want to define just enough architecture to enable continuous delivery of value. When a hypothesis turns out to be true, we want to be ready to deliver value continuously, without having to stop and build a continuous delivery pipeline or fix accumulated technical debt first.\nSeparation of Deployment and Release # One of the fundamental concepts in DevOps is the separation of deployment and release. A deployment is the act of bringing compiled code into production with a feature toggle switched off. A release is the act of switching that feature toggle on in production. By separating these two activities, we enable continuous deployment of code into production, which is a key enabler for continuously delivering value to our customers.\nArchitect for Testability # As architects and developers, we need to design our systems so they can be tested properly. This means:\nHaving proper tests and proper test data Building loosely coupled architectures with small components or services that each serve a single purpose Testing through the API layer, which provides stable and reliable test interfaces Using the microservice architectural style where small, independent services run in separate containers Loosely coupled systems are not only easier to test but also easier to change, deploy, and scale independently.\nArchitect for Releasability # In a large system, you typically have multiple components, services, or microservices. Each of these should have its own deployment and release cycle. For example, one component might release every two weeks, another only on demand for security patches, and a third roughly every month. The overall system might have a quarterly release cycle.\nBy designing for independent deployment and release cycles, teams can deliver value at their own pace without being blocked by other teams or components.\nArchitect for Operations # When architecting a system, we need to consider the operational needs from the start. This means thinking about how the system will be monitored and operated in production without logging into the production server directly. To achieve this, we need:\nA good telemetry and logging system that extracts all relevant data from the production environment Not just application data but also business data, because we need to prove our hypothesis and measure the value we deliver Feature toggles that allow us to quickly switch off problematic features, which massively improves operability Feature toggles also enable us to switch on features for a subset of users first, so we can observe how the system behaves in production before a full rollout.\nArchitect for Fast Recoverability # We need a plan for when something goes wrong in production. This includes:\nA clear incident response plan for recovering from major incidents The ability to analyze incidents quickly to identify root causes Ensuring business continuity can be maintained even during outages Designing for fast recoverability means the architecture itself supports quick rollback, isolation of failures, and rapid recovery.\nSecurity: Threat Modelling # Security must be taken into account during the architecture phase. We apply threat modelling, which involves:\nIdentifying all threats that could affect your application Analyzing potential attackers who might target your system Mapping attack vectors that these attackers could use Addressing the security concerns that emerge from this analysis This applies to both internet-facing applications and internal applications. It is important to involve security experts from your organization, because they know the threats, attackers, and attack vectors best.\nWhat the Architect Step Produces # The output of this step is:\nA solution intent (also called solution blueprint or solution design): an architectural idea for the minimal architecture needed to prove the hypothesis A clear set of non-functional requirements (the \u0026ldquo;-ilities\u0026rdquo;): availability, usability, reliability, testability, releasability, and others These non-functional requirements are constraints that apply to every user story in the backlog. They must be tested and verified alongside the functional requirements.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a maturity assessment for the Architect step. You rate your team\u0026rsquo;s effectiveness at architecting for continuous delivery:\nSit: Architecture is monolithic and fragile. It is difficult to change and involves managing complex dependencies across many components and systems. Crawl: Architecture is predominantly monolithic, but some applications and systems are loosely coupled. Walk: Architecture is mostly decoupled but does not allow release on demand. Run: Architecture is aligned around value delivery with few dependencies across components and systems. Fly: Architecture is built for release on demand and operability. Key Takeaways # Define only the minimal architecture. Do not over-architect. Build just enough to prove the hypothesis and enable continuous delivery. Separate deployment from release. Feature toggles allow you to deploy continuously while controlling when features become visible to users. Design for testability. Loosely coupled architectures with API-level testing and containerized microservices make verification straightforward. Design for operations from the start. Telemetry, logging, and feature toggles are not afterthoughts. They are architectural decisions. Plan for failure. Architect for fast recoverability so that major incidents do not turn into prolonged outages. Apply threat modelling early. Identify threats, attackers, and attack vectors during the architecture phase, and involve your security experts. ","date":"15 August 2021","externalUrl":null,"permalink":"/en/blogs/what-is-architect-safe-devops-health-radar/","section":"Blogs","summary":"Architect is the third step in the SAFe DevOps Health Radar, part of Continuous Exploration. In this video, I explain how we define the minimal architecture needed to prove a hypothesis and enable continuous delivery of value to customers.\n","title":"What is Architect? | SAFe DevOps Health Radar","type":"blogs"},{"content":"","date":"8 August 2021","externalUrl":null,"permalink":"/en/tags/business-model-canvas/","section":"Tags","summary":"","title":"Business Model Canvas","type":"tags"},{"content":"","date":"8 August 2021","externalUrl":null,"permalink":"/en/tags/lean-ux/","section":"Tags","summary":"","title":"Lean UX","type":"tags"},{"content":"Collaborate \u0026amp; Research ist der zweite Schritt im SAFe DevOps Health Radar. In diesem Video erkläre ich, wie Teams intern zusammenarbeiten und Marktforschung betreiben, um ein minimales Feature-Set zu definieren, das die Hypothese aus dem vorherigen Schritt validiert.\nWarum Collaborate \u0026amp; Research? # Die grundlegende Frage hinter diesem Schritt ist einfach: Wissen Sie, ob Ihre Idee oder Hypothese tatsächlich ein echtes Kundenbedürfnis löst? Woher wissen Sie das? Und was ist der schnellste Weg, diese Hypothese zu validieren? Collaborate \u0026amp; Research existiert, um diese Fragen zu beantworten, bevor man erheblichen Aufwand in den Bau von etwas investiert, das möglicherweise keinen Wert liefert.\nDer Lean UX Prozess # Collaborate \u0026amp; Research folgt dem Lean UX Prozess. Ausgehend vom Epic und dessen Hypothese (erstellt im Hypothesize-Schritt) identifizieren wir das Feature, das diese Hypothese validieren kann. Aus diesem Feature leiten wir eine Benefit-Hypothese ab. Zusammen mit UX-Experten erstellen wir dann ein kollaboratives Design für dieses Feature und bauen ein MMF (Minimal Marketable Feature). Das MMF ist das kleinstmögliche Inkrement, mit dem wir die Benefit-Hypothese evaluieren können und das gleichzeitig bereits Kundenwert liefert.\nKundenbedürfnisse erforschen # Das Verstehen dessen, was Kunden wirklich brauchen, steht im Zentrum dieses Schritts. Wir verwenden verschiedene Techniken, um dieses Verständnis aufzubauen:\nPersonas: Wir erstellen detaillierte Repräsentationen unserer Zielgruppen. Jede Persona bekommt einen Namen, ein Foto, Fähigkeiten, Ängste und eine ausführliche Beschreibung, damit jeder im Team die gleiche Sicht auf die Zielgruppe hat. Customer Journey Maps: Diese Maps zeigen den End-to-End-Prozess, den ein Kunde bei der Nutzung unseres Produkts durchläuft. Sie zeigen die Höhen und Tiefen, die Berührungspunkte und die Interaktionen mit unserem Produkt über alle Phasen hinweg. Kundeninterviews: Wir besuchen echte Kunden und führen Interviews durch, um ihre Bedürfnisse und die Probleme zu identifizieren, die wir gemeinsam lösen müssen. Umfragen und Marktforschung: Wir erstellen Umfragen und erforschen den breiteren Markt, um Marktbedürfnisse jenseits des individuellen Kundenfeedbacks zu identifizieren. Das Business Model Canvas # Sobald wir die Kundenbedürfnisse identifiziert haben, können wir das Business Model Canvas erstellen oder aktualisieren (ein Tool von Strategyzer). Das Canvas hilft uns bei der Definition von:\nDer Value Proposition, die wir unseren Kunden bieten Den Kundensegmenten, die wir bedienen Den Kanälen, über die wir mit unseren Kunden kommunizieren Den Schlüsselaktivitäten, die zur Wertlieferung erforderlich sind Den benötigten Ressourcen Der Kostenstruktur unseres Geschäftsmodells Das Value Proposition Canvas # Als Teil des Business Model Canvas arbeiten wir auch am Value Proposition Canvas. Auf der Kundenseite dokumentieren wir die Jobs, Gains und Pains des Kunden. Auf der Produktseite identifizieren wir unsere Produkte und Dienstleistungen, die Gain Creators und die Pain Relievers. Das gibt uns ein sehr klares Bild davon, welchen Wert wir liefern und wie unsere Lösung die tatsächlichen Probleme des Kunden adressiert.\nWas Collaborate \u0026amp; Research produziert # Nach Abschluss dieses Schritts haben wir:\nIdentifizierte Kundenbedürfnisse und die Probleme, die wir lösen wollen Style Guides, die in den nachfolgenden Prozessschritten verwendet werden können Logos und UI Assets für die Lösung Prototypen oder Mockups, die die Lösung visualisieren Personas und Customer Journey Maps, die unser Verständnis der Zielgruppe dokumentieren Die Reifegrade # Der SAFe DevOps Health Radar enthält eine Reifegradbeurteilung für Collaborate \u0026amp; Research. Sie bewerten die Fähigkeit Ihres Teams, mit Kundenexperten und IT-Experten zusammenzuarbeiten, um ein Minimal Marketable Feature zur Unterstützung der Hypothese zu definieren:\nSit: Rollen und Verantwortlichkeiten des Product Managements sind nicht definiert oder werden nicht befolgt. Crawl: Das Product Management erstellt Anforderungen in grossen Paketen mit wenig Kunden- oder Entwicklungszusammenarbeit. Walk: Das Product Management arbeitet mit Business- und Entwicklungsexperten zusammen, aber nicht mit beiden gleichzeitig bei der Definition von Anforderungen. Run: Das Product Management arbeitet regelmässig mit Business-, Entwicklungs- und Operations-Experten zusammen, definiert aber kein Minimal Marketable Feature. Fly: Das Product Management arbeitet immer mit Business-, Entwicklungs- und Operations-Experten zusammen und definiert Minimal Marketable Features. Kernaussagen # Validieren vor dem Bauen. Collaborate \u0026amp; Research stellt sicher, dass Ihre Hypothese tatsächlich ein echtes Kundenbedürfnis adressiert, bevor Sie in die Entwicklung investieren. Den Lean UX Prozess anwenden. Vom Epic zum Feature zur Benefit-Hypothese zum kollaborativen Design zum MMF. Jeder Schritt schärft Ihr Verständnis. Personas und Journey Maps erstellen. Diese Werkzeuge geben dem gesamten Team ein gemeinsames Verständnis davon, wer Ihre Kunden sind und wie sie mit Ihrem Produkt interagieren. Das Business Model Canvas nutzen. Es bietet eine strukturierte Sicht auf Value Proposition, Kundensegmente, Kanäle, Aktivitäten, Ressourcen und Kostenstruktur. Das Kleinste bauen, das Wert liefert. Das Minimal Marketable Feature ist der schnellste Weg, Ihre Hypothese zu validieren und gleichzeitig etwas Nützliches für den Kunden bereitzustellen. Kontinuierliche Zusammenarbeit anstreben. Der höchste Reifegrad erfordert, dass das Product Management immer mit Business-, Entwicklungs- und Operations-Experten zusammenarbeitet. ","date":"8. August 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-collaborate-and-research-safe-devops-health-radar/","section":"Blogs","summary":"Collaborate \u0026 Research ist der zweite Schritt im SAFe DevOps Health Radar. In diesem Video erkläre ich, wie Teams intern zusammenarbeiten und Marktforschung betreiben, um ein minimales Feature-Set zu definieren, das die Hypothese aus dem vorherigen Schritt validiert.\n","title":"Was ist Collaborate \u0026 Research? | SAFe DevOps Health Radar","type":"blogs"},{"content":"Collaborate \u0026amp; Research is the second step in the SAFe DevOps Health Radar. In this video, I explain how teams collaborate internally and conduct market research to define a minimal feature set that validates the hypothesis from the previous step.\nWhy Collaborate \u0026amp; Research? # The fundamental question behind this step is simple: do you know whether your idea or hypothesis actually solves a real customer need? How do you know? And what is the fastest way to validate that hypothesis? Collaborate \u0026amp; Research exists to answer these questions before investing significant effort into building something that may not deliver value.\nThe Lean UX Process # Collaborate \u0026amp; Research follows the Lean UX process. Starting from the epic and its hypothesis statement (created in the Hypothesize step), we identify the feature that can validate this hypothesis. From that feature, we derive a benefit hypothesis. Together with UX experts, we then create a collaborative design for this feature and build an MMF (Minimal Marketable Feature). The MMF is the smallest possible increment that allows us to evaluate the benefit hypothesis while already delivering customer value.\nResearching Customer Needs # Understanding what customers actually need is central to this step. We use several techniques to build that understanding:\nPersonas: We create detailed representations of our target audiences. Each persona gets a name, a photo, skills, fears, and a thorough description so that everyone on the team shares the same view of the target audience. Customer Journey Maps: These maps show the end-to-end process a customer goes through when using our product. They reveal the ups and downs, the touchpoints, and the interactions with our product across all stages. Customer Interviews: We visit real customers and conduct interviews to identify their needs and the problems we need to solve together with them. Surveys and Market Research: We create surveys and research the broader market to identify market needs beyond individual customer feedback. The Business Model Canvas # Once we have identified the customer needs, we can create or update the Business Model Canvas (a tool by Strategyzer). The canvas helps us define:\nThe value proposition we bring to our customers The customer segments we serve The channels through which we communicate with our customers The key activities required to deliver value The resources needed The cost structure of our business model The Value Proposition Canvas # As part of the Business Model Canvas, we also work on the Value Proposition Canvas. On the customer side, we document the customer\u0026rsquo;s jobs, gains, and pains. On the product side, we identify our products and services, the gain creators, and the pain relievers. This gives us a very clear picture of what value we deliver and how our solution addresses the customer\u0026rsquo;s actual problems.\nWhat Collaborate \u0026amp; Research Produces # After completing this step, we have:\nIdentified customer needs and the problems we want to solve Style guides that can be used in subsequent process steps Logos and UI assets for the solution Prototypes or mockups that visualize the solution Personas and customer journey maps that document our understanding of the target audience The Maturity Levels # The SAFe DevOps Health Radar includes a maturity assessment for Collaborate \u0026amp; Research. You rate your team\u0026rsquo;s ability to collaborate with customer experts and IT experts to define a Minimal Marketable Feature in support of the hypothesis:\nSit: Product management roles and responsibilities are not defined or followed. Crawl: Product management creates requirements in large batches with little customer or development collaboration. Walk: Product management collaborates with business side and development side experts, but not both when defining requirements. Run: Product management regularly collaborates with business side, development side, and operation side experts but does not define a Minimal Marketable Feature. Fly: Product management always collaborates with business side, development side, and operation side experts and defines Minimal Marketable Features. Key Takeaways # Validate before you build. Collaborate \u0026amp; Research ensures your hypothesis actually addresses a real customer need before you invest in development. Apply the Lean UX process. Move from epic to feature to benefit hypothesis to collaborative design to MMF. Each step sharpens your understanding. Create personas and journey maps. These tools give the entire team a shared understanding of who your customers are and how they interact with your product. Use the Business Model Canvas. It provides a structured view of your value proposition, customer segments, channels, activities, resources, and cost structure. Build the smallest thing that delivers value. The Minimal Marketable Feature is the fastest way to validate your hypothesis while already providing something useful to the customer. Strive for continuous collaboration. The highest maturity level requires product management to always work with business, development, and operations experts together. ","date":"8 August 2021","externalUrl":null,"permalink":"/en/blogs/what-is-collaborate-and-research-safe-devops-health-radar/","section":"Blogs","summary":"Collaborate \u0026 Research is the second step in the SAFe DevOps Health Radar. In this video, I explain how teams collaborate internally and conduct market research to define a minimal feature set that validates the hypothesis from the previous step.\n","title":"What is Collaborate \u0026 Research? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In diesem Video gehe ich im Detail auf Hypothesize ein, den ersten Prozessschritt des SAFe DevOps Health Radar und der Continuous Delivery Pipeline. Die zentrale Frage ist einfach: Woher wissen wir, dass wir das Richtige bauen?\nDer SAFe DevOps Health Radar als Prozess # Der SAFe DevOps Health Radar ist nicht nur ein Assessment-Tool. Er ist auch ein Prozess, der beim Kunden beginnt und beim Kunden endet. Der Prozess umfasst die vier Dimensionen der Continuous Delivery Pipeline: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Hypothesize ist der allererste Schritt in dieser Pipeline.\nWarum Epics und nicht Projekte # Ein zentrales Konzept im Hypothesize-Schritt ist das Epic. Ein Epic unterscheidet sich grundlegend von einem Projekt:\nEpic: Ein Container für eine bedeutende Initiative. Man definiert eine Hypothese dahinter und baut dann ein MVP, um diese Hypothese zu validieren. Projekt: Hat einen klaren Start und ein klares Ende, ein festes Budget, einen Zeitplan und einen definierten Satz an Anforderungen oder Aufgaben. Das Problem mit Projekten ist, dass sie davon ausgehen, man wisse bereits, was gebaut werden soll. Epics hingegen akzeptieren Unsicherheit und bieten einen Mechanismus, um zu testen, ob eine Idee tatsächlich Wert liefert, bevor man sich auf eine vollständige Umsetzung festlegt.\nDas Epic Hypothesis Statement # Um ein Epic sauber zu definieren, erstellt man ein Epic Hypothesis Statement. Dieses Dokument beschreibt:\nDen Kunden: Für wen bauen wir das? (Interne oder externe Kunden) Das Problem: Was möchte der Kunde tun? Die Lösung: Was werden wir bauen? Das Business Outcome: Was wollen wir wirklich erreichen? Die Leading Indicators: Wie messen wir den Erfolg frühzeitig? Die Non-Functional Requirements: Welche Rahmenbedingungen gelten? Die Erstellung dieses Statements dauert etwa ein bis zwei Stunden. Es zwingt das Team, klar darüber nachzudenken, was es erreichen will, bevor eine einzige Zeile Code geschrieben wird.\nDer Lean Business Case # Nach dem Epic Hypothesis Statement folgt der Lean Business Case. Das ist ein zweiseitiges Dokument, das definiert:\nWas das MVP ist und wie die vollständige Lösung aussehen könnte Was das MVP kosten wird und was die vollständige Umsetzung kosten wird Die Erstellung des Lean Business Case dauert etwa zwei bis vier Stunden. Er liefert gerade genug Information für eine gute Investitionsentscheidung, ohne monatelange Vorausplanung.\nDer Lean Startup Cycle # Mit dem definierten MVP treten Teams in den Lean Startup Cycle ein:\nBuild: Das MVP bauen Evaluate: Die Hypothese anhand der Leading Indicators bewerten Decide: Wenn die Hypothese bestätigt wird, mehr investieren und weitere Features bauen. Wenn sie widerlegt wird, einen Pivot machen. Das bedeutet entweder, komplett aufzuhören, oder ein neues Epic mit einer neuen Hypothese zu erstellen und den Zyklus erneut zu durchlaufen. Leading Indicators und Vanity Metrics # Leading Indicators sind Metriken, die frühzeitig messen, ob man das Richtige baut und ob es die gewünschte Wirkung hat. Sie müssen schnell messbar sein, nicht erst in sechs Monaten oder einem Jahr.\nVorsicht bei Vanity Metrics. Das sind Metriken, die beeindruckend aussehen, aber den tatsächlichen Business-Wert nicht wirklich messen. Beispiele sind die Anzahl der Downloads oder die Anzahl der Nutzer. Diese Zahlen können steigen, während der eigentliche Geschäftswert stagniert. Vanity Metrics können sich zudem je nach Kontext verändern. Daher sollte man immer prüfen, was eine Metrik wirklich aussagt.\nDie Reifegrade # Der SAFe DevOps Health Radar bietet ein Self-Assessment für Hypothesize mit fünf Reifegraden:\nSit: Ideen sind nur vage und nicht definiert. Crawl: Ideen sind definiert (zum Beispiel als Epic), enthalten aber kein Hypothesis Statement. Walk: Einige Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert. Run: Die meisten Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert und beinhalten MVPs. Fly: Alle Ideen sind als Hypothesis Statements mit messbaren Ergebnissen formuliert und beinhalten MVPs. Kernaussagen # Validieren vor dem Bauen. Der Zweck von Hypothesize ist sicherzustellen, dass man das Richtige baut, indem man eine Hypothese definiert und testet, bevor Ressourcen eingesetzt werden. Epics statt Projekte verwenden. Epics akzeptieren Unsicherheit und ermöglichen die Validierung von Ideen durch MVPs. Projekte setzen voraus, dass man die Antwort bereits kennt. Das Epic Hypothesis Statement ist schnell erstellt. In ein bis zwei Stunden definiert man Kunde, Problem, Lösung, Business Outcome und Leading Indicators. Leading Indicators messen frühzeitig den Erfolg. Sie zeigen schnell, ob die Hypothese stimmt, sodass man investieren oder pivotieren kann, ohne Monate zu verlieren. Vorsicht vor Vanity Metrics. Metriken wie Download-Zahlen können gut aussehen, ohne den tatsächlichen Geschäftswert widerzuspiegeln. Immer prüfen, was eine Metrik wirklich misst. Reifegrade von Sit bis Fly. Teams können sich selbst bewerten und ein klares Ziel setzen, wie konsequent sie ihre Ideen validieren wollen. ","date":"2. August 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-hypothesize-safe-devops-health-radar/","section":"Blogs","summary":"In diesem Video gehe ich im Detail auf Hypothesize ein, den ersten Prozessschritt des SAFe DevOps Health Radar und der Continuous Delivery Pipeline. Die zentrale Frage ist einfach: Woher wissen wir, dass wir das Richtige bauen?\n","title":"Was ist Hypothesize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"In this video, I take a deep dive into Hypothesize, the first process step of the SAFe DevOps Health Radar and the continuous delivery pipeline. The core question is simple: how do you know you are building the right thing?\nThe SAFe DevOps Health Radar as a Process # The SAFe DevOps Health Radar is not just an assessment tool. It is also a process that starts with the customer and ends with the customer. The process covers the four dimensions of the continuous delivery pipeline: continuous exploration, continuous integration, continuous deployment, and release on demand. Hypothesize is the very first step in this pipeline.\nWhy Epics, Not Projects # A central concept in the Hypothesize step is the epic. An epic is different from a project in a fundamental way:\nEpic: A container for a significant initiative. You define a hypothesis behind it and then build an MVP to validate that hypothesis. Project: Has a clear start and end, a fixed budget, a timeline, and a defined set of requirements or tasks. The problem with projects is that they assume you already know what to build. Epics, on the other hand, acknowledge uncertainty and provide a mechanism to test whether an idea actually delivers value before committing to a full implementation.\nThe Epic Hypothesis Statement # To define an epic properly, you create an Epic Hypothesis Statement. This document describes:\nThe customer: Who are you building this for? (Internal or external customers) The problem: What does the customer want to do? The solution: What are you going to build? The business outcome: What do you really want to achieve? The leading indicators: How will you measure success early? The non-functional requirements: What constraints apply? Creating this statement takes roughly one to two hours. It forces the team to think clearly about what they are trying to achieve before writing a single line of code.\nThe Lean Business Case # After the Epic Hypothesis Statement, the next step is a Lean Business Case. This is a two-page document that defines:\nWhat the MVP is and what the full solution might look like What the MVP will cost and what the full implementation will cost Creating the Lean Business Case takes roughly two to four hours. It provides just enough information to make a good investment decision without months of upfront planning.\nThe Lean Startup Cycle # With the MVP defined, teams enter the Lean Startup Cycle:\nBuild the MVP Evaluate the hypothesis using the leading indicators Decide: If the hypothesis is proven, invest more and build additional features. If it is disproven, pivot. That means either stopping completely or creating a new epic with a new hypothesis and going through the cycle again. Leading Indicators and Vanity Metrics # Leading indicators are metrics that measure early whether you are building the right thing and whether it has the desired impact. They need to be measurable quickly, not in six months or a year.\nBe careful with vanity metrics. These are metrics that look impressive but do not truly measure the real business outcome. Examples include number of downloads or number of users. These numbers can go up while the actual business value remains flat. Vanity metrics can also shift from context to context, so always evaluate what a metric truly tells you.\nThe Maturity Levels # The SAFe DevOps Health Radar provides a self-assessment for Hypothesize with five maturity levels:\nSit: Ideas are only vague and not defined. Crawl: Ideas are defined (for example as an epic) but do not include a hypothesis statement. Walk: Some ideas are expressed as hypothesis statements with measurable outcomes. Run: Most ideas are expressed as hypothesis statements with measurable outcomes and include MVPs. Fly: All ideas are expressed as hypothesis statements with measurable outcomes and include MVPs. Key Takeaways # Validate before you build. The purpose of Hypothesize is to ensure you are building the right thing by defining and testing a hypothesis before committing resources. Use epics, not projects. Epics embrace uncertainty and let you validate ideas through MVPs. Projects assume you already know the answer. The Epic Hypothesis Statement is quick to create. In one to two hours, you define the customer, problem, solution, business outcome, and leading indicators. Leading indicators measure early success. They tell you quickly whether your hypothesis holds, so you can invest or pivot without wasting months. Watch out for vanity metrics. Metrics like download numbers can look good without reflecting actual business value. Always check what a metric truly measures. Maturity ranges from Sit to Fly. Teams can assess themselves and set a clear target for how rigorously they want to validate ideas. ","date":"2 August 2021","externalUrl":null,"permalink":"/en/blogs/what-is-hypothesize-safe-devops-health-radar/","section":"Blogs","summary":"In this video, I take a deep dive into Hypothesize, the first process step of the SAFe DevOps Health Radar and the continuous delivery pipeline. The core question is simple: how do you know you are building the right thing?\n","title":"What is Hypothesize? | SAFe DevOps Health Radar","type":"blogs"},{"content":"How can innovation and development budgets be distributed faster, more transparently, and more effectively? Participatory Budgeting offers a collaborative approach to steering investments not project-by-project, but along value streams and strategic priorities.\nWhat This Talk Covers # Using a concrete practical example from Zühlke, this talk shows how a market portfolio can be jointly prioritized using clear budget frameworks, epic pitches, and moderated decision rounds.\nKey Messages # 1. From Project Budgets to Value Stream Funding Traditional project-by-project funding is slow and inflexible. Participatory Budgeting steers investments along value streams and strategic priorities for faster, more effective allocation.\n2. Transparency and Commitment The approach creates transparency, increases stakeholder commitment, and supports agile, adaptive budget steering. Everyone involved understands why decisions are made.\n3. Success Factors The success of participatory budgeting depends strongly on good preparation, clear information, and professional moderation. Without these foundations, the approach falls short.\n","date":"29 June 2021","externalUrl":null,"permalink":"/en/speaking/participatory-budgeting/","section":"Speaking","summary":"How can innovation and development budgets be distributed faster, more transparently, and more effectively? Participatory Budgeting offers a collaborative approach to steering investments not project-by-project, but along value streams and strategic priorities.\n","title":"Participatory Budgeting: Funding in the 21st Century","type":"speaking"},{"content":"In this meetup talk, Nadine Broghammer and I share our experience coaching a portfolio team on participatory budgeting based on the SAFe framework. We explain the problem with traditional top-down budget allocation and show how participatory budgeting creates transparency, fosters entrepreneurial thinking, and leads to better investment decisions.\nThe Problem with Traditional Budgeting # In many organizations, the budget process works the same way every year. Teams submit their project proposals, and a committee without deep domain knowledge reviews them. The budget is never enough to fund everything, so the committee divides the total by some arbitrary number and distributes it with a watering can approach. Some teams get more because someone on the committee knows them personally. Nobody is satisfied with the result.\nThis was exactly the situation we faced. A \u0026ldquo;fruit committee\u0026rdquo; (we anonymized all examples using fruits as stand-ins for real offerings) was responsible for allocating budgets to teams producing \u0026ldquo;apples,\u0026rdquo; \u0026ldquo;bananas,\u0026rdquo; \u0026ldquo;lemons,\u0026rdquo; and other products. The committee lacked the knowledge to evaluate proposals like \u0026ldquo;molecular apples\u0026rdquo; or \u0026ldquo;blue bananas\u0026rdquo; and simply spread the budget evenly. The result was widespread frustration.\nThe SAFe Portfolio Level # To solve this, we turned to the portfolio level of the Scaled Agile Framework (SAFe). A portfolio manages one or more value streams that deliver solutions end to end. Instead of organizing around projects, we organized around value streams, each responsible for delivering a specific type of value to the market.\nThe key shift is moving from project funding to value stream funding. Instead of approving individual projects, the portfolio allocates budget to value streams. Each value stream then decides autonomously how to invest its budget according to the strategic objectives and OKRs of the organization.\nEpics Instead of Projects # A core element of this approach is replacing projects with epics. An epic is a significant initiative, but unlike a project with fixed deliverables and a fixed budget, an epic is built around a hypothesis statement:\nFor whom are we doing this? What problem are we solving? What business outcome do we want to achieve? What leading indicators will tell us whether our hypothesis is validated? This means we can validate an epic very quickly using leading indicators rather than waiting for lagging indicators that arrive too late. The epic hypothesis statement ensures we know we are delivering the right thing and that customers actually need it.\nPreparing for the Event # The participatory budgeting process has three main steps: preparation, assembling the right participants, and conducting the event itself.\nFor preparation, we ran an introduction session where we explained the concept and the theory to all participants. The value stream leads then had approximately two weeks to prepare their epics using the SAFe epic template. We split the process into run-the-business (ongoing activities that cannot be interrupted) and grow-the-business (new initiatives).\nAs coaches, we also prepared extensively. We adapted the SAFe Excel template to fit our specific case and ran a simulation beforehand to make sure everything would work smoothly during the actual event.\nThe Participatory Budgeting Event # The event itself took about three hours. We split the participants into two groups, each with a coach (Nadine and I each moderated one table). The process worked in two rounds:\nRound 1 (Run-the-Business): Each value stream pitched their ongoing activities to the group. Both groups then independently discussed and allocated the full portfolio budget across all value streams. Importantly, each group allocated budget to all value streams, including those not represented at their table.\nRound 2 (Grow-the-Business): The remaining budget after run-the-business was available for new initiatives. Value stream leads pitched their epics. The group discussions were intense, time was scarce, and the decisions were tough. Both groups proposed their budget allocations, and in the final plenary, everyone worked towards a consensus.\nWe had a Plan B ready in case no agreement could be reached: the fruit committee would make the final decision. Fortunately, we never needed it. The teams reached consensus, and we could communicate the final budget distribution the very next day.\nWhat We Learned # The feedback from participants highlighted several key themes:\nTransparency: The biggest benefit. Everyone now understood why certain value streams received more or less budget. The old process was opaque; the new process was fully visible. Cross-value-stream learning: The discussions were extremely valuable. Value stream leads learned about each other\u0026rsquo;s plans, the company strategy, and which epics aligned with the strategic objectives. Efficient process: Despite the tight schedule, participants found the process fast and effective. For the next round, we would allocate a bit more time, since this first attempt was itself a hypothesis we wanted to validate quickly. Entrepreneurial thinking: The most remarkable outcome. Participants voluntarily reduced their own budgets, saying things like \u0026ldquo;I do not need that much money. It is better to invest in apples because that benefits the whole portfolio.\u0026rdquo; This cross-silo, company-first thinking was exactly what we hoped to achieve. Bottom-up decision making: Participants appreciated that the decision was no longer top-down. They were enabled to make investment decisions themselves, which led to much stronger engagement and ownership. The overall participant rating was 3.5 out of 5, with no score below 3. For a first attempt, this was a strong result.\nPractical Tips # Do not underestimate preparation. The epic templates need time, and the coaching of individual value streams is essential. Run a simulation first. We tested the entire process with sample numbers before the real event. This gave us confidence that everything would work. Moderation matters. You need strong facilitation skills to keep discussions focused and help groups reach decisions within tight timescales. Work in pairs. Do not run a participatory budgeting event alone. Having two coaches, one per discussion table, made a significant difference. Consider splitting the event. Participants suggested holding the epic pitches in a separate alignment meeting before the budgeting event, giving people more time to absorb the information. Key Takeaways # Participatory budgeting replaces top-down allocation. Instead of a committee distributing budgets without domain knowledge, the people closest to the work make the investment decisions together. Value stream funding over project funding. Organizing around value streams and using epic hypotheses ensures money flows to validated ideas rather than fixed project plans. Transparency creates trust. When everyone sees why budgets are allocated the way they are, frustration decreases and buy-in increases. Entrepreneurial thinking emerges naturally. When people have budget responsibility, they think beyond their silo and invest where the portfolio benefits most. Start with a hypothesis. Our first participatory budgeting event was itself a hypothesis. We kept the time investment small, validated the approach, and will invest more in the next iteration. Preparation and facilitation are critical. Good templates, a simulation run, strong moderation, and working in pairs are essential for a successful event. ","date":"9 June 2021","externalUrl":null,"permalink":"/en/blogs/participatory-budgeting-financing-in-the-21st-century/","section":"Blogs","summary":"In this meetup talk, Nadine Broghammer and I share our experience coaching a portfolio team on participatory budgeting based on the SAFe framework. We explain the problem with traditional top-down budget allocation and show how participatory budgeting creates transparency, fosters entrepreneurial thinking, and leads to better investment decisions.\n","title":"Participatory Budgeting: Financing in the 21st Century","type":"blogs"},{"content":"In diesem Meetup-Vortrag teilen Nadine Broghammer und ich unsere Erfahrungen beim Coaching eines Portfolio-Teams für partizipatives Budgetieren basierend auf dem SAFe-Framework. Wir erklären das Problem der traditionellen Top-down-Budgetverteilung und zeigen, wie partizipatives Budgetieren Transparenz schafft, unternehmerisches Denken fördert und zu besseren Investitionsentscheidungen führt.\nDas Problem mit traditioneller Budgetierung # In vielen Organisationen funktioniert der Budgetprozess jedes Jahr gleich. Teams reichen ihre Projektvorschläge ein, und ein Gremium ohne tiefes Fachwissen prüft sie. Das Budget reicht nie für alles, also teilt das Gremium den Gesamtbetrag durch eine beliebige Zahl und verteilt ihn nach dem Giesskannenprinzip. Manche Teams bekommen mehr, weil jemand im Gremium sie persönlich kennt. Niemand ist mit dem Ergebnis zufrieden.\nGenau diese Situation hatten wir. Ein \u0026ldquo;Früchte-Komitee\u0026rdquo; (wir haben alle Beispiele mit Früchten anonymisiert) war für die Budgetverteilung an Teams zuständig, die \u0026ldquo;Äpfel,\u0026rdquo; \u0026ldquo;Bananen,\u0026rdquo; \u0026ldquo;Zitronen\u0026rdquo; und andere Produkte herstellen. Das Komitee hatte nicht das nötige Wissen, um Vorschläge wie \u0026ldquo;Molekular-Äpfel\u0026rdquo; oder \u0026ldquo;blaue Bananen\u0026rdquo; zu beurteilen, und verteilte das Budget einfach gleichmässig. Das Ergebnis war grosse Unzufriedenheit.\nDie SAFe Portfolio-Ebene # Um dieses Problem zu lösen, wandten wir uns der Portfolio-Ebene des Scaled Agile Frameworks (SAFe) zu. Ein Portfolio verwaltet einen oder mehrere Wertströme (Value Streams), die Lösungen end-to-end liefern. Statt uns um Projekte zu organisieren, organisierten wir uns um Wertströme, die jeweils für eine bestimmte Art von Wertlieferung an den Markt verantwortlich sind.\nDer entscheidende Wandel ist der Übergang von Projektfinanzierung zu Wertstrom-Finanzierung. Statt einzelne Projekte zu genehmigen, weist das Portfolio den Wertströmen Budget zu. Jeder Wertstrom entscheidet dann autonom, wie er sein Budget entsprechend den strategischen Zielen und OKRs der Organisation einsetzt.\nEpics statt Projekte # Ein Kernelement dieses Ansatzes ist die Ablösung von Projekten durch Epics. Ein Epic ist eine signifikante Initiative, aber im Gegensatz zu einem Projekt mit fixen Lieferungen und fixem Budget baut ein Epic auf einem Hypothesen-Statement auf:\nFür wen machen wir das? Welches Problem lösen wir? Welchen Business-Outcome wollen wir erzielen? Welche Leading Indicators zeigen uns, ob unsere Hypothese validiert wird? Das bedeutet, wir können ein Epic sehr schnell mit Leading Indicators validieren, anstatt auf Lagging Indicators zu warten, die zu spät kommen. Das Epic-Hypothesen-Statement stellt sicher, dass wir das Richtige liefern und dass die Kunden es wirklich brauchen.\nVorbereitung auf das Event # Der partizipative Budgetprozess hat drei Hauptschritte: Vorbereitung, die richtigen Teilnehmenden zusammenbringen und das Event selbst durchführen.\nZur Vorbereitung führten wir eine Introduction Session durch, in der wir allen Teilnehmenden das Konzept und die Theorie erklärten. Die Value-Stream-Leads hatten dann etwa zwei Wochen Zeit, ihre Epics mit dem SAFe-Epic-Template vorzubereiten. Wir teilten den Prozess in Run-the-Business (laufende Aktivitäten, die nicht unterbrochen werden können) und Grow-the-Business (neue Initiativen) auf.\nAls Coaches bereiteten auch wir uns intensiv vor. Wir passten das SAFe-Excel-Template an unseren spezifischen Fall an und führten vorab eine Simulation durch, um sicherzustellen, dass am eigentlichen Event alles reibungslos funktioniert.\nDas Participatory Budgeting Event # Das Event selbst dauerte rund drei Stunden. Wir teilten die Teilnehmenden in zwei Gruppen auf, jede mit einem Coach (Nadine und ich moderierten je einen Tisch). Der Prozess lief in zwei Runden ab:\nRunde 1 (Run-the-Business): Jeder Wertstrom pitchte seine laufenden Aktivitäten vor der Gruppe. Beide Gruppen diskutierten dann unabhängig voneinander und verteilten das gesamte Portfolio-Budget auf alle Wertströme. Wichtig: Jede Gruppe verteilte Budget an alle Wertströme, auch an jene, die nicht am eigenen Tisch vertreten waren.\nRunde 2 (Grow-the-Business): Das verbleibende Budget nach Run-the-Business stand für neue Initiativen zur Verfügung. Die Value-Stream-Leads pitchten ihre Epics. Die Gruppendiskussionen waren intensiv, die Zeit knapp und die Entscheidungen hart. Beide Gruppen schlugen ihre Budgetverteilungen vor, und im finalen Plenum arbeiteten alle an einem Konsens.\nWir hatten einen Plan B bereit für den Fall, dass keine Einigung erzielt werden konnte: Das Früchte-Komitee hätte die finale Entscheidung getroffen. Glücklicherweise brauchten wir ihn nie. Die Teams erreichten einen Konsens, und wir konnten die finale Budgetverteilung bereits am nächsten Tag kommunizieren.\nWas wir gelernt haben # Das Feedback der Teilnehmenden hob mehrere zentrale Themen hervor:\nTransparenz: Der grösste Vorteil. Alle verstanden nun, warum bestimmte Wertströme mehr oder weniger Budget erhielten. Der alte Prozess war undurchsichtig, der neue Prozess war vollständig transparent. Lernen über Wertströme hinweg: Die Diskussionen waren extrem wertvoll. Value-Stream-Leads erfuhren von den Plänen der anderen, der Unternehmensstrategie und welche Epics auf die strategischen Ziele einzahlten. Effizienter Prozess: Trotz des straffen Zeitplans empfanden die Teilnehmenden den Prozess als schnell und effektiv. Für die nächste Runde würden wir etwas mehr Zeit einplanen, da dieser erste Versuch selbst eine Hypothese war, die wir schnell validieren wollten. Unternehmerisches Denken: Das bemerkenswerteste Ergebnis. Teilnehmende reduzierten freiwillig ihre eigenen Budgets mit Aussagen wie \u0026ldquo;Ich brauche nicht so viel Geld. Es ist besser, in Äpfel zu investieren, weil das dem gesamten Portfolio mehr bringt.\u0026rdquo; Dieses siloübergreifende, unternehmensbezogene Denken war genau das, was wir erhofft hatten. Bottom-up-Entscheidungsfindung: Teilnehmende schätzten, dass die Entscheidung nicht mehr top-down war. Sie wurden befähigt, Investitionsentscheidungen selbst zu treffen, was zu deutlich stärkerem Engagement und Ownership führte. Die Gesamtbewertung der Teilnehmenden lag bei 3,5 von 5, ohne eine einzige Bewertung unter 3. Für einen ersten Versuch war das ein starkes Ergebnis.\nPraktische Tipps # Unterschätzt die Vorbereitung nicht. Die Epic-Templates brauchen Zeit, und das Coaching einzelner Wertströme ist essenziell. Führt zuerst eine Simulation durch. Wir haben den gesamten Prozess mit Beispielzahlen vorab getestet. Das gab uns die Sicherheit, dass alles funktioniert. Moderation ist entscheidend. Man braucht starke Moderationsfähigkeiten, um Diskussionen fokussiert zu halten und Gruppen innerhalb enger Zeitrahmen zu Entscheidungen zu führen. Arbeitet zu zweit. Führt ein partizipatives Budgeting-Event nicht alleine durch. Zwei Coaches, einer pro Diskussionstisch, machten einen grossen Unterschied. Erwägt eine Aufteilung des Events. Teilnehmende schlugen vor, die Epic-Pitches in einem separaten Alignment-Meeting vor dem Budgeting-Event zu halten, damit alle mehr Zeit haben, die Informationen aufzunehmen. Kernaussagen # Partizipatives Budgetieren ersetzt Top-down-Verteilung. Statt dass ein Gremium Budgets ohne Fachwissen verteilt, treffen die Menschen, die der Arbeit am nächsten sind, gemeinsam die Investitionsentscheidungen. Wertstrom-Finanzierung statt Projektfinanzierung. Die Organisation um Wertströme und die Verwendung von Epic-Hypothesen stellt sicher, dass Geld in validierte Ideen fliesst statt in fixe Projektpläne. Transparenz schafft Vertrauen. Wenn alle sehen, warum Budgets so verteilt werden, wie sie verteilt werden, nimmt Frustration ab und Akzeptanz zu. Unternehmerisches Denken entsteht natürlich. Wenn Menschen Budgetverantwortung haben, denken sie über ihr Silo hinaus und investieren dort, wo das Portfolio am meisten profitiert. Startet mit einer Hypothese. Unser erstes partizipatives Budgeting-Event war selbst eine Hypothese. Wir hielten den Zeitaufwand klein, validierten den Ansatz und werden in der nächsten Iteration mehr investieren. Vorbereitung und Moderation sind entscheidend. Gute Templates, ein Simulationslauf, starke Moderation und Teamarbeit sind essenziell für ein erfolgreiches Event. ","date":"9. June 2021","externalUrl":null,"permalink":"/de/blogs/participatory-budgeting-finanzierung-im-21-jahrhundert/","section":"Blogs","summary":"In diesem Meetup-Vortrag teilen Nadine Broghammer und ich unsere Erfahrungen beim Coaching eines Portfolio-Teams für partizipatives Budgetieren basierend auf dem SAFe-Framework. Wir erklären das Problem der traditionellen Top-down-Budgetverteilung und zeigen, wie partizipatives Budgetieren Transparenz schafft, unternehmerisches Denken fördert und zu besseren Investitionsentscheidungen führt.\n","title":"Participatory Budgeting: Finanzierung im 21. Jahrhundert","type":"blogs"},{"content":"In diesem Video erkläre ich, worum es beim SAFe for DevOps Training geht. Im Gegensatz zu klassischen Schulungen ist dieses Training ein praxisnaher Workshop, in dem echte Teams an ihren eigenen Value Streams arbeiten und mit einem konkreten, priorisierten Aktionsplan nach Hause gehen.\nMehr Workshop als Training # Das SAFe for DevOps Training ist eher ein Workshop oder ein Assessment als ein klassischer Kurs. Teams kommen mit ihren echten Herausforderungen und Fragen rund um DevOps. Gemeinsam arbeiten wir einen strukturierten Prozess durch, der greifbare Ergebnisse liefert. Diese können die Teams direkt nach dem Kurs umsetzen.\nDas Training vermittelt die Theorie hinter DevOps, aber der eigentliche Wert entsteht durch die direkte Anwendung auf die eigene Delivery Pipeline.\nDer Vier-Schritte-Prozess # Der Workshop folgt einem klaren Vier-Schritte-Prozess:\nSAFe DevOps Health Radar: Die Teams bewerten sich selbst über die verschiedenen Disziplinen von DevOps hinweg. Dieses Self-Assessment liefert eine Ausgangslage, wo das Team aktuell steht. Aktuelles Value Stream Mapping: Wir erfassen alle Prozessschritte, die nötig sind, um eine Idee in Produktion zu bringen. Das ist der aktuelle Zustand der Delivery Pipeline. Zukünftiges Value Stream Mapping: Mit den Erkenntnissen aus dem SAFe for DevOps Training leiten wir einen zukünftigen Value Stream ab. Das ist der Zielzustand, den das Team erreichen möchte. Priorisierte Massnahmen: Aus der Lücke zwischen aktuellem und zukünftigem Zustand erstellen wir eine klare, priorisierte Liste von Massnahmen, die das Team sofort umsetzen kann. Was die Teams lernen # Während des Workshops erhalten die Teams fundierte Theorie-Inputs zu mehreren wichtigen Themen:\nWas DevOps ist und warum es für Unternehmen heute so wichtig ist Shift Left und die Auswirkungen auf Qualität und Geschwindigkeit Continuous Testing und warum es so entscheidend ist Continuous Security und wie man es in die Pipeline integriert Flow messen durch die Pipeline und Engpässe identifizieren Der SAFe DevOps Health Radar # Der Health Radar deckt vier zentrale Dimensionen der Continuous Delivery Pipeline ab:\nContinuous Exploration: Wie gut entdeckt und validiert das Team, was gebaut werden soll? Continuous Integration: Wie effektiv integriert und verifiziert das Team seinen Code? Continuous Deployment: Wie reibungslos kann das Team in Produktionsumgebungen deployen? Release on Demand: Wie gut kann das Team Mehrwert an Kunden liefern, wenn er gebraucht wird? Durch die Selbstbewertung über diese Dimensionen erhalten Teams ein klares Bild ihrer Stärken und Verbesserungsbereiche.\nFunktioniert auch für einzelne Teams # Eine häufige Frage ist, ob das Training einen vollständigen Agile Release Train (ART) oder eine umfassende SAFe-Implementierung voraussetzt. Die Antwort ist nein. Einzelne Teams können diesen Kurs problemlos besuchen. Zwar tauchen während des Workshops einige SAFe-Begriffe auf, aber wir erklären sie immer im Kontext. Der eigentliche Fokus liegt auf der Verbesserung der Continuous Delivery Pipeline, und das gilt für Teams jeder Grösse.\nKernaussagen # Praxisnah statt theoretisch. Das SAFe for DevOps Training ist ein Workshop, in dem Teams an ihren eigenen realen Value Streams arbeiten, nicht an Lehrbuchbeispielen. Self-Assessment mit dem Health Radar. Teams bewerten sich selbst über vier Dimensionen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Value Stream Mapping deckt Engpässe auf. Durch das Mapping der aktuellen Delivery Pipeline und die Gestaltung eines Zielzustands sehen Teams genau, wo sie sich verbessern können. Teams gehen mit einem konkreten Aktionsplan nach Hause. Die priorisierten Massnahmen geben den Teams etwas, woran sie am nächsten Tag direkt weiterarbeiten können. Keine vollständige SAFe-Implementierung nötig. Das Training funktioniert genauso gut für einzelne Teams wie für ganze Agile Release Trains. Zertifizierung möglich. Teams haben ausserdem die Möglichkeit, sich nach Abschluss des Trainings zertifizieren zu lassen. ","date":"6. June 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-safe-fuer-devops/","section":"Blogs","summary":"In diesem Video erkläre ich, worum es beim SAFe for DevOps Training geht. Im Gegensatz zu klassischen Schulungen ist dieses Training ein praxisnaher Workshop, in dem echte Teams an ihren eigenen Value Streams arbeiten und mit einem konkreten, priorisierten Aktionsplan nach Hause gehen.\n","title":"Was ist SAFe for DevOps?","type":"blogs"},{"content":"In this video, I explain what the SAFe for DevOps training is all about. Unlike traditional classroom courses, this training is a hands-on workshop where real teams work on their own value streams and leave with a concrete, prioritized action plan.\nMore Workshop Than Training # The SAFe for DevOps training is more like a workshop or an assessment than a traditional course. Teams come in with their real challenges and questions about DevOps. Together, we work through a structured process that produces tangible results the teams can act on immediately after the course.\nThe training covers the theory behind DevOps, but the real value comes from applying that theory directly to the teams\u0026rsquo; own delivery pipelines.\nThe Four-Step Process # The workshop follows a clear four-step process:\nSAFe DevOps Health Radar: Teams assess themselves across the different disciplines of DevOps. This self-assessment provides a baseline of where the team currently stands. Current Value Stream Mapping: We map out all the process steps needed to bring an idea into production. This is the current state of the delivery pipeline. Future Value Stream Mapping: Using the input from the SAFe for DevOps training, we derive a future value stream. This is the target state the team wants to reach. Prioritized Action Items: From the gap between current and future state, we create a clear, prioritized set of action items the team can work on right away. What Teams Learn # During the workshop, teams get deep theory input on several important topics:\nWhat DevOps is and why it matters for companies today Shift left and its implications for quality and speed Continuous testing and why it is so important Continuous security and how to integrate it into the pipeline Measuring flow through the pipeline and identifying bottlenecks The SAFe DevOps Health Radar # The Health Radar covers four key dimensions of the continuous delivery pipeline:\nContinuous Exploration: How well does the team discover and validate what to build? Continuous Integration: How effectively does the team integrate and verify their code? Continuous Deployment: How smoothly can the team deploy to production environments? Release on Demand: How well can the team release value to customers when needed? By assessing themselves across these dimensions, teams get a clear picture of their strengths and areas for improvement.\nWorks for Single Teams Too # A common question I get is whether this training requires a full Agile Release Train (ART) or a large-scale SAFe implementation. The answer is no. Single teams can absolutely take this course. While some SAFe terminology will come up during the workshop, we always explain it in context. The real focus is on improving your continuous delivery pipeline, and that applies to teams of any size.\nKey Takeaways # Hands-on, not theoretical. The SAFe for DevOps training is a workshop where teams work on their own real value streams, not on textbook examples. Self-assessment with the Health Radar. Teams assess themselves across four dimensions: continuous exploration, continuous integration, continuous deployment, and release on demand. Value stream mapping reveals bottlenecks. By mapping the current delivery pipeline and designing a future state, teams can see exactly where to improve. Teams leave with a concrete action plan. The prioritized action items give teams something they can start working on the very next day. No full SAFe implementation required. The training works just as well for single teams as it does for entire Agile Release Trains. Certification available. Teams also have the option to get certified after completing the training. ","date":"6 June 2021","externalUrl":null,"permalink":"/en/blogs/what-is-safe-for-devops/","section":"Blogs","summary":"In this video, I explain what the SAFe for DevOps training is all about. Unlike traditional classroom courses, this training is a hands-on workshop where real teams work on their own value streams and leave with a concrete, prioritized action plan.\n","title":"What is SAFe for DevOps?","type":"blogs"},{"content":"","date":"3 April 2021","externalUrl":null,"permalink":"/en/tags/.net/","section":"Tags","summary":"","title":".NET","type":"tags"},{"content":"Does test-driven development work with legacy applications? That is a question I get a lot, and the short answer is yes. In this video I take a big, ugly WinForms application and walk through how I use TDD to add a new feature without touching the messy parts of the existing code. The goal is simple: show that the test-first mindset works even when the surrounding codebase has no tests at all.\nThe Starting Point: A Big, Ugly WinForms Application # The application in the video is exactly the kind of code most developers deal with every day. It is a legacy WinForms application with plenty of settings and screens, no test project, and no test coverage to speak of. When I open it in Visual Studio and start it, it runs, but there is nothing in place that would give me any confidence if I changed something.\nThe task is deliberately small and realistic: add a new button to the form, and when the user clicks it, display a label with some text. That is exactly the kind of ticket that usually tempts people to skip tests altogether, because \u0026ldquo;it is only a button.\u0026rdquo; But that is where the pattern starts.\nRule Number One: Always Start With a Test # The first thing I do when I use test-driven development is introduce a test. That rule does not change just because the application is legacy. Since this project has no test project yet, I add a new unit test project next to the legacy project and call it the big legacy project test. That is the first concrete step: give the legacy solution a place where tests can live.\nInside the test project I create a first test class. I do not start by writing production code. I do not start by dragging a button onto the form. I start by thinking about what the new behavior should look like from the outside.\nDesigning the Backend From the Test # Before I touch the WinForms UI, I decide that the new functionality will live in a separate class called Backend. The UI will eventually call into it, but the tests will drive its design.\nSo I rename the test class to BackendTest and write a test method for it. In the test, I arrange a new Backend, act by calling an OnClick method, and assert that the result equals \u0026quot;hello world\u0026quot;. I add the classic arrange, act, assert comments to make the intent of the test obvious.\nAt this point the Backend class does not exist yet, and the test project does not even have a reference to the legacy project. That is fine. The compiler errors tell me exactly what to do next: create the Backend class in the legacy project, make it public, and add a project reference from the test project to the legacy project so that the test can see it.\nThis is the key shift in mindset. In a legacy application, the temptation is to open the form designer, drop the button, and wire things up. With TDD, the test is what pulls the new code into existence, one small step at a time.\nRed, Green, Refactor in Practice # From there the loop is the classic red-green-refactor cycle.\nFirst red: I run the test, and it fails with a NotImplementedException because Visual Studio generated a stub for OnClick that throws. That is exactly what I want. A failing test is proof that the test actually runs and actually checks something.\nThen green: I change OnClick to return \u0026quot;hello world\u0026quot;. I intentionally make a small mistake first and return \u0026quot;hello world!\u0026quot; with an exclamation mark. I run the tests again and they stay red, because the expected value does not include the exclamation mark. I remove it, run the tests again, and now they go green. That tiny detour is useful. It proves the assertion is really comparing the strings.\nThen refactor: with a green test in place, I can look at the OnClick method and clean it up with confidence. The test will tell me the moment I break the behavior.\nWiring the Legacy UI to the Tested Code # Only now do I go back into the WinForms form and add the new button. I call it \u0026ldquo;Click me\u0026rdquo; and add a button click handler. Inside the handler, I instantiate the Backend and call OnClick, then write the returned string into label1.Text.\nI say it clearly in the video: this is not beautiful code. Instantiating the backend directly in the click handler is not how I would leave it long term. But the important part is that the logic that produces the text lives in a class that is covered by a test. The ugly WinForms glue code is thin, and the behavior underneath it is safe.\nI run all tests again, everything stays green, I start the application, click the button, and the label shows \u0026quot;hello world\u0026quot;. The feature is done, and the legacy application now has its first real test.\nWhat This Means for Legacy Projects # The question at the beginning of the video was whether TDD can be used inside a legacy application, inside a rich client application, inside something built on WinForms that is genuinely ugly. The answer is yes. You do not have to refactor the whole codebase first. You do not have to wait for a big rewrite. You can add a test project next to what you already have, pull new logic out into a small, testable class, and drive that class with tests from day one.\nThe magic behind test-driven development is that you always start with a test. That is the test-first mindset. Once you adopt it, the state of the surrounding code stops being an excuse. Every new feature becomes an opportunity to grow an island of tested, trustworthy code inside the legacy application.\nKey Takeaways # TDD works on legacy code. A missing test project is not a blocker, it is the first thing you create. Add a unit test project next to the legacy project and start there.\nLet the test pull the design. Decide what the new behavior should look like from the outside, write the test first, and let the compiler errors guide you to the classes and methods you need to create.\nKeep new logic out of the UI. Put new functionality into a plain class like Backend, and let the legacy UI call into it. The UI glue stays thin, and the logic underneath is covered by tests.\nTrust the red-green-refactor loop. A failing test, a minimal implementation that turns it green, and then a careful cleanup. Even a tiny mistake like an extra exclamation mark becomes a useful check that your assertions work.\nAdopt the test-first mindset. The real shift is not tooling, it is always starting with a test. Once that becomes your default, TDD scales naturally from greenfield projects into the ugliest legacy applications.\n","date":"3 April 2021","externalUrl":null,"permalink":"/en/blogs/does-tdd-work-with-legacy-code/","section":"Blogs","summary":"Does test-driven development work with legacy applications? That is a question I get a lot, and the short answer is yes. In this video I take a big, ugly WinForms application and walk through how I use TDD to add a new feature without touching the messy parts of the existing code. The goal is simple: show that the test-first mindset works even when the surrounding codebase has no tests at all.\n","title":"Does TDD Work With Legacy Code?","type":"blogs"},{"content":"Funktioniert Test-Driven Development auch mit Legacy-Applikationen? Diese Frage bekomme ich häufig, und die kurze Antwort lautet: Ja. Im Video nehme ich eine grosse, hässliche WinForms-Anwendung und zeige Schritt für Schritt, wie ich mit TDD ein neues Feature ergänze, ohne den bestehenden Spaghetti-Code anfassen zu müssen. Das Ziel ist einfach: demonstrieren, dass der Test-First-Mindset auch dann funktioniert, wenn die Codebasis drumherum überhaupt keine Tests kennt.\nDer Ausgangspunkt: Eine grosse, hässliche WinForms-Anwendung # Die Anwendung im Video ist genau die Art von Code, mit der viele Entwicklerinnen und Entwickler jeden Tag zu tun haben. Eine Legacy-WinForms-Anwendung mit vielen Einstellungen und Screens, ohne Testprojekt, ohne nennenswerte Testabdeckung. Wenn ich sie in Visual Studio öffne und starte, läuft sie zwar, aber es gibt nichts, das mir Sicherheit geben würde, sobald ich etwas ändere.\nDer Task ist bewusst klein und realistisch: Ein neuer Button auf der Form, und wenn man darauf klickt, soll ein Label mit einem Text erscheinen. Genau bei solchen Tickets sind viele versucht, die Tests wegzulassen, weil es \u0026ldquo;nur ein Button\u0026rdquo; ist. Aber genau hier fängt das Muster an.\nRegel Nummer eins: Immer mit einem Test beginnen # Das Erste, was ich bei Test-Driven Development mache, ist einen Test einführen. Diese Regel ändert sich nicht, nur weil die Anwendung Legacy ist. Da das Projekt noch kein Testprojekt hat, lege ich ein neues Unit-Test-Projekt neben dem Legacy-Projekt an und nenne es \u0026ldquo;Big Legacy Project Test\u0026rdquo;. Das ist der erste konkrete Schritt: der Legacy-Solution überhaupt einen Ort geben, an dem Tests leben können.\nIm Testprojekt erstelle ich eine erste Testklasse. Ich fange nicht mit Produktionscode an. Ich ziehe keinen Button auf die Form. Ich überlege mir zuerst, wie sich das neue Verhalten von aussen anfühlen soll.\nDas Backend vom Test her designen # Bevor ich das WinForms-UI anfasse, entscheide ich mich, die neue Funktionalität in einer separaten Klasse namens Backend unterzubringen. Das UI wird später darauf zugreifen, aber die Tests treiben das Design.\nAlso benenne ich die Testklasse in BackendTest um und schreibe eine Testmethode. Im Test arrangiere ich ein neues Backend, rufe im Act-Schritt eine Methode OnClick auf, und im Assert prüfe ich, dass das Ergebnis gleich \u0026quot;hello world\u0026quot; ist. Ich füge die klassischen Arrange-, Act-, Assert-Kommentare hinzu, damit die Absicht des Tests sofort klar ist.\nIn diesem Moment existiert die Klasse Backend noch gar nicht, und das Testprojekt hat nicht einmal eine Referenz auf das Legacy-Projekt. Das ist in Ordnung. Die Compiler-Fehler sagen mir genau, was als Nächstes zu tun ist: die Klasse Backend im Legacy-Projekt erstellen, public machen und eine Projektreferenz vom Testprojekt auf das Legacy-Projekt setzen, damit der Test sie überhaupt sieht.\nDas ist der entscheidende Perspektivenwechsel. In einer Legacy-Anwendung ist die Versuchung gross, sofort den Form-Designer zu öffnen, den Button draufzuziehen und alles direkt zu verdrahten. Mit TDD zieht der Test den neuen Code Schritt für Schritt ins Leben.\nRed, Green, Refactor in der Praxis # Ab hier läuft der klassische Red-Green-Refactor-Zyklus.\nZuerst Red: Ich führe den Test aus, und er schlägt mit einer NotImplementedException fehl, weil Visual Studio einen Stub für OnClick generiert hat, der wirft. Genau das will ich. Ein fehlgeschlagener Test beweist, dass der Test wirklich läuft und wirklich etwas prüft.\nDann Green: Ich ändere OnClick so, dass die Methode \u0026quot;hello world\u0026quot; zurückgibt. Absichtlich baue ich zuerst einen kleinen Fehler ein und gebe \u0026quot;hello world!\u0026quot; mit Ausrufezeichen zurück. Ich lasse die Tests erneut laufen und sie bleiben rot, weil der erwartete Wert kein Ausrufezeichen enthält. Ich entferne es, führe die Tests noch einmal aus, und jetzt werden sie grün. Dieser kleine Umweg ist nützlich. Er beweist, dass die Assertion wirklich die Strings vergleicht.\nDann Refactor: Mit einem grünen Test im Rücken kann ich die OnClick-Methode in Ruhe anschauen und aufräumen. Der Test sagt mir sofort Bescheid, wenn ich das Verhalten kaputt mache.\nDas Legacy-UI an den getesteten Code anbinden # Erst jetzt gehe ich zurück in die WinForms-Form und füge den neuen Button hinzu. Ich nenne ihn \u0026ldquo;Click me\u0026rdquo; und ergänze einen Button-Click-Handler. Im Handler instanziere ich das Backend und rufe OnClick auf, danach schreibe ich den zurückgegebenen Text in label1.Text.\nIch sage es im Video ganz klar: Das ist kein schöner Code. Das Backend direkt im Click-Handler zu instanziieren, ist nicht der Zustand, in dem ich es langfristig lassen würde. Aber das Entscheidende ist: Die Logik, die den Text erzeugt, liegt in einer Klasse, die von einem Test abgedeckt ist. Der hässliche WinForms-Glue-Code ist dünn, und das Verhalten darunter ist sicher.\nIch lasse alle Tests noch einmal laufen, alles bleibt grün. Ich starte die Anwendung, klicke auf den Button, und das Label zeigt \u0026quot;hello world\u0026quot;. Das Feature ist fertig, und die Legacy-Anwendung hat jetzt ihren ersten echten Test.\nWas das für Legacy-Projekte bedeutet # Die Frage zu Beginn des Videos war, ob man TDD innerhalb einer Legacy-Anwendung, innerhalb einer Rich-Client-Anwendung, innerhalb von etwas WinForms-artigem und wirklich Hässlichem einsetzen kann. Die Antwort ist ja. Du musst nicht erst die ganze Codebasis refactoren. Du musst nicht auf den grossen Rewrite warten. Du kannst ein Testprojekt neben das bestehende Projekt legen, neue Logik in eine kleine, testbare Klasse herausziehen und diese Klasse von Tag eins an mit Tests treiben.\nDie Magie hinter Test-Driven Development ist, dass du immer mit einem Test anfängst. Das ist der Test-First-Mindset. Sobald du ihn verinnerlichst, hört der Zustand des bestehenden Codes auf, eine Ausrede zu sein. Jedes neue Feature wird zur Gelegenheit, innerhalb der Legacy-Anwendung eine Insel aus getestetem, vertrauenswürdigem Code wachsen zu lassen.\nWichtigste Erkenntnisse # TDD funktioniert auch mit Legacy Code. Ein fehlendes Testprojekt ist kein Blocker, sondern das Erste, was du anlegst. Ein Unit-Test-Projekt neben dem Legacy-Projekt, und schon hast du einen Startpunkt.\nLass den Test das Design treiben. Überlege dir, wie sich das neue Verhalten von aussen anfühlen soll, schreibe den Test zuerst und lass dich von den Compiler-Fehlern zu den Klassen und Methoden führen, die du brauchst.\nNeue Logik raus aus dem UI. Pack die neue Funktionalität in eine einfache Klasse wie Backend, und lass das Legacy-UI darauf zugreifen. Der UI-Glue bleibt dünn, die Logik darunter ist durch Tests abgedeckt.\nVertraue dem Red-Green-Refactor-Zyklus. Ein fehlschlagender Test, eine minimale Implementierung bis er grün wird, dann sauberes Aufräumen. Selbst ein kleiner Fehler wie ein zusätzliches Ausrufezeichen wird zu einem nützlichen Check, dass deine Assertions wirklich greifen.\nVerinnerliche den Test-First-Mindset. Die eigentliche Veränderung ist nicht das Tooling, sondern dass du immer mit einem Test anfängst. Sobald das dein Default ist, skaliert TDD ganz natürlich von Greenfield-Projekten bis in die hässlichsten Legacy-Anwendungen.\n","date":"3. April 2021","externalUrl":null,"permalink":"/de/blogs/funktioniert-tdd-mit-legacy-code/","section":"Blogs","summary":"Funktioniert Test-Driven Development auch mit Legacy-Applikationen? Diese Frage bekomme ich häufig, und die kurze Antwort lautet: Ja. Im Video nehme ich eine grosse, hässliche WinForms-Anwendung und zeige Schritt für Schritt, wie ich mit TDD ein neues Feature ergänze, ohne den bestehenden Spaghetti-Code anfassen zu müssen. Das Ziel ist einfach: demonstrieren, dass der Test-First-Mindset auch dann funktioniert, wenn die Codebasis drumherum überhaupt keine Tests kennt.\n","title":"Funktioniert TDD mit Legacy Code?","type":"blogs"},{"content":"","date":"3 April 2021","externalUrl":null,"permalink":"/en/tags/legacy-code/","section":"Tags","summary":"","title":"Legacy Code","type":"tags"},{"content":"","date":"3 April 2021","externalUrl":null,"permalink":"/en/tags/refactoring/","section":"Tags","summary":"","title":"Refactoring","type":"tags"},{"content":"","date":"3 April 2021","externalUrl":null,"permalink":"/en/tags/tdd/","section":"Tags","summary":"","title":"TDD","type":"tags"},{"content":"","date":"3 April 2021","externalUrl":null,"permalink":"/en/tags/unit-testing/","section":"Tags","summary":"","title":"Unit Testing","type":"tags"},{"content":"","date":"2 March 2021","externalUrl":null,"permalink":"/en/tags/remote-collaboration/","section":"Tags","summary":"","title":"Remote Collaboration","type":"tags"},{"content":"","date":"2 March 2021","externalUrl":null,"permalink":"/en/tags/spatial-computing/","section":"Tags","summary":"","title":"Spatial Computing","type":"tags"},{"content":"After the strong response our previous video on VR received on LinkedIn, people kept asking the same questions: Is this really the new normal? Where is the technology going? Is now the right moment to jump in? To go deeper, I invited Christoph back into the conversation together with Michaela. Christoph has been working with enterprise clients on virtual reality for years, and our discussion ranges from the maturing hardware and software ecosystem to what a workshop in VR actually feels like, and why the employer of the future will hand out three devices instead of one.\nFrom Prototype to Real Product # Four years ago, when Michaela and I first worked on a VR project together, the setup felt like building a home gym every time you wanted to jump in. Cables, external sensors, a dedicated three-by-three-meter space, a powerful computer in the corner. Christoph\u0026rsquo;s observation is that this world is gone.\nIn the last six months in particular, he sees the technology crossing an inflection point. Enterprise adoption has accelerated in a way that simply was not the case a year or a year and a half ago. What used to be a prototype is now a real product. Hardware has become user-friendly and available at scale, use cases are becoming replicable, and the software ecosystem around them is maturing. The last twelve months, in his words, were pivotal.\nThat matters because the friction around the technology is what always held it back. Remove that friction, and the things that already worked start working at scale, across departments and across processes.\nNot a Glorified Video Conference # One of the clearest points Christoph made is about what VR is not. It is not a better camera. It is not a better microphone. And it is emphatically not a glorified video conference where everybody puts on a headset to share a screen and stare at it together. If that is all you do, you will never justify the change management effort required to adopt the technology.\nWhat VR actually delivers is a fundamentally different way of being together. Even a simple meeting in VR feels more intimate, more focused, and more connected than the same meeting on a video call. The sense of presence is the foundation, and every benefit stacks on top of it.\nWhen I joined the VR meeting for this conversation, I was sitting at my desk with a coffee cup next to me. But it genuinely felt like I was sitting at a table with Christoph and Michaela, having a real conversation. The other two were physically miles away, and yet the interaction felt personal.\nWhere VR Shines Right Now # The real business case today, Christoph argues, is in meetings that a video conference cannot handle well. Think of a workshop with twenty people where you actually need to make a decision. On a video call, one person speaks at a time, one piece of information is shared at a time. The dynamism of a real team in a real room is simply missing.\nIn VR, that dynamism returns. People split into groups. They work in parallel on whiteboards. They move around the space. They discuss complex data spread out across their field of view instead of crammed onto a small screen. Decisions that would otherwise drag across several video calls happen in a single immersive session.\nFor those kinds of meetings, complex decisions, strategic workshops, data-heavy discussions, the payback time on equipping people with headsets is, in his experience, incredibly fast. That is the honest business case, not a wow factor.\nCompatibility and Cognitive Bandwidth # One of the more nuanced points in the conversation was Christoph\u0026rsquo;s concept of cognitive bandwidth. A VR meeting can actually carry more information than an individual working on a laptop, because the space around you becomes usable. A presentation here, a whiteboard there, data visualizations in between. You turn your head instead of juggling tabs.\nBut that only works if VR does not become an island. You cannot build a productivity environment where no data flows in and no data flows out. The transition from traditional tools into VR has to be smooth, not binary. Work streams should be able to move into VR gradually, as the use cases prove themselves, without forcing the organization to choose between legacy systems and immersive collaboration.\nGetting this balance right is the hard product question. How do you bring in concepts from the physical world like whiteboards, post-its, and screen sharing without limiting what VR can do? That is where good solutions distinguish themselves from gimmicks.\nThe Space Question # One detail that stuck with me from our previous conversation was the cost of physical space. Companies hold real estate with large square footage, and over the past months a lot of that space simply sat empty. Good meeting rooms with whiteboards, screens, and room to move are expensive in big cities, and you end up paying for capacity you rarely use in full.\nIn VR, space is essentially free to replicate and reshape. You can have a small room for a focused one-on-one, a large auditorium for a company-wide announcement, or a mountain terrace with a view of a lake for a strategic offsite, and switch between them without moving anyone. The psychology of a space influences how people interact, and in VR you can choose the environment that actually fits the meeting.\nThe Employer of the Future # Toward the end of our conversation, we came back to a piece Christoph and his team had written about the employer of the future. Their shorthand was SLH: smartphone, laptop, and headset. The point is not that VR replaces everything else. It does not.\nYou will not spend eight hours a day in a headset. You will continue to use video conferencing, chat, and email for everything they already handle well. But for a specific class of meetings, strategy, workshops, immersive team events, networking, VR becomes the right tool. The employer of the future equips people with the right instrument for the right job.\nThis also reshapes how we think about geography. Christoph made a point that stayed with me: in twenty years, we may look back at today as barbaric, because so many people were forced to choose between family and career, to relocate to cities purely because their jobs were anchored there. The promise of VR and spatial computing is that employers will be able to work with the people they want, wherever those people are. Work becomes more equal, not more dystopian.\nWhat I Miss, and What VR Gives Back # During the pandemic, what I missed most was not formal meetings. Those migrated to video conferencing without too much pain. What I missed was the coffee-machine chat with colleagues, the unplanned conversation in a hallway, the social connection that forms almost by accident. Those informal moments have been the real casualty of fully remote work.\nThe evening before this conversation, I attended a meetup in VR. I walked up to a table, joined a chat, and suddenly felt like I knew the people at that table. I could hear them, sense them, feel their presence. That is the part of in-person work that video calls have not been able to replicate, and it is the part VR actually restores.\nThis does not mean VR will replace real human contact. But for the moments where we cannot be in the same room, and for the global collaboration that is increasingly normal, it offers something closer to the real thing than any tool we have had before.\nThe Remaining Hurdles # I do not want to pretend the technology is finished. The biggest hurdle I still see, and I hear this from friends and colleagues all the time, is simply the device. You need to own one, put it on, and set it up. The moment software exists that lets people join a VR meeting from a normal PC to simulate the experience, adoption will climb significantly.\nThe second hurdle is that we are still learning which meetings belong in VR and which do not. Every organization has to experiment to figure out where the technology adds value and where it does not. Not every use case works everywhere, and that is fine. What matters is the willingness to try.\nChristoph pointed out something encouraging here. In the clients he works with, they now see clear activation moments. A first social event, a first workshop, a first strategic presentation in VR, and the conversion rate of people who then want to bring it into their own teams is very high. Once people experience it, most of the skepticism dissolves.\nRiding the Wave, Not Chasing It # My closing recommendation is simple: try it. We are at a tipping point. The growth right now looks exponential, even if from the outside it still feels like a flat curve because the market of work is so enormous. Within the next six to twelve months, I expect to see a serious increase in the number of meetings and events happening in VR.\nIf you are an organization and spatial computing is not yet on your map, now is the moment to put it there. Not because of hype, but because the companies adopting it are not doing so as a gimmick. They are using it to make decisions faster, work more flexibly across geographies, and build teams that are not bound by location.\nAs I said at the end of the conversation: smart working for the future is VR. Be brave and take the step. If you are in the first wave, you get to shape how your organization uses the technology. If you wait for the wave to pass, catching up will be harder.\nKey Takeaways # VR has crossed an inflection point. In the last twelve months, the technology moved from prototype to real product. Hardware is user-friendly, use cases are replicable, and the software ecosystem has matured.\nDo not build a glorified video conference. VR\u0026rsquo;s value is the sense of presence and the ability to collaborate dynamically. If your VR solution just mirrors a screen share, it will not justify the adoption effort.\nStart with the meetings where VR shines. Complex decisions, strategic workshops, data-heavy discussions, and team events are where the payback is fast. Not every meeting needs to move into VR.\nPlan for integration, not an island. Work streams should be able to transition into VR gradually. Data needs to flow in and out. Treat the transition as continuous, not binary.\nThink of the employer of the future as SLH. Smartphone, laptop, headset. Pick the right tool for the right interaction instead of forcing everything into one channel.\nLower the experience barrier. Organize a first VR event for your team, even a small one. The activation moment, once people have actually felt presence in VR, drives far higher adoption than any pitch.\nDo not miss the train. Exponential growth looks flat from the outside at first. The organizations informing themselves now and running their first pilots will be years ahead of those who wait.\n","date":"2 March 2021","externalUrl":null,"permalink":"/en/blogs/virtual-reality-businesses-metaverse-future/","section":"Blogs","summary":"After the strong response our previous video on VR received on LinkedIn, people kept asking the same questions: Is this really the new normal? Where is the technology going? Is now the right moment to jump in? To go deeper, I invited Christoph back into the conversation together with Michaela. Christoph has been working with enterprise clients on virtual reality for years, and our discussion ranges from the maturing hardware and software ecosystem to what a workshop in VR actually feels like, and why the employer of the future will hand out three devices instead of one.\n","title":"Virtual Reality Businesses: The Metaverse Is the Future","type":"blogs"},{"content":"Nach den vielen Reaktionen auf unser erstes VR-Video auf LinkedIn kamen immer wieder dieselben Fragen: Ist das jetzt wirklich die neue Normalität? Wohin entwickelt sich die Technologie? Ist der richtige Moment gekommen, um einzusteigen? Um tiefer einzutauchen, habe ich Christoph zusammen mit Michaela erneut ins Gespräch geholt. Christoph arbeitet seit Jahren mit Enterprise-Kunden an Virtual-Reality-Lösungen, und unsere Diskussion reicht von der reifenden Hardware- und Software-Landschaft bis zu der Frage, wie sich ein Workshop in VR wirklich anfühlt und warum der Arbeitgeber der Zukunft nicht mehr nur ein Gerät verteilt.\nVom Prototyp zum echten Produkt # Vor rund vier Jahren, als Michaela und ich das erste Mal gemeinsam an einem VR-Projekt arbeiteten, fühlte sich jeder Einstieg in VR an wie das Aufbauen eines Home Gyms. Kabel, externe Sensoren, ein dedizierter Raum von drei mal drei Metern, ein leistungsstarker Rechner in der Ecke. Christoph stellt klar: Diese Welt ist vorbei.\nVor allem in den letzten sechs Monaten sieht er, wie die Technologie einen Wendepunkt erreicht hat. Die Adoption im Unternehmen hat sich so stark beschleunigt, wie es vor einem Jahr noch nicht absehbar war. Was früher Prototyp war, ist heute echtes Produkt. Die Hardware ist benutzerfreundlich und skalierbar verfügbar, Use Cases sind replizierbar, und das Software-Ökosystem rund herum reift. Die letzten zwölf Monate waren, wie er sagt, entscheidend.\nDas ist deshalb so wichtig, weil die Reibung rund um die Technologie immer der eigentliche Bremsklotz war. Nimm diese Reibung weg, und die Dinge, die grundsätzlich funktionieren, funktionieren plötzlich im grossen Stil, über Abteilungen und Prozesse hinweg.\nKeine aufgemotzte Videokonferenz # Einer der klarsten Punkte im Gespräch war Christophs Aussage, was VR nicht ist. Es ist keine bessere Kamera. Es ist kein besseres Mikrofon. Und es ist ganz sicher keine aufgemotzte Videokonferenz, bei der alle ein Headset aufsetzen, um gemeinsam auf einen geteilten Screen zu starren. Wer VR so einsetzt, wird den Change-Management-Aufwand niemals rechtfertigen können.\nWas VR wirklich liefert, ist eine fundamental andere Form des Zusammenseins. Selbst ein einfaches Meeting in VR fühlt sich persönlicher, fokussierter und verbindender an als das gleiche Meeting per Video. Dieses Gefühl von Präsenz ist das Fundament, und jeder weitere Nutzen stapelt sich darauf.\nAls ich mich für dieses Gespräch in die VR-Umgebung eingeloggt habe, sass ich an meinem Schreibtisch, die Kaffeetasse neben mir. Aber es fühlte sich tatsächlich so an, als würde ich mit Christoph und Michaela an einem Tisch sitzen und mich unterhalten. Die beiden waren physisch weit weg, und trotzdem war die Interaktion persönlich.\nWo VR heute glänzt # Der eigentliche Business Case liegt laut Christoph bei Meetings, die eine Videokonferenz nicht gut abbilden kann. Stell dir einen Workshop mit zwanzig Personen vor, in dem eine echte Entscheidung getroffen werden muss. Auf dem Videocall spricht eine Person zur Zeit, eine Information wird zur Zeit geteilt. Die Dynamik eines echten Teams in einem echten Raum fehlt komplett.\nIn VR kommt diese Dynamik zurück. Die Leute bilden Gruppen. Sie arbeiten parallel an Whiteboards. Sie bewegen sich im Raum. Sie diskutieren komplexe Daten, die sich um sie herum verteilen, statt sich auf einen kleinen Bildschirm zu quetschen. Entscheidungen, die sonst über mehrere Videocalls gezogen würden, passieren in einer einzigen immersiven Session.\nFür genau diese Art von Meetings, komplexe Entscheidungen, strategische Workshops, datenintensive Diskussionen, ist laut Christoph die Amortisationszeit für die Headsets erstaunlich kurz. Das ist der ehrliche Business Case, nicht der Wow-Effekt.\nKompatibilität und kognitive Bandbreite # Einer der spannenderen Punkte im Gespräch war Christophs Konzept der kognitiven Bandbreite. Ein VR-Meeting kann mehr Information tragen als die Arbeit einer einzelnen Person am Laptop, weil der Raum rund herum nutzbar wird. Eine Präsentation hier, ein Whiteboard dort, Datenvisualisierungen dazwischen. Man dreht den Kopf, statt Tabs zu jonglieren.\nDas funktioniert allerdings nur, wenn VR keine Insel wird. Man kann keine Produktivitätsumgebung bauen, in die weder Daten hinein noch hinaus fliessen. Der Übergang von klassischen Tools zu VR muss fliessend sein, nicht binär. Workstreams müssen schrittweise in VR wandern können, genau dann, wenn die Use Cases sich bewähren, ohne dass die Organisation zwischen Legacy-Systemen und immersiver Zusammenarbeit wählen muss.\nDiese Balance richtig hinzubekommen, ist die harte Produktfrage. Wie bringt man Konzepte aus der physischen Welt wie Whiteboards, Post-its und Screensharing hinein, ohne die Möglichkeiten von VR zu beschneiden? Genau an dieser Stelle unterscheiden sich gute Lösungen von Spielereien.\nDie Frage nach dem Raum # Ein Detail aus unserem letzten Gespräch ist mir hängen geblieben: die Kosten von physischem Raum. Unternehmen halten grosse Büroflächen, und in den letzten Monaten stand ein Grossteil davon schlicht leer. Gute Meetingräume mit Whiteboards, Bildschirmen und genug Platz, um sich zu bewegen, sind in grossen Städten teuer, und man zahlt oft für Kapazität, die man nur selten voll nutzt.\nIn VR ist Raum praktisch gratis replizierbar und umgestaltbar. Ein kleiner Raum für ein fokussiertes Zweiergespräch, ein grosser Saal für die Firmeninfo, eine Bergterrasse mit Blick auf den See für das strategische Offsite, und das alles ohne dass jemand umziehen muss. Die Psychologie eines Raumes prägt, wie Menschen miteinander arbeiten, und in VR kann man die Umgebung wählen, die wirklich zum Meeting passt.\nDer Arbeitgeber der Zukunft # Gegen Ende des Gesprächs kamen wir auf einen Beitrag zurück, den Christophs Team über den Arbeitgeber der Zukunft geschrieben hat. Ihr Kürzel dafür ist SLH: Smartphone, Laptop, Headset. Die Idee ist nicht, dass VR alles andere ersetzt. Tut sie nicht.\nNiemand wird acht Stunden am Stück im Headset verbringen. Videokonferenzen, Chat und Mail bleiben für das, wofür sie gut funktionieren. Aber für eine bestimmte Art von Meetings, Strategie, Workshops, immersive Team-Events, Networking, wird VR zum richtigen Werkzeug. Der Arbeitgeber der Zukunft rüstet Menschen mit dem richtigen Instrument für den richtigen Zweck aus.\nDamit ändert sich auch, wie wir über Geografie denken. Christoph hat einen Punkt gemacht, der bei mir hängen geblieben ist: In zwanzig Jahren blicken wir vielleicht auf die heutige Zeit zurück als etwas Barbarisches, weil so viele Menschen gezwungen waren, zwischen Familie und Karriere zu wählen, nur weil ihr Job an eine Stadt gebunden war. Das Versprechen von VR und Spatial Computing ist, dass Arbeitgeber mit den Menschen zusammenarbeiten können, die sie wollen, egal wo diese sind. Arbeit wird dadurch gerechter, nicht dystopischer.\nWas mir fehlt, und was VR zurückgibt # Während der Pandemie habe ich nicht die formalen Meetings vermisst. Die sind ohne grössere Schmerzen in Videokonferenzen gewandert. Was mir gefehlt hat, war der Schwatz an der Kaffeemaschine, das ungeplante Gespräch im Flur, die soziale Verbindung, die fast nebenbei entsteht. Diese informellen Momente sind die eigentlichen Verlierer vollständig remote organisierter Arbeit.\nAm Abend vor unserem Gespräch war ich an einem Meetup in VR. Ich bin an einen Tisch gelaufen, habe mich in ein Gespräch eingeklinkt, und plötzlich hatte ich das Gefühl, die Leute am Tisch zu kennen. Ich konnte sie hören, sie spüren, ihre Präsenz wahrnehmen. Genau der Teil von Präsenz-Arbeit, den Videocalls nie wirklich ersetzen konnten, kommt in VR zurück.\nDas heisst nicht, dass VR echten menschlichen Kontakt ersetzt. Aber für die Momente, in denen wir nicht im selben Raum sein können, und für die globale Zusammenarbeit, die immer mehr zur Norm wird, liefert VR etwas, das der Realität näher kommt als alles, was wir bisher hatten.\nDie verbleibenden Hürden # Ich will nicht so tun, als wäre die Technologie fertig. Die grösste Hürde, die ich sehe, und das höre ich auch von Freunden und Kolleginnen, ist schlicht das Gerät. Man muss eines besitzen, aufsetzen, einrichten. In dem Moment, in dem Software entsteht, mit der Teilnehmende auch über den normalen PC in eine VR-Session einsteigen und den Raum simulieren können, wird die Adoption deutlich zulegen.\nDie zweite Hürde ist, dass wir noch lernen, welche Meetings in VR gehören und welche nicht. Jede Organisation muss experimentieren, um herauszufinden, wo die Technologie Wert liefert und wo nicht. Nicht jeder Use Case funktioniert überall, und das ist in Ordnung. Entscheidend ist die Bereitschaft, es auszuprobieren.\nChristoph hat hier einen ermutigenden Punkt gemacht. Bei seinen Kunden sieht sein Team mittlerweile klare Aktivierungsmomente. Ein erstes Social Event, ein erster Workshop, eine erste strategische Präsentation in VR, und die Konversionsrate der Menschen, die das danach in ihre eigenen Teams tragen wollen, ist sehr hoch. Sobald Menschen es erlebt haben, löst sich ein grosser Teil der Skepsis auf.\nDie Welle mitnehmen, nicht hinterherlaufen # Meine abschliessende Empfehlung ist einfach: ausprobieren. Wir stehen an einem Kipppunkt. Das Wachstum sieht im Moment exponentiell aus, auch wenn es von aussen noch wie eine flache Kurve wirkt, weil der Markt der Arbeit so riesig ist. Innerhalb der nächsten sechs bis zwölf Monate erwarte ich eine spürbare Zunahme von Meetings und Events in VR.\nWenn du als Organisation Spatial Computing noch nicht auf deiner Landkarte hast, ist jetzt der Moment, es dort einzutragen. Nicht wegen Hype, sondern weil die Firmen, die es einführen, es nicht als Spielerei nutzen. Sie setzen es ein, um schneller zu entscheiden, über Geografien hinweg flexibler zu arbeiten und Teams zu bauen, die nicht mehr an Orte gebunden sind.\nWie ich am Ende des Gesprächs gesagt habe: Smart Working der Zukunft heisst VR. Sei mutig und mach den Schritt. Wer in der ersten Welle mitreitet, gestaltet, wie die eigene Organisation die Technologie nutzt. Wer wartet, bis die Welle vorbei ist, tut sich beim Aufholen schwer.\nWichtigste Erkenntnisse # VR hat einen Wendepunkt überschritten. In den letzten zwölf Monaten ist die Technologie vom Prototyp zum echten Produkt geworden. Hardware ist benutzerfreundlich, Use Cases sind replizierbar und das Software-Ökosystem ist gereift.\nBau keine aufgemotzte Videokonferenz. Der Wert von VR liegt im Präsenzgefühl und in der dynamischen Zusammenarbeit. Wer VR nur als Screensharing nutzt, rechtfertigt den Aufwand der Einführung nicht.\nStarte dort, wo VR glänzt. Komplexe Entscheidungen, strategische Workshops, datenintensive Diskussionen und Team-Events bringen den schnellsten Return. Nicht jedes Meeting muss in VR.\nPlane Integration, keine Insel. Workstreams müssen schrittweise in VR wandern können. Daten müssen rein und raus fliessen. Behandle den Übergang als kontinuierlich, nicht als binär.\nDenke an den Arbeitgeber der Zukunft als SLH. Smartphone, Laptop, Headset. Das richtige Werkzeug für die richtige Interaktion, statt alles in einen Kanal zu zwängen.\nSenke die Erfahrungshürde. Organisiere einen ersten kleinen VR-Event für dein Team. Der Aktivierungsmoment, wenn Menschen Präsenz in VR selbst erlebt haben, zieht deutlich mehr Adoption nach sich als jedes Verkaufsargument.\nVerpass den Zug nicht. Exponentielles Wachstum sieht von aussen anfangs flach aus. Wer sich jetzt informiert und erste Pilotprojekte fährt, ist denen, die warten, über Jahre hinweg voraus.\n","date":"2. March 2021","externalUrl":null,"permalink":"/de/blogs/virtual-reality-unternehmen-metaverse-zukunft/","section":"Blogs","summary":"Nach den vielen Reaktionen auf unser erstes VR-Video auf LinkedIn kamen immer wieder dieselben Fragen: Ist das jetzt wirklich die neue Normalität? Wohin entwickelt sich die Technologie? Ist der richtige Moment gekommen, um einzusteigen? Um tiefer einzutauchen, habe ich Christoph zusammen mit Michaela erneut ins Gespräch geholt. Christoph arbeitet seit Jahren mit Enterprise-Kunden an Virtual-Reality-Lösungen, und unsere Diskussion reicht von der reifenden Hardware- und Software-Landschaft bis zu der Frage, wie sich ein Workshop in VR wirklich anfühlt und warum der Arbeitgeber der Zukunft nicht mehr nur ein Gerät verteilt.\n","title":"Virtual Reality im Unternehmen: Das Metaverse ist die Zukunft","type":"blogs"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/bdd/","section":"Tags","summary":"","title":"BDD","type":"tags"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/cucumber/","section":"Tags","summary":"","title":"Cucumber","type":"tags"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/gherkin/","section":"Tags","summary":"","title":"Gherkin","type":"tags"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/sdlc/","section":"Tags","summary":"","title":"SDLC","type":"tags"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/software-testing/","section":"Tags","summary":"","title":"Software Testing","type":"tags"},{"content":"","date":"20 February 2021","externalUrl":null,"permalink":"/en/tags/specflow/","section":"Tags","summary":"","title":"SpecFlow","type":"tags"},{"content":"Automating tests is a complex and demanding task. The iterative approach in the development process also means that the automated tests have to be continuously adapted. Behaviour-driven development (BDD) can be used to simplify and speed up test automation.\nBy Romano Roth and Marcel Stalder\nAgile and iterative software development with DevOps, including an automated build and deployment pipeline, requires good and automated test coverage.\nDefining requirements for business software isn’t a trivial task. While the basic idea of a new functionality is usually communicated quickly, the challenges lie in the details. For example, product owners (PO), business analysts (BA) and requirement engineers (RE) use different forms to define requirements such as prose text, decision tables or sequence diagrams. Requirements are also communicated verbally to the developers (DEV) when something is questionable or ambiguous, for example, or if requirements have not been documented elsewhere.\nThis leads to several transformation steps:\nThe requirements from different sources and in different formats have to be communicated to the developers. The developers convert the requirements into source code, firstly for the implementation itself and secondly for the automated tests. The Quality Assurance (QA) managers, in turn, must be familiar not only with the requirements but also with how they have been implemented in practice. Requirements, however, don’t usually remain fixed. They change. So the transformation process starts again and the delta to the existing implementation has to be identified. This step is time consuming and makes testing and quality assurance more difficult when changes are made, which isn\u0026rsquo;t ideal when you\u0026rsquo;re dealing with an automated CI/CD pipeline that has short development and test cycles.\nThe executable specification # What if the specification were executable? This would simplify the transformation steps, there would be fewer misunderstandings and the development process would be accelerated. An additional benefit is the documentation of the system’s functionality, which also really corresponds to the current implementation. This should result in better quality and therefore fewer bugs.\nOne possibility for an executable specification is behaviour-driven development (BDD) - an agile software development process that has its roots in test-driven development (TDD) and incorporates ideas from domain-driven design (DDD).\nIn BDD, the desired behaviour of a piece of software can be defined directly in a user story, for example:\nThe syntax Gherkin, which uses Given-When-Then as the basic structure for describing the precondition, the action and the expected result, is used for the definition. As it is pure text, the description of the behaviour can be used with various technologies, including:\nSpecFlow for .NET Cucumber.js for JavaScript Cucumber-JVM for Java Behave for Python A practical example # Start with the specification of the desired behaviour. One example is a (simplified) calculation of the market value of a position in a securities portfolio:\nThe BDD tool reads this specification and generates a step definition for each Given/When/Then line. Step definitions are methods in the test code and are used as a link to the domain classes. The developers’ job is now to implement the generated step definitions based on the specification. The specification is then executed via the runner of the test framework used.\nAs the domain classes suggest, BDD is used here for unit tests to test the business logic. However, the automated execution of the specification is not limited to unit testing but can be used at all levels of the test pyramid. Many examples of BDD work at system level and automate UI tests using Selenium. Integration tests can, however, also be carried out to create or verify data in a database, for example.\nThe development process # The specifications are usually much more complex than the simplified practical example. This is why a solution design (SD) is created before the actual implementation process. To name but a few examples, this SD describes the actual situation, the target situation and the implementation steps (stories). The key element is the specification in Gherkin. Starting with the user story for the solution design, this spec is constantly expanded and refined. The spec is also a key element in the reviews to verify the requirements and the current implementation.\nBehaviour-driven development (BDD) with the specification of the application behaviour in Gherkin is an advisable step for the automated testing of complex technical requirements. As the executable specification is already available at the start of the development work, test-driven development (TDD) is easy to implement. If a specification is to be consistent, everyone involved in the development process must use a common language, which is why domain-driven design (DDD) with a central and documented domain model is a good basis.\nThanks to behaviour-driven development (BDD) and an automated build and deployment pipeline, organisations can increase both feedback cycles and throughput speed. This allows them to react more quickly and impress their customers with constant innovation. Thanks to DevOps, processes are automated and optimised, from development to release and all the way to operations. This increases efficiency, which in turn reduces the costs associated with changes.\nOriginal Post: Medium\n","date":"20 February 2021","externalUrl":null,"permalink":"/en/blogs/test-automation-with-behavior-driven-development-bdd/","section":"Blogs","summary":"Automating tests is a complex and demanding task. The iterative approach in the development process also means that the automated tests have to be continuously adapted. Behaviour-driven development (BDD) can be used to simplify and speed up test automation.\n","title":"Test automation with Behavior-Driven Development (BDD)","type":"blogs"},{"content":"Die Automatisierung von Tests ist eine komplexe und anspruchsvolle Aufgabe. Der iterative Ansatz im Entwicklungsprozess bedeutet auch, dass die automatisierten Tests kontinuierlich angepasst werden müssen. Behaviour-Driven Development (BDD) kann eingesetzt werden, um die Testautomatisierung zu vereinfachen und zu beschleunigen.\nVon Romano Roth und Marcel Stalder\nAgile und iterative Softwareentwicklung mit DevOps, einschliesslich einer automatisierten Build- und Deployment-Pipeline, erfordert eine gute und automatisierte Testabdeckung.\nDie Definition von Anforderungen für Geschäftssoftware ist keine triviale Aufgabe. Während die Grundidee einer neuen Funktionalität in der Regel schnell kommuniziert wird, liegen die Herausforderungen im Detail. Product Owner (PO), Business-Analysten (BA) und Requirements Engineers (RE) verwenden beispielsweise verschiedene Formen zur Definition von Anforderungen wie Prosatext, Entscheidungstabellen oder Sequenzdiagramme. Anforderungen werden auch mündlich an die Entwickler (DEV) kommuniziert, wenn etwas fragwürdig oder mehrdeutig ist oder wenn Anforderungen nicht anderweitig dokumentiert wurden.\nDies führt zu mehreren Transformationsschritten:\nDie Anforderungen aus verschiedenen Quellen und in verschiedenen Formaten müssen an die Entwickler kommuniziert werden. Die Entwickler setzen die Anforderungen in Quellcode um, erstens für die eigentliche Implementierung und zweitens für die automatisierten Tests. Die Verantwortlichen für Qualitätssicherung (QA) müssen wiederum nicht nur die Anforderungen kennen, sondern auch wissen, wie diese in der Praxis umgesetzt wurden. Anforderungen bleiben jedoch in der Regel nicht fix. Sie ändern sich. Also beginnt der Transformationsprozess von neuem und das Delta zur bestehenden Implementierung muss identifiziert werden. Dieser Schritt ist zeitaufwändig und erschwert das Testen und die Qualitätssicherung bei Änderungen. Das ist nicht ideal, wenn man mit einer automatisierten CI/CD-Pipeline arbeitet, die kurze Entwicklungs- und Testzyklen hat.\nDie ausführbare Spezifikation # Was wäre, wenn die Spezifikation ausführbar wäre? Das würde die Transformationsschritte vereinfachen, es gäbe weniger Missverständnisse und der Entwicklungsprozess würde beschleunigt. Ein zusätzlicher Vorteil ist die Dokumentation der Systemfunktionalität, die auch wirklich der aktuellen Implementierung entspricht. Das sollte zu besserer Qualität und damit zu weniger Fehlern führen.\nEine Möglichkeit für eine ausführbare Spezifikation ist Behaviour-Driven Development (BDD), ein agiler Softwareentwicklungsprozess, der seine Wurzeln im Test-Driven Development (TDD) hat und Ideen aus dem Domain-Driven Design (DDD) übernimmt.\nIn BDD kann das gewünschte Verhalten einer Software direkt in einer User Story definiert werden, zum Beispiel:\nDie Syntax Gherkin, die Given-When-Then als Grundstruktur zur Beschreibung der Vorbedingung, der Aktion und des erwarteten Ergebnisses verwendet, wird für die Definition eingesetzt. Da es sich um reinen Text handelt, kann die Verhaltensbeschreibung mit verschiedenen Technologien verwendet werden, darunter:\nSpecFlow für .NET Cucumber.js für JavaScript Cucumber-JVM für Java Behave für Python Ein praktisches Beispiel # Beginne mit der Spezifikation des gewünschten Verhaltens. Ein Beispiel ist eine (vereinfachte) Berechnung des Marktwerts einer Position in einem Wertpapierportfolio:\nDas BDD-Tool liest diese Spezifikation und generiert für jede Given/When/Then-Zeile eine Step Definition. Step Definitions sind Methoden im Testcode und dienen als Verbindung zu den Domänenklassen. Die Aufgabe der Entwickler ist es nun, die generierten Step Definitions basierend auf der Spezifikation zu implementieren. Die Spezifikation wird dann über den Runner des verwendeten Testframeworks ausgeführt.\nWie die Domänenklassen nahelegen, wird BDD hier für Unit Tests eingesetzt, um die Geschäftslogik zu testen. Die automatisierte Ausführung der Spezifikation ist jedoch nicht auf Unit Tests beschränkt, sondern kann auf allen Ebenen der Testpyramide eingesetzt werden. Viele BDD-Beispiele arbeiten auf Systemebene und automatisieren UI-Tests mit Selenium. Es können jedoch auch Integrationstests durchgeführt werden, um beispielsweise Daten in einer Datenbank zu erstellen oder zu verifizieren.\nDer Entwicklungsprozess # Die Spezifikationen sind in der Regel wesentlich komplexer als das vereinfachte praktische Beispiel. Deshalb wird vor dem eigentlichen Implementierungsprozess ein Solution Design (SD) erstellt. Dieses SD beschreibt unter anderem die Ist-Situation, die Soll-Situation und die Implementierungsschritte (Stories). Das Schlüsselelement ist die Spezifikation in Gherkin. Ausgehend von der User Story für das Solution Design wird diese Spezifikation ständig erweitert und verfeinert. Die Spezifikation ist auch ein Schlüsselelement in den Reviews, um die Anforderungen und die aktuelle Implementierung zu überprüfen.\nBehaviour-Driven Development (BDD) mit der Spezifikation des Anwendungsverhaltens in Gherkin ist ein empfehlenswerter Schritt für die automatisierte Prüfung komplexer fachlicher Anforderungen. Da die ausführbare Spezifikation bereits zu Beginn der Entwicklungsarbeit vorliegt, lässt sich Test-Driven Development (TDD) einfach umsetzen. Wenn eine Spezifikation konsistent sein soll, müssen alle am Entwicklungsprozess Beteiligten eine gemeinsame Sprache verwenden. Deshalb ist Domain-Driven Design (DDD) mit einem zentralen und dokumentierten Domänenmodell eine gute Grundlage.\nDank Behaviour-Driven Development (BDD) und einer automatisierten Build- und Deployment-Pipeline können Organisationen sowohl die Feedback-Zyklen als auch die Durchsatzgeschwindigkeit erhöhen. So können sie schneller reagieren und ihre Kunden mit ständigen Innovationen beeindrucken. Dank DevOps werden Prozesse von der Entwicklung über das Release bis zum Betrieb automatisiert und optimiert. Das steigert die Effizienz, was wiederum die mit Änderungen verbundenen Kosten senkt.\nOriginalbeitrag: Medium\n","date":"20. February 2021","externalUrl":null,"permalink":"/de/blogs/testautomatisierung-mit-behavior-driven-development-bdd/","section":"Blogs","summary":"Die Automatisierung von Tests ist eine komplexe und anspruchsvolle Aufgabe. Der iterative Ansatz im Entwicklungsprozess bedeutet auch, dass die automatisierten Tests kontinuierlich angepasst werden müssen. Behaviour-Driven Development (BDD) kann eingesetzt werden, um die Testautomatisierung zu vereinfachen und zu beschleunigen.\n","title":"Testautomatisierung mit Behavior-Driven Development (BDD)","type":"blogs"},{"content":"Was passiert, wenn man den Flug, den Stau und die Zoom-Müdigkeit einfach überspringt und einen Kollegen in einem virtuellen Büro auf einem anderen Kontinent trifft? In dieser Folge steige ich in VR ein und besuche Michele bei BCVR. Ein Klick, und ich stehe neben ihm in Chicago, Kaffee in der Hand, schaue mir Diagramme an der Wand an und erlebe, was Arbeiten, Trainieren und Zusammenarbeiten im Metaverse wirklich bedeutet. Das ist keine Demo eines Gaming-Gadgets. Das ist ein ernsthaftes Business-Umfeld, das sich schon 2021 erstaunlich nah an der Zukunft der Arbeit anfühlt.\nAnkommen mit einem Klick: Präsenz statt Pixel # Das Erste, was mir beim Aufsetzen des Headsets auffällt, ist, wie schnell das Gefühl von Distanz verschwindet. Ich sitze an meinem Schreibtisch in der Schweiz, Michele ist in München, und trotzdem stehen wir nebeneinander in einem hellen, grosszügigen Raum in Chicago. Er reicht mir einen Cappuccino. Er ist noch warm, zumindest in der Logik dieses Raums.\nWas das Ganze von Teams oder Zoom unterscheidet, sind nicht die Visuals, sondern das Gefühl von Präsenz. Micheles Stimme wird lauter, wenn er näher kommt, und leiser, wenn er sich entfernt, genau wie im echten Leben. Ich höre ihn von links, ich höre ihn von rechts, und mein Gehirn reagiert, als stünde tatsächlich jemand neben mir. Das Feedback der Teilnehmenden, die für Trainings in diesen Raum kommen, zeigt dasselbe Muster: Sie sagen, sie fühlten sich nah an ihrem Arbeitskollegen, nicht wie beim Starren auf ein 2D-Gesicht in einem flachen Rechteck.\nGenau diese kleinen physischen Signale, Position, Nähe, Richtung, machen aus einem Video-Call ein Meeting, an das man sich tatsächlich erinnert.\nDie Rückkehr des Kaffeemaschinen-Gesprächs # Was uns beiden in der Pandemie am meisten fehlt, ist das Informelle. Das kurze Gespräch an der Kaffeemaschine. Der schnelle Ideenaustausch im Gang. Die Frage, für die man nie ein Meeting ansetzen würde, die aber oft ein ganzes Projekt verändert.\nTeams und Zoom haben diese Schicht weitgehend getötet. Der formelle Informationsfluss funktioniert, Chef zu Team und zurück, aber der informelle Austausch ist weg. Michele und ich sprechen darüber, während wir im virtuellen Raum herumlaufen. Und genau das ist der Punkt: Weil man läuft, weil man sich in einem geteilten Raum begegnet, kommt diese informelle Schicht leise zurück.\nFür mich, der seit dem frühen Morgen vor dem Laptop sitzt, war das der überraschendste Teil. Aufstehen, herumlaufen, mit einem echten Menschen reden, der vor einem steht, auch wenn er virtuell ist, fühlt sich einfach besser an als noch ein flacher Video-Call.\nRaus aus dem Schlafzimmer # Michele erzählt mir von einer Person, deren Wohnung so klein ist, dass der Schreibtisch im Schlafbereich steht. Sie steht morgens auf, zieht etwas für Teams Präsentables an, arbeitet den ganzen Tag und geht abends zwei Schritte weiter ins Bett. Zwischen Arbeit und Freizeit ändert sich praktisch nichts in der Umgebung.\nVR ist keine Lösung für Wohnraum, aber sie ist ein Weg aus diesem Zimmer, zumindest mental. In dem Moment, in dem du einen weiten virtuellen Raum betrittst, mit Tiefe, Licht und Aussicht, registriert dein Gehirn einen echten Ortswechsel. Du läufst, du schaust dich um, du interagierst mit Objekten. Für hybrid und remote Arbeitende, die in kleinen Wohnungen oder dauerhaft dunklen Räumen leben, ist dieser Wechsel wichtiger, als es klingt.\nMichele wechselt uns in einen klassischen Trainingsraum mit Panoramablick über Österreich. In der Schweiz ist es Nachmittag, draussen wird es bereits dunkel, hier drinnen ist das Licht hell und warm. Allein dieser Kontrast verändert, wie ich mich im Gespräch fühle.\nEchte Zusammenarbeit: Whiteboards, Diagramme und PI Planning # Die nächste Frage war für mich naheliegend: Taugt das wirklich für ernsthafte Arbeit, oder ist es nur eine schöne Kulisse?\nMichele geht zu einem Whiteboard. Sobald er sich nähert, erscheint ein Stift in seiner Hand. Er skizziert ein Klassendiagramm, wir fügen Kommentare dazu, wir heften Post-its an einen virtuellen Tisch. Er zeigt mir, wie bestehende Dokumente von einem gemeinsamen Laufwerk in den Raum geholt, gemeinsam annotiert und wieder exportiert werden können. PDFs funktionieren gut, weil sie leichtgewichtig sind. PowerPoint lässt sich zeigen, aber nicht direkt im Raum bearbeiten. Bei Word ist es ähnlich. Diese Grenzen sind real, aber wie Michele sagt: \u0026ldquo;Es ist nur eine Frage der Zeit, die Entwicklung geht gerade sehr schnell.\u0026rdquo;\nDann zeigt er mir etwas, das mich wirklich beeindruckt. Er lässt ein paar 3D-Objekte in den Raum fallen, beschriftet eines mit \u0026ldquo;Interest\u0026rdquo;, dupliziert es, beschriftet das nächste mit \u0026ldquo;Buying\u0026rdquo;, verbindet sie mit einem animierten Pfeil, und plötzlich stehen wir in einem Prozessdiagramm, um das wir herumlaufen können. Für Architekturdiskussionen, Organigramme und Prozessdesign ist das eine andere Kategorie von Zusammenarbeit. Du schaust dir ein Diagramm nicht mehr nur an, du stehst mittendrin.\nMichele erwähnt ausserdem, dass sie in diesen Räumen SAFe-artige Planungssessions mit etwa 40 Personen durchführen. Wenn sich alle versammeln, wird es laut, dann zieht sich jede Gruppe in ihre Ecke zurück, und der Klang wird mit der Distanz ganz natürlich leiser. Das kann kein 2D-Tool in dieser Intensität abbilden.\nJenseits des Büros: Warum Raum unendlich wird # Irgendwann führt mich Michele nach draussen, auf einen virtuellen Campus. Strahlender Sonnenschein, offener Himmel. Er platziert Palmen mit einem Klick, dann Liegestühle, für jeden von uns einen. Wir reden weiter, aber die Umgebung hat sich vom Konferenzraum in etwas verwandelt, das sich wie eine kurze Pause anfühlt.\nHinter diesem verspielten Moment steht eine ernste Business-Frage: Was macht man mit grossen, leeren Büroflächen, wenn die meisten Mitarbeitenden remote arbeiten? In der Pandemie wurde ein Grossteil der Bürofläche in Konzernen zu totem Kapital. Einige Organisationen, mit denen Michele gesprochen hat, denken darüber nach, Teile dieser Flächen in VR-Büros zu verwandeln: kleinere physische Footprints, dafür ausgerüstet, um mit Kolleginnen und Kollegen weltweit in riesige virtuelle Räume einzutauchen.\nWie Michele augenzwinkernd sagt, hat man im VR bereits mehr Fläche als jedes Grossunternehmen, weil sich Räume beliebig vervielfältigen lassen. Genau das ist der Punkt. Im Metaverse hören Quadratmeter auf, eine Restriktion zu sein.\nDie S.L.H-Ära: Smartphone, Laptop, Headset # Wir landen natürlich bei der Frage nach der Zukunft. Michele ist überzeugt, dass in fünf Jahren die meisten Wissensarbeiter regelmässig in VR Meetings haben werden und dass sich Headsets zu Brillen weiterentwickeln. Ich teile eine Perspektive, über die ich mit Paul einen kurzen Blog-Artikel geschrieben habe: die kommende Ära des S.L.H-Mitarbeiters. S für Smartphone, L für Laptop, H für Headset. Je nachdem, was du gerade tun willst, greifst du zu einem der drei. Eine kurze Nachricht auf dem Smartphone, fokussierte Arbeit am Laptop, kollaborative und immersive Arbeit im Headset.\nDas ist keine Science-Fiction. Mit neuen Oculus-Generationen, mit Apple und Samsung, die in den Markt einsteigen, bewegen sich Auflösung, Komfort und Interaktionsqualität rasant. Michele rechnet damit, dass die neue Normalität für Early-Adopter-Unternehmen innerhalb von 18 bis 24 Monaten da ist. Genau deshalb habe ich mir jetzt mein eigenes Headset gekauft: Man braucht Zeit, um sich mit dem Interaktionsmodell, dem Gefühl und der Etikette vertraut zu machen. Wer erst einsteigt, wenn alle anderen schon drin sind, startet die Lernkurve zu spät.\nEs ist kein Spiel, es ist Business # Das grösste Missverständnis über VR heute ist die Verbindung mit Gaming. Ja, die Technologie ist im Gaming gross geworden. Ja, sie wirkt verspielt. Aber genau die Psychologie dahinter ist der Grund, warum sie im Business so gut funktioniert. Wir wissen aus der Forschung, dass Menschen in einem spielerischen, immersiven Zustand schneller lernen und Inhalte länger behalten. Freude und Arbeit sind keine Gegensätze, sie verstärken sich gegenseitig.\nWas ich mit Michele erlebt habe, war keine Unterhaltung. Es war eine Arbeitssession mit Whiteboards, Diagrammen, Prozessen und einem Strategiegespräch, einfach in einer Umgebung, die all das lebendiger und einprägsamer gemacht hat. Die Aufgabe der Branche ist, genau das klar zu kommunizieren: Es geht nicht um Ballern und Rennen, es geht um Austausch, Gestaltung und gemeinsames Erleben.\nUnd wer einmal drin war, braucht keine weiteren Argumente. Alle, die ich bisher in einen solchen Raum habe einsteigen sehen, kommen mit derselben Reaktion heraus: Wow, das ist einfach, und das wird verändern, wie wir arbeiten.\nWichtigste Erkenntnisse # Präsenz schlägt Pixel. Räumlicher Klang, Bewegung, Nähe und ein geteilter 3D-Raum machen aus einem Meeting etwas, das dein Gehirn als real verarbeitet. Das ist das Fundament, auf dem alles andere aufbaut.\nHol die informelle Ebene zurück. Der am meisten unterschätzte Vorteil von VR-Kollaboration ist die Rückkehr von Kaffeemaschinen-Gesprächen, Gang-Plaudereien und spontanem Austausch, den Teams und Zoom leise zerstört haben.\nNutze VR dort, wo 2D-Tools an ihre Grenzen kommen. Whiteboards, Architekturdiagramme, Prozessdesign, Big-Room-Planning mit Dutzenden Teilnehmenden: Das sind die Use Cases, in denen VR flache Tools heute klar schlägt.\nDenke Bürofläche neu. Leere Konzernflächen sind totes Kapital. Kleinere physische Hubs in Kombination mit geteilten VR-Umgebungen können grosse Büro-Footprints ersetzen und Teams mehr Raum geben, nicht weniger.\nBereite dich auf die S.L.H-Ära vor. Plane mit einer Belegschaft, die fliessend zwischen Smartphone, Laptop und Headset wechselt. Je früher deine Organisation diesen Muskel aufbaut, desto geschmeidiger wird der Übergang.\nFang jetzt an zu experimentieren. Die Lernkurve ist real: Interaktion, Etikette, Tool-Beherrschung. Wer heute beginnt, verschafft sich einen klaren Vorsprung, wenn VR in den nächsten 18 bis 24 Monaten zur neuen Normalität wird.\n","date":"9. February 2021","externalUrl":null,"permalink":"/de/blogs/business-meetings-im-metaverse/","section":"Blogs","summary":"Was passiert, wenn man den Flug, den Stau und die Zoom-Müdigkeit einfach überspringt und einen Kollegen in einem virtuellen Büro auf einem anderen Kontinent trifft? In dieser Folge steige ich in VR ein und besuche Michele bei BCVR. Ein Klick, und ich stehe neben ihm in Chicago, Kaffee in der Hand, schaue mir Diagramme an der Wand an und erlebe, was Arbeiten, Trainieren und Zusammenarbeiten im Metaverse wirklich bedeutet. Das ist keine Demo eines Gaming-Gadgets. Das ist ein ernsthaftes Business-Umfeld, das sich schon 2021 erstaunlich nah an der Zukunft der Arbeit anfühlt.\n","title":"Business Meetings im Metaverse: Das ist kein Spiel, hier ist der Beweis","type":"blogs"},{"content":"What happens when you skip the plane, the traffic and the Zoom fatigue and simply meet a colleague in a virtual office on another continent? In this conversation, I jump into VR to visit Michele at BCVR. Within a click I am standing next to him in Chicago, coffee in hand, looking over diagrams on the wall and exploring what it really means to work, train and collaborate in the Metaverse. This is not a demo of a gaming toy. It is a look at a serious business environment that, even in 2021, already feels remarkably close to the future of work.\nArriving in a Click: Presence Instead of Pixels # The first thing that strikes me when I put on the headset is how quickly the idea of distance disappears. I am sitting at my desk in Switzerland, Michele is in Munich, and yet we are standing next to each other in a bright, spacious room in Chicago. He hands me a cappuccino. It is still warm, at least in the logic of the space.\nWhat makes this different from Teams or Zoom is not the visuals, it is the sense of presence. Michele\u0026rsquo;s voice gets louder as he walks closer to me and softer as he moves away, exactly like in real life. I can hear him from my left, I can hear him from my right, and my brain reacts as if someone were actually standing beside me. Feedback from people who join trainings in this environment points in the same direction: they say they feel close to their working partner, not like they are staring at a 2D face behind a flat rectangle.\nThat small physical cue, position, proximity, direction, is what turns a video call into a meeting you actually remember.\nThe Return of the Coffee Machine Chat # One thing we both miss most in the pandemic is the informal side of office life. The two-minute conversation at the coffee machine. The quick exchange of ideas in a hallway. The question you would never schedule a meeting for but that often changes a project.\nTeams and Zoom have mostly killed that layer. We have the formal information flow, boss to team and back, but the informal flow has collapsed. Michele and I talk about this while walking around the virtual room. And that is exactly the point. Because you walk, because you bump into each other in a shared space, the informal layer quietly comes back.\nFor me, sitting in front of a laptop since early morning, this was the most surprising part. Standing up, walking around, talking to a real person in front of me, even a virtual one, simply feels better than yet another flat video call.\nGetting People Out of Their Bedroom # Michele tells me about one participant whose apartment is so small that his desk stands in his sleeping area. He wakes up, puts on something presentable for Teams, works a full day, and at night goes back to bed two steps away. Nothing in his environment changes between work and rest.\nVR is not a solution for housing, but it is a way out of that room, at least mentally. The moment you step into a wide virtual space, with depth, light and a view, your brain registers a real change of location. You walk, you look around, you interact with objects. For hybrid and remote workers who live in small spaces or in permanently dim rooms, that shift matters more than it might sound.\nMichele switches us into a classical training room with a panoramic view over Austria. It is mid-afternoon in Switzerland, already getting dark outside my real window, but here the light is bright and warm. That contrast alone changes how I feel in the conversation.\nReal Collaboration: Whiteboards, Diagrams and PI Planning # The next question I had was obvious. Is this actually useful for serious work, or just a nice backdrop?\nMichele walks to a whiteboard. As he approaches, a pen appears in his hand. He starts sketching a class diagram, we add comments, we attach post-it notes to a virtual table. He demonstrates how existing documents from a shared drive can be pulled into the room, annotated together and taken back out. PDFs work well because they are lightweight. PowerPoints can be shown but not edited inside the room yet. Word is similar. These limitations are real, but as Michele puts it, \u0026ldquo;it\u0026rsquo;s a matter of time as the things are evolving quite strong and quite fast.\u0026rdquo;\nThen he shows me something I find genuinely impressive. He drops a few 3D objects into the room, labels one \u0026ldquo;interest\u0026rdquo;, duplicates it, labels the next one \u0026ldquo;buying\u0026rdquo;, connects them with an animated arrow, and suddenly we are standing inside a process diagram we can walk around. For architectural discussions, for organizational charts, for process design, this is a different category of collaboration. You do not just look at a diagram, you stand inside it.\nHe also mentions that they run SAFe-style planning sessions in these rooms, with around 40 people. It gets loud when everyone gathers, then each group moves into its own area and the sound naturally fades with distance. That is something no 2D tool can replicate with the same intensity.\nBeyond the Office: Why Space Becomes Infinite # At some point Michele takes us outside, onto a virtual campus. Bright sun, open sky. He adds palm trees with a click, then deck chairs, one for each of us. We keep talking, but the environment has shifted from a conference room to something that feels like a short break.\nBehind that playful moment sits a serious business question. What do you do with large, empty physical office spaces when most of your people work remotely? During the pandemic, a lot of floor space in corporate buildings turned into dead capital. Some of the organizations Michele has spoken to are thinking about turning parts of those rooms into VR offices: smaller physical footprints, equipped so that people can step into huge shared virtual spaces with colleagues around the world.\nAs Michele jokes, they already have more space than any big company, because they can multiply rooms as often as they want. That is the point. In the Metaverse, square meters stop being a constraint.\nThe S.L.H Era: Smartphone, Laptop, Headset # We naturally end up talking about the future. Michele is convinced that within five years, most knowledge workers will routinely meet in VR, and that headsets will evolve into glasses. I share a perspective I wrote about with Paul in a short article: the coming age of the S.L.H employee. S for smartphone, L for laptop, H for headset. Depending on what you need to do, you pick up one of the three. A quick message on the phone, focused work on the laptop, collaborative and immersive work in the headset.\nThis is not science fiction. With new generations of Oculus hardware, with Apple and Samsung entering the space, resolution, comfort and interaction quality are moving fast. Michele expects the new normal to arrive within the next 18 to 24 months for early-adopting companies. That is why I bought my own headset: you need time to get comfortable with the interaction model, with the feel, with the etiquette. Waiting until everybody else is already there means starting the learning curve too late.\nIt\u0026rsquo;s Not a Game, It\u0026rsquo;s Business # The biggest misunderstanding about VR today is the association with gaming. Yes, the technology grew up in gaming. Yes, it looks playful. But the psychology behind it is exactly the reason it works so well for business. We know from research that when people learn in a playful, immersive state, they absorb content faster and retain it longer. Joy and work are not opposites, they amplify each other.\nWhat I experienced with Michele was not entertainment. It was a working session with whiteboards, diagrams, processes and a conversation about strategy, just in an environment that made all of it more engaging and more memorable. The challenge for the industry is to communicate that clearly: this is not about shooting and running, it is about exchanging, designing and experiencing together.\nAnd once you have been in, the argument makes itself. Everyone I have seen step into a space like this comes out with the same reaction: wow, this is easy, and this is going to change how we work.\nKey Takeaways # Presence beats pixels. Spatial audio, walking, proximity and a shared 3D space turn a meeting from a video call into something your brain treats as real. That is the foundation everything else is built on.\nBring back the informal layer. The most underrated benefit of VR collaboration is the return of coffee-machine conversations, hallway chats and spontaneous exchanges that Teams and Zoom have quietly killed.\nUse VR where 2D tools hit their limits. Whiteboards, architectural diagrams, process design, big-room planning with dozens of people: these are the use cases where VR clearly outperforms flat tools today.\nRethink physical office space. Empty corporate floors are dead capital. Smaller physical hubs combined with shared VR environments can replace large office footprints and give teams more space, not less.\nPrepare for the S.L.H era. Plan for a workforce that switches fluidly between smartphone, laptop and headset. The sooner your organization builds that muscle, the smoother the transition will be.\nStart experimenting now. The learning curve is real: interaction, etiquette, tool fluency. Companies and individuals who begin today will have a clear advantage when VR becomes the new normal over the next 18 to 24 months.\n","date":"9 February 2021","externalUrl":null,"permalink":"/en/blogs/business-meetings-in-the-metaverse/","section":"Blogs","summary":"What happens when you skip the plane, the traffic and the Zoom fatigue and simply meet a colleague in a virtual office on another continent? In this conversation, I jump into VR to visit Michele at BCVR. Within a click I am standing next to him in Chicago, coffee in hand, looking over diagrams on the wall and exploring what it really means to work, train and collaborate in the Metaverse. This is not a demo of a gaming toy. It is a look at a serious business environment that, even in 2021, already feels remarkably close to the future of work.\n","title":"Business Meetings in the Metaverse: It's Not a Game, Here's Why","type":"blogs"},{"content":"","date":"9 February 2021","externalUrl":null,"permalink":"/en/tags/remote-work/","section":"Tags","summary":"","title":"Remote Work","type":"tags"},{"content":"","date":"2 February 2021","externalUrl":null,"permalink":"/en/tags/extreme-programming/","section":"Tags","summary":"","title":"Extreme Programming","type":"tags"},{"content":"Was genau ist TDD oder Test-Driven Development, und warum schwören so viele erfahrene Entwickler darauf? In diesem kurzen Video erkläre ich, woher TDD kommt, wie der Red-Green-Refactor-Zyklus funktioniert, und ich zeige an einem einfachen Calculator-Beispiel in C#, wie der Prozess in der Praxis aussieht. TDD ist nicht nur eine Entwicklungstechnik, sondern ein Mindset, das prägt, wie man an jede Zeile Code herangeht.\nTDD steht für Test-Driven Development # TDD steht für Test-Driven Development und wird auch als Test-First-Ansatz bezeichnet. Es ist ein Softwareentwicklungsprozess, den wir im agilen Kontext einsetzen, um Software zu entwickeln. TDD tauchte 1999 zum ersten Mal im Rahmen von Extreme Programming auf und hat sich von dort als Grundpfeiler moderner Engineering-Praktiken in der ganzen Industrie etabliert.\nAber TDD ist nicht nur ein Prozess. Es ist auch ein Mindset. Die Kernidee ist einfach: Das Erste, was du immer machst, wenn du Code anfasst, ist einen Test zu schreiben. Egal ob du ein neues Feature baust oder einen Bug fixst, der Test kommt zuerst. Alles andere folgt daraus.\nDer Red-Green-Refactor-Zyklus # Der TDD-Zyklus ist simpel, und sobald man ihn verinnerlicht hat, läuft er fast automatisch. Wenn du neue Funktionalität bauen oder einen Bug fixen willst, schreibst du als Erstes einen Test. Sobald der Test geschrieben ist, führst du ihn aus und siehst einen roten Test. Das ist erwartet, denn hinter dem, was du gerade geschrieben hast, steckt ja noch keine Funktionalität.\nDanach schreibst du die Funktionalität, die den Test grün macht. Jetzt hast du einen grünen Test. Damit gehst du in den Refactoring-Schritt. Im Refactoring räumst du den Code auf und führst die Tests erneut aus, um zu sehen, ob dein Refactoring nichts kaputt gemacht hat. Und dann schreibst du den nächsten Test für die nächste Funktionalität, und den nächsten, und den nächsten. So funktioniert Test-Driven Development.\nDieser Loop wirkt trügerisch einfach, aber er hat eine enorme Wirkung. Jede Zeile Produktionscode ist durch einen Test abgedeckt, der gezeigt hat, dass sie überhaupt nötig war. Der Code bleibt sauber, weil Refactoring sicher ist, und du baust nie Funktionalität, die niemand verlangt hat.\nTDD in Aktion: Ein einfacher Calculator # Lass mich das an einem konkreten Codebeispiel zeigen. Im Video nutze ich Visual Studio mit C#, aber TDD funktioniert mit jeder IDE und jeder Programmiersprache. Die Aufgabe ist, einen Calculator zu implementieren, konkret eine Methode, die zwei Zahlen addiert.\nIch starte mit einer Calculator-Testklasse und einer Testmethode, die prüft, ob die Add-Methode die Zahlen korrekt summiert. Ich strukturiere den Test mit Kommentaren für Arrange, Act und Assert. Im Arrange erzeuge ich einen neuen Calculator, obwohl die Klasse noch gar nicht existiert. Im Act rufe ich die Add-Methode mit eins plus eins auf. Im Assert prüfe ich, ob das Ergebnis gleich zwei ist.\nWenn ich den Test ausführe, bekomme ich einen Build-Fehler, weil die Calculator-Klasse noch nicht existiert. Das ist in Ordnung. Ich lege die Calculator-Klasse an und führe die Tests erneut aus. Der nächste Fehler: Die Add-Methode fehlt. Ich generiere die Add-Methode, führe die Tests erneut aus, der Build läuft nun, aber der Test ist rot, weil die generierte Methode eine NotImplementedException wirft. Ich gehe in den Calculator, ersetze die Exception durch ein return v1 plus v2 und führe die Tests noch einmal aus. Grün.\nMit grünen Tests gehe ich in den Refactoring-Schritt. Im Video überspringe ich diesen Teil, aber in der Praxis würde man hier Namen bereinigen, Return-Typen anpassen und Duplikationen entfernen. Danach kommt der nächste Test, und der nächste, und der nächste.\nWarum das Mindset wichtiger ist als die Mechanik # Die Mechanik von TDD ist schnell gelernt. Was länger dauert, ist die Mindset-Veränderung. Den Test zuerst zu schreiben zwingt dich, über das Interface deines Codes nachzudenken, bevor du über die Implementierung nachdenkst. Es zwingt dich, präzise zu spezifizieren, was der Code leisten soll. Und es gibt dir sofortiges Feedback: In dem Moment, in dem du nicht mehr verstehst, was du baust, sagt es dir der Test.\nGenau deshalb ist TDD für mich ein Grundpfeiler von sauberem Software Engineering. Es verhindert, dass du Code ausliefertst, den niemand verifiziert hat, es hält dein Design modular, weil Tests gegen verwobenen Code schmerzhaft zu schreiben sind, und es gibt dir die Sicherheit, mutig zu refactoren.\nMeine Empfehlung # TDD ist absolut grossartig, und ich kann es nur wärmstens empfehlen. Schreib keinen Code, ohne vorher einen Test zu schreiben. Am Anfang braucht das Disziplin, und die ersten Tage fühlt es sich langsamer an. Aber sobald die Gewohnheit sitzt, produzierst du die Bugs nicht mehr, die du früher produziert hast, dein Design verbessert sich, und du baust dir ein Sicherheitsnetz, das dich durch jede zukünftige Änderung trägt.\nWichtigste Erkenntnisse # Test zuerst, immer. Bevor du eine einzige Zeile Produktionscode schreibst, schreibst du den Test, der beschreibt, was dieser Code leisten soll. Der Test kommt zuerst, jedes Mal.\nHalte dich an Red-Green-Refactor. Rot: schreibe einen fehlschlagenden Test. Grün: schreibe den minimalen Code, der ihn erfüllt. Refactor: räume auf, ohne die Tests zu brechen. Dann von vorn.\nTDD ist ein Mindset, nicht nur ein Prozess. Es prägt, wie du über Code denkst. Jede Änderung beginnt mit einem Test, egal ob neues Feature oder Bugfix.\nKleine Schritte machen. Im Calculator-Beispiel war jeder Schritt winzig: fehlende Klasse, fehlende Methode, NotImplementedException, echte Implementierung. Kleine Schritte bedeuten schnelles Feedback.\nRefactoring mit Vertrauen. Grüne Tests sind dein Sicherheitsnetz. Sobald du ihnen vertraust, kannst du Namen, Strukturen und Design verbessern, ohne Angst vor kaputtem Verhalten.\nTDD funktioniert mit jeder Sprache und jeder IDE. Das Beispiel nutzt C# in Visual Studio, aber der gleiche Zyklus gilt für jede Sprache, jedes Framework und jede Domäne. Das Prinzip ist universell.\n","date":"2. February 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-tdd/","section":"Blogs","summary":"Was genau ist TDD oder Test-Driven Development, und warum schwören so viele erfahrene Entwickler darauf? In diesem kurzen Video erkläre ich, woher TDD kommt, wie der Red-Green-Refactor-Zyklus funktioniert, und ich zeige an einem einfachen Calculator-Beispiel in C#, wie der Prozess in der Praxis aussieht. TDD ist nicht nur eine Entwicklungstechnik, sondern ein Mindset, das prägt, wie man an jede Zeile Code herangeht.\n","title":"Was ist TDD? Test-Driven Development erklärt","type":"blogs"},{"content":"What exactly is TDD or Test-Driven Development, and why do so many experienced engineers swear by it? In this short video I explain where TDD comes from, how the red-green-refactor cycle works, and I walk through a simple C# calculator example that shows the process in action. TDD is not only a development technique, it is a mindset that shapes how you approach every line of code.\nTDD Stands for Test-Driven Development # TDD stands for Test-Driven Development. It is also known as the test first approach. It is a software development process that we use to develop software in an agile context. The first appearance TDD made was in 1999 within Extreme Programming, and from there it spread across the industry as a cornerstone of modern engineering practice.\nBut TDD is not only a process. It is also a mindset. The core idea is simple: the first thing you always do when you are going to touch code is to write a test. Whether you are adding a new feature or fixing a bug, the test comes first. Everything else follows from there.\nThe Red-Green-Refactor Cycle # The TDD cycle is straightforward, and once you internalize it, it becomes second nature. When you are about to write new functionality or fix a bug, the first thing you do is write a test. As soon as you have written the test, you execute it and you will see a red test. That is expected, because there is no functionality behind what you just wrote.\nThen you write the functionality that makes this test pass, and you get a green test. With that you move into the refactoring step. In the refactoring step you clean up the code and execute the tests again to see if your refactoring has not broken anything. And then you write another test for another functionality, and another, and another. That is how Test-Driven Development works.\nThis loop is deceptively simple, but it has a huge effect. Every piece of production code you write is backed by a test that proved it was needed. Your code stays clean because refactoring is safe, and you never accumulate functionality that nobody asked for.\nTDD in Action: A Simple Calculator # Let me show you how TDD works with a real code example. In the video I use Visual Studio with C#, but TDD can be used with any IDE and any programming language. The task is to implement a calculator, specifically a method that adds two numbers.\nI start by creating a calculator test class with a test method that will check if the add method sums up the numbers correctly. I structure the test with comments for arrange, act, and assert. In the arrange step I create a new calculator instance, even though the calculator class does not exist yet. In the act step I call the add method with one plus one. In the assert step I check that the result equals two.\nWhen I run the test, I get a build error because the calculator class does not exist. That is fine. I create the calculator class and run the tests again. Now I get another error because the add method is not there. I generate the add method, run the tests again, and now the build works, but the test fails because the generated method throws a not-implemented exception. I go into the calculator, replace the exception with a return of v1 plus v2, and run the tests one more time. Green.\nWith green tests in place, I move into the refactoring step. I skip that in the video, but in practice you would clean up names, return types, and any duplication. Then you add the next test, and the next, and the next.\nWhy the Mindset Matters More Than the Mechanics # The mechanics of TDD are easy to learn. What takes longer is the mindset shift. Writing the test first forces you to think about the interface of your code before you think about the implementation. It forces you to specify precisely what you want your code to do. And it gives you immediate feedback: the moment you stop understanding what you are building, the test tells you.\nThis is why I consider TDD a cornerstone of clean software engineering. It prevents you from shipping code nobody verified, it keeps your design modular because tests are painful to write against tangled code, and it gives you the confidence to refactor aggressively.\nMy Recommendation # TDD is absolutely great and I can highly recommend it. Don\u0026rsquo;t write any code without writing a test first. It takes discipline at the beginning, and it feels slower for the first few days. But once the habit is there, you stop producing the bugs you used to produce, your design improves, and you build a safety net that carries you through every future change.\nKey Takeaways # Test first, always. Before you write a single line of production code, write the test that describes what that code should do. The test comes first, every time.\nFollow the red-green-refactor cycle. Red: write a failing test. Green: write the minimum code to pass it. Refactor: clean up without breaking tests. Then repeat.\nTDD is a mindset, not just a process. It shapes how you think about code. Every change starts with a test, whether it is a new feature or a bug fix.\nKeep steps small. In the calculator example, every step was tiny: missing class, missing method, not-implemented exception, real implementation. Small steps mean fast feedback.\nRefactor with confidence. Green tests are your safety net. Once you trust them, you can improve names, structure, and design without fear of breaking behavior.\nTDD works with any language or IDE. The example uses C# in Visual Studio, but the same cycle applies to any language, any framework, and any domain. The principle is universal.\n","date":"2 February 2021","externalUrl":null,"permalink":"/en/blogs/what-is-tdd/","section":"Blogs","summary":"What exactly is TDD or Test-Driven Development, and why do so many experienced engineers swear by it? In this short video I explain where TDD comes from, how the red-green-refactor cycle works, and I walk through a simple C# calculator example that shows the process in action. TDD is not only a development technique, it is a mindset that shapes how you approach every line of code.\n","title":"What is TDD? Test-Driven Development Explained","type":"blogs"},{"content":"","date":"27 January 2021","externalUrl":null,"permalink":"/en/tags/test-strategy/","section":"Tags","summary":"","title":"Test Strategy","type":"tags"},{"content":"","date":"27. January 2021","externalUrl":null,"permalink":"/de/tags/teststrategie/","section":"Tags","summary":"","title":"Teststrategie","type":"tags"},{"content":" Wenn wir über traditionelles Testen sprechen, meinen wir das V-Modell, das in Wasserfall-Projekten verwendet wird. Wir betreiben Requirements Engineering, schreiben Features für unsere Software nieder, brechen diese dann herunter und schreiben Stories, die anschliessend den Entwicklern zur Umsetzung übergeben werden. Der Entwickler setzt dies in Code um und schreibt dann Unit Tests und Integrationstests.\nWenn er fertig ist, übergibt er die Story an Tester, die sie testen. Nachdem alle Tests entwickelt wurden, werden die Features getestet.\nDas Problem bei diesem traditionellen Ansatz ist das verzögerte Feedback. Nach dem Schreiben der Features dauert es 3 Monate oder länger, bis wir Feedback erhalten.\nBeim agilen Testen verschieben wir das gesamte Testen nach links. Wir verwenden BDD (Behaviour-Driven Development), um die Akzeptanzkriterien bereits beim Schreiben eines Features zu definieren. Wir brechen das Feature in User Stories herunter, bei denen die Akzeptanzkriterien ebenfalls mit BDD geschrieben werden. Dadurch erhalten wir ausführbare Spezifikationen. Der Entwickler kann dann zuerst die als Akzeptanzkriterien in der User Story spezifizierten Tests verwenden, bevor er mit der Implementierung der Funktionalität beginnt.\nAuf diese Weise haben wir Tests auf Story- und Feature-Ebene von Anfang an. In unserer Continuous-Delivery-Pipeline können wir die Tests ausführen, die den Entwicklern bestätigen, dass nichts kaputt gegangen ist. Das führt zu einer schnelleren Time-to-Market.\n","date":"27. January 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-der-unterschied-zwischen-traditionellem-testen-und-agilem-testen/","section":"Blogs","summary":" Wenn wir über traditionelles Testen sprechen, meinen wir das V-Modell, das in Wasserfall-Projekten verwendet wird. Wir betreiben Requirements Engineering, schreiben Features für unsere Software nieder, brechen diese dann herunter und schreiben Stories, die anschliessend den Entwicklern zur Umsetzung übergeben werden. Der Entwickler setzt dies in Code um und schreibt dann Unit Tests und Integrationstests.\n","title":"Was ist der Unterschied zwischen traditionellem Testen und agilem Testen?","type":"blogs"},{"content":" When we are talking about traditional testing, we are talking about the V-model which is used in waterfall projects. We do requirement engineering, we write down features for our software, then we break them down and then write stories which are then given to the developer to implement this story. The developer then codifies this and then writes unite tests and integration tests.\nWhen he is done, he gives the story to testers who test it. After all the tests have been developed then the features are tested.\nThe problem with this traditional approach is that there is delayed feedback. After writing the features, it takes 3 months or more until we get feedback.\nIn agile testing, we shift the whole testing left. We use BDD (behaviour driven development) for defining the acceptance criteria when we are writing a feature. We break down the feature into user stories where again the acceptance criteria are written using BDD. By doing this we get executable specifications. The developer can then first use the tests specified as acceptance criteria in the user story before he/she starts implementing the functionality.\nThis way we have tests on the story and feature level from the beginning. In our continuous delivery pipeline, we can execute the tests which assure developers that nothing has beens broken. This leads to a faster time to market.\n","date":"27 January 2021","externalUrl":null,"permalink":"/en/blogs/what-is-the-difference-between-traditional-testing-and-agile-testing/","section":"Blogs","summary":" When we are talking about traditional testing, we are talking about the V-model which is used in waterfall projects. We do requirement engineering, we write down features for our software, then we break them down and then write stories which are then given to the developer to implement this story. The developer then codifies this and then writes unite tests and integration tests.\n","title":"What is the difference between traditional testing and agile testing?","type":"blogs"},{"content":"","date":"17. January 2021","externalUrl":null,"permalink":"/de/tags/verschwendung/","section":"Tags","summary":"","title":"Verschwendung","type":"tags"},{"content":" Ich habe 9 Arten von Verschwendung 🗑 in der Softwareentwicklung identifiziert:\n🧩Unfertige Arbeit\n💲Überflüssige Features\n😤Unnötige Prozesse\n🤯Task-Wechsel\n🧟‍♀️Nicht-standardisierte Arbeit\nWelche Arten von Verschwendung hast du identifiziert?\n🧩Unfertige Arbeit: Das ist die Arbeit, die in der Pipeline liegt und noch nicht abgeschlossen ist. Das kann Code sein, der nicht committed wurde, oder Tests, die nicht ausgeführt wurden. Es bezieht sich aber auch auf Situationen, in denen wir beispielsweise ein Feature entwickeln und plötzlich die Arbeit daran stoppen müssen, um an einem anderen Feature zu arbeiten. Das ist unfertige Arbeit.\n💲Überflüssige Features: Überflüssige Features werden auch als Gold Plating bezeichnet. Das passiert, wenn der PO meint, dass \u0026ldquo;Nice-to-have\u0026rdquo;-Features von der Softwareentwicklung umgesetzt werden sollten. Sie bringen dem Kunden jedoch keinen Mehrwert und der Kunde braucht sie nicht.\n😤Unnötige Prozesse: Diese Schritte bringen keinen Kundenmehrwert, aber sie geben uns Sicherheit. Wir können diese automatisieren, aber ich spreche von den zusätzlichen Prozessen, die gebraucht werden, weil jemand einen Bericht braucht oder eben nicht braucht. Diese sind nutzlos und sollten entfernt werden.\n🤯Task-Wechsel: Wenn wir etwas tun und beispielsweise durch einen anderen Kollegen oder eine andere Aufgabe unterbrochen werden. Solches Wechseln zwingt uns dazu, Informationen in unseren Köpfen zu laden und wieder zu entladen.\n🤲Übergaben: Wenn wir etwas tun, müssen wir die Informationen an jemand anderen weitergeben. Die Informationen wandern also zu jemand anderem, wobei wir einen gewissen Informationsverlust haben. Das ist etwas, das wir minimieren oder automatisieren sollten.\n🐞Defekte: Defekte gibt es in Software, aber das ist nicht das Problem, wenn sie identifiziert werden. Es sind die Defekte, die in unserer Software versteckt sind und schnell beseitigt werden müssen, um die Qualität zu sichern.\n🧟‍♀️Nicht-standardisierte Arbeit: Es gibt Fälle, in denen manuelle Arbeit sinnvoll ist, weil der Business Case für eine Automatisierung negativ ist. Wir sollten aber immer in die Richtung gehen, dass nicht-standardisierte Arbeit eliminiert und automatisiert wird.\n😴Wartezeiten: Wartezeiten sollten reduziert werden, und dafür müssen wir unsere Wertströme analysieren. Wir können diese Wartezeiten eliminieren.\n🦸‍♀️Heldentum: Wir haben immer einen Helden in unserem Projekt, der alles lösen kann. Das Problem dabei ist, dass die Dinge, die er repariert, nicht automatisiert werden. Sich auf die eigentlichen Probleme zu konzentrieren und Elemente zu automatisieren, ist wichtiger als dieses Heldentum.\nDas sind also die neun Arten von Verschwendung in der Softwareentwicklung, die man kennen sollte.\n","date":"17. January 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-verschwendung-in-der-softwareentwicklung/","section":"Blogs","summary":" Ich habe 9 Arten von Verschwendung 🗑 in der Softwareentwicklung identifiziert:\n🧩Unfertige Arbeit\n💲Überflüssige Features\n😤Unnötige Prozesse\n🤯Task-Wechsel\n🧟‍♀️Nicht-standardisierte Arbeit\nWelche Arten von Verschwendung hast du identifiziert?\n","title":"Was ist Verschwendung 🗑 in der Softwareentwicklung?","type":"blogs"},{"content":"","date":"17 January 2021","externalUrl":null,"permalink":"/en/tags/waste/","section":"Tags","summary":"","title":"Waste","type":"tags"},{"content":" I’ve identified 9 types of waste 🗑 in Software Development:\n🧩Partially done work\n💲Extra features\n😤Extra processes\n🤯Task switching\n🧟‍♀️Nonstandard work\nWhat types of waste have you identified?\n🧩Partial work done: This is the work that sits in the pipeline and is not yet finished. This can be code that is not committed, tests that have not been executed. But it also refers to, for example, when we are doing something like developing a feature and we suddenly need to stop the work on that feature and go to another feature, this is partially done work.\n💲Extra features: Extra features are also known as gold plating. This is done when the PO thinks this is nice to have features that should be done by software development. But, it does not add any value to the customer and the customer does not need it.\n😤Extra processes: These steps do not add any customer value, but they keep you safe. We can automate these but am talking about the extra processes that are needed because someone needs a report or does not need a report. These are useless and should be removed.\n🤯Task switching: When we are doing something and we are interrupted by, for example, another colleague or another task we need to do. Such switching causes us to load and reload information in our minds.\n🤲Handoffs: When we are doing something, we need to give the information to someone else. So, the information moves to someone else, we have some loss of information during that process and this is something we should minimize or automate.\n🐞Defects: Defects are in softwares, but that is not the problem if they are identified. It is the defects that are hidden in our softwares and must be eliminated quickly for quality.\n🧟‍♀️Non-standard work: There are some cases where manual work makes sense because the business case of automating it is negative. We should always go in the direction that non-standardized work is eliminated and automated.\n😴Waiting: Waiting should be reduced and for that, we need to analyze our value chains. We can eliminate these waiting times.\n🦸‍♀️Heroics: We always have a hero in our project that can solve everything. But, the problem with that is you do not automate the things that he fixes. Focusing on root problems and automating elements is more important than these heroics.\nThus, these are the nine types of waste in software development that you should be aware of.\n","date":"17 January 2021","externalUrl":null,"permalink":"/en/blogs/what-is-waste-in-software-development/","section":"Blogs","summary":" I’ve identified 9 types of waste 🗑 in Software Development:\n🧩Partially done work\n💲Extra features\n😤Extra processes\n🤯Task switching\n🧟‍♀️Nonstandard work\n","title":"What is waste 🗑 in Software Development?","type":"blogs"},{"content":"","date":"11. January 2021","externalUrl":null,"permalink":"/de/tags/geschichte/","section":"Tags","summary":"","title":"Geschichte","type":"tags"},{"content":"","date":"11 January 2021","externalUrl":null,"permalink":"/en/tags/history/","section":"Tags","summary":"","title":"History","type":"tags"},{"content":"","date":"11 January 2021","externalUrl":null,"permalink":"/en/tags/iterative-development/","section":"Tags","summary":"","title":"Iterative Development","type":"tags"},{"content":"","date":"11. January 2021","externalUrl":null,"permalink":"/de/tags/iterative-entwicklung/","section":"Tags","summary":"","title":"Iterative Entwicklung","type":"tags"},{"content":"","date":"11. January 2021","externalUrl":null,"permalink":"/de/tags/methodenvergleich/","section":"Tags","summary":"","title":"Methodenvergleich","type":"tags"},{"content":"","date":"11 January 2021","externalUrl":null,"permalink":"/en/tags/methodology-comparison/","section":"Tags","summary":"","title":"Methodology Comparison","type":"tags"},{"content":"","date":"11 January 2021","externalUrl":null,"permalink":"/en/tags/process-models/","section":"Tags","summary":"","title":"Process Models","type":"tags"},{"content":"","date":"11. January 2021","externalUrl":null,"permalink":"/de/tags/prozessmodelle/","section":"Tags","summary":"","title":"Prozessmodelle","type":"tags"},{"content":" Der \u0026ldquo;Erfinder\u0026rdquo; des Wasserfall-Prozesses 💧 sagte 1970: \u0026ldquo;I believe in this concept, but the implementation described above is risky and invites failure.\u0026rdquo; 😱\nSchau dir mein Video an, um zu sehen, welchen bahnbrechenden 🤯 Ansatz er 1970 empfohlen hat:\nDer Wasserfall-Prozess 💧 ist ein Softwareentwicklungsprozess, der erstmals von Dr. Winston W. Royce in einem 📝 Paper von 1970 vorgestellt wurde (obwohl Royce den Begriff Wasserfall in diesem Artikel nicht verwendete).\n📑 Auf Seite 329 stellt Royce den Wasserfall-Prozess vor und sagt: \u0026ldquo;I believe in this concept, but the implementation described above is risky and invites failure.\u0026rdquo;\n📑 Auf Seite 330 zeigt Royce, wie der Wasserfall-Prozess durch die Einführung eines ♻ iterativen Ansatzes verbessert werden kann.\n👉 Verwende einen iterativen Ansatz für komplexe und komplizierte Softwareentwicklung. 👍\nReferenzen:\nWasserfallmodell: Wikipedia Royce 1970 Paper (PDF) ","date":"11. January 2021","externalUrl":null,"permalink":"/de/blogs/was-ist-die-geschichte-des-wasserfall-prozesses/","section":"Blogs","summary":" Der “Erfinder” des Wasserfall-Prozesses 💧 sagte 1970: “I believe in this concept, but the implementation described above is risky and invites failure.” 😱\n","title":"Was ist die Geschichte des Wasserfall-Prozesses?","type":"blogs"},{"content":"","date":"11. January 2021","externalUrl":null,"permalink":"/de/tags/wasserfall/","section":"Tags","summary":"","title":"Wasserfall","type":"tags"},{"content":"","date":"11 January 2021","externalUrl":null,"permalink":"/en/tags/waterfall/","section":"Tags","summary":"","title":"Waterfall","type":"tags"},{"content":" The “inventor” of the waterfall process 💧 said in 1970: “I believe in this concept, but the implementation described above is risky and invites failure.” 😱\nWatch my video to see what a mind blowing 🤯 approach he recommended in 1970:\nThe waterfall process 💧 is a software development process first introduced by Dr. Winston W. Royce in a 📝 paper published in 1970 (although Royce did not use the term waterfall in that article).\n📑 On page 329 Royce introduces the waterfall process and says: “I believe in this concept, but the implementation described above is risky and invites failure.”\n📑 On page 330 Royce shows how the waterfall process can be fixed by introducing an ♻ iterative approach.\n👉 Use an iterative approach for complex and complicated software development. 👍\nReferences:\nWaterfall model: Wikipedia Royce 1970 Paper (PDF) ","date":"11 January 2021","externalUrl":null,"permalink":"/en/blogs/what-is-the-history-of-the-waterfall-process/","section":"Blogs","summary":" The “inventor” of the waterfall process 💧 said in 1970: “I believe in this concept, but the implementation described above is risky and invites failure.” 😱\n","title":"What is the history of the Waterfall Process?","type":"blogs"},{"content":"","date":"3 January 2021","externalUrl":null,"permalink":"/en/tags/2021/","section":"Tags","summary":"","title":"2021","type":"tags"},{"content":"What will move the needle in DevOps in 2021? After a year that forced almost every organisation to accelerate digital delivery, the trends I see for 2021 are less about shiny new tools and more about discipline: making DevOps stick at scale, shifting security left, getting serious about continuous delivery, leaning further into the cloud, and watching the early signals from AIOps.\nStrong DevOps Adoption Driven by Agile Transformation # DevOps adoption was already growing fast, and 2021 will push it further. The reason is that agile transformation alone is no longer enough. Companies have rolled out Scrum, SAFe and team-of-teams setups, but if the path from a developer\u0026rsquo;s commit to a customer-facing release still takes weeks, the agile process work is wasted. DevOps is what closes that gap. Expect to see more enterprises treating DevOps not as a tooling project for one team but as a transformation programme alongside their agile rollout.\nSecurity Will Be a Top Priority — DevSecOps # The number and severity of cyber-attacks made it impossible to keep treating security as a final gate before go-live. In 2021, security shifts left into the pipeline. That means SAST, secret detection, software composition analysis and container scanning running on every commit, and DAST in the staging environment. The cultural shift matters as much as the tools: developers, operations and security working in one team rather than three. DevSecOps is the umbrella term, and it will dominate the conversation this year.\nFocus on Continuous Delivery Pipelines # Continuous delivery is the connective tissue between agile teams and customers. In 2021, more organisations will move from \u0026ldquo;we have CI\u0026rdquo; to \u0026ldquo;we have a real CD pipeline\u0026rdquo; — automated deployments to staging, automated quality and security gates, and the ability to release on demand. The differentiator will not be having a pipeline; it will be how mature the pipeline is. Feedback in minutes, not hours. Decoupled deployment and release through feature toggles. Trunk-based development to keep merge cost low.\nCloud Becomes the Default # The cloud has been a trend for years, but 2021 is the year it becomes the default rather than the exception. Workloads keep moving from data centres to public cloud, and the conversation shifts to multi-cloud and hybrid architectures. Containers and Kubernetes are the standard packaging and orchestration model, and Infrastructure as Code is now table stakes. If your team is still treating cloud as a side project, you are already behind.\nAIOps as a Young but Promising Area # AIOps — applying machine learning to IT operations — is still early, but the signals are real. The volume of telemetry coming out of distributed systems is too large for humans to make sense of in real time. AI-assisted anomaly detection, log analysis and incident response will not replace SREs, but they will give them leverage. In 2021, expect more pilot projects and a lot more vendor noise. Treat the noise sceptically and focus on use cases where the data quality is good enough to actually train on.\nKey Takeaways # DevOps is the missing piece of agile transformation. Without a fast path from commit to production, agile process improvements get stuck at the team level.\nDevSecOps is no longer optional. Security has to move into the pipeline, run on every commit, and be owned by the same team that ships the code.\nContinuous delivery maturity is the differentiator. Everyone has a pipeline. The question is how fast, how automated, and how trustworthy yours is.\nCloud is the default platform. Containers, Kubernetes and IaC are the operating model. Multi-cloud and hybrid setups are the norm, not the exception.\nAIOps is promising but early. Pilot it where your data is good. Be sceptical of vendors selling magic.\n","date":"3 January 2021","externalUrl":null,"permalink":"/en/blogs/top-devops-trends-2021/","section":"Blogs","summary":"What will move the needle in DevOps in 2021? After a year that forced almost every organisation to accelerate digital delivery, the trends I see for 2021 are less about shiny new tools and more about discipline: making DevOps stick at scale, shifting security left, getting serious about continuous delivery, leaning further into the cloud, and watching the early signals from AIOps.\n","title":"What Are the Top DevOps Trends in 2021?","type":"blogs"},{"content":"","date":"31 August 2020","externalUrl":null,"permalink":"/en/tags/iterative-delivery/","section":"Tags","summary":"","title":"Iterative Delivery","type":"tags"},{"content":"","date":"31 August 2020","externalUrl":null,"permalink":"/en/tags/process/","section":"Tags","summary":"","title":"Process","type":"tags"},{"content":"","date":"31. August 2020","externalUrl":null,"permalink":"/de/tags/prozess/","section":"Tags","summary":"","title":"Prozess","type":"tags"},{"content":"Waterfall und Agile sind nicht einfach zwei Geschmacksrichtungen von Projektmanagement. Es sind zwei grundlegend verschiedene Arten, mit Unsicherheit umzugehen. Wer das versteht, versteht den Rest fast von selbst.\nWaterfall: Linear und sequenziell # Waterfall ist ein linearer, sequenzieller Lebenszyklus. Das Team geht erst in die nächste Phase, wenn die vorherige erfolgreich abgeschlossen ist. Zuerst Anforderungen, dann Design, dann Implementierung, dann Test, dann Deployment, dann Betrieb. Jede Phase hat eine Übergabe und eine Freigabe. Jede Phase erzeugt ein Dokument, das die nächste Phase konsumiert.\nDas Modell hat seine Stärken. Es ist auf dem Papier planbar. Es sieht in einem Gantt-Chart hübsch aus. Es funktioniert leidlich, wenn die Anforderungen stabil sind, die Technologie gut verstanden ist und sich der Scope nicht ändert. Hochbau ist ein guter Fit. Software in den meisten Fällen nicht.\nWarum Waterfall mit Software ringt # Software hat Unsicherheit eingebaut. Anforderungen ändern sich, sobald Nutzer das Produkt sehen. Technologie verschiebt sich unter den Füssen. Der Markt bewegt sich, während du baust. Waterfall geht damit schlecht um, weil es annimmt, dass alles vorne entschieden und dann ausgeführt werden kann. Bis du in die Testphase kommst — sechs, neun, zwölf Monate später — haben sich die Anforderungen verschoben, aber du hast schon gegen die alten gebaut. Die Fehlerkosten sind enorm, und die Wertkosten (das Falsche bauen) können noch grösser sein.\nAgile: Iterativ und inkrementell # Agile geht den umgekehrten Weg. Es nimmt Unsicherheit als Standard an. Statt einer grossen Sequenz machst du viele kleine Loops. Jeder Loop produziert etwas Nutzbares, du legst es vor Nutzer, du lernst und du justierst nach. Das Produkt wächst inkrementell, und der Plan passt sich an, während du lernst.\nDie Mechanik ist weniger wichtig als das Mindset. Scrum, Kanban, SAFe, XP — alles Geschmacksrichtungen. Der gemeinsame Kern ist: kurze Zyklen, kontinuierliches Feedback, lauffähige Software über umfassende Dokumentation, Reagieren auf Veränderung über Folgen eines Plans.\nDer eigentliche Unterschied: Umgang mit Unsicherheit # Das ist der Teil, den die meisten verpassen. Waterfall sagt: \u0026ldquo;Wir reduzieren Unsicherheit, indem wir alles vorne planen.\u0026rdquo; Agile sagt: \u0026ldquo;Wir akzeptieren Unsicherheit und reduzieren sie, indem wir schnell lernen.\u0026rdquo; Beides sind valide Antworten — aber nur eine davon funktioniert, wenn sich die Welt unter dir verändert. Für Software in 2026 ist die Antwort fast immer Agile. Nicht weil Agile in Mode ist, sondern weil die zugrundeliegende Annahme — Unsicherheit ist Standard — die ehrliche ist.\nWo Agile mit DevOps zusammenhängt # Agile gibt dir kurze Zyklen in der Entwicklung. DevOps zieht diese kurzen Zyklen bis in den Betrieb durch. Ein agiles Team, das einmal pro Quartal in Produktion deployed, bekommt nicht wirklich das Feedback, das der Loop liefern soll. DevOps ist das, was den agilen Feedback-Loop bis zum Nutzer durchzieht. Die beiden gehören zusammen.\nWann Waterfall noch seinen Platz hat # Ich bin in der Frage nicht religiös. Es gibt Situationen, in denen Waterfall die richtige Wahl ist: stark regulierte Umgebungen mit eingefrorenen Specs, Hardware-Projekte mit langen Fertigungszeiten, Integrationen mit Altsystemen, die sich nicht inkrementell testen lassen. Der ehrliche Test ist: Wie stark werden sich die Anforderungen ändern, während du baust? Lautet die Antwort \u0026ldquo;praktisch nicht\u0026rdquo;, ist Waterfall in Ordnung. Lautet sie \u0026ldquo;wir wissen es noch nicht so genau\u0026rdquo;, dann Agile.\nKey Takeaways # Waterfall ist sequenziell, Agile ist iterativ. Das ist der Oberflächen-Unterschied. Der tiefere Unterschied ist, wie jedes Modell mit Unsicherheit umgeht.\nWaterfall nimmt an, dass alles vorne planbar ist. Diese Annahme hält in manchen Domänen. In Software selten.\nAgile reduziert Unsicherheit durch schnelles Lernen. Kurze Zyklen, lauffähige Software, kontinuierliches Feedback. Der Plan passt sich an, während das Team lernt.\nDas Framework ist weniger wichtig als das Mindset. Scrum, Kanban, SAFe — alles Geschmacksrichtungen. Der Kern sind kurze Loops und Feedback.\nAgile ohne DevOps bleibt auf halbem Weg stehen. Wer einmal pro Quartal in Produktion deployed, dessen Feedback-Loop erreicht den Nutzer nie. Agile und DevOps gehören zusammen.\nWähle nach Unsicherheit, nicht nach Mode. Sind die Anforderungen wirklich stabil, ist Waterfall in Ordnung. Sind sie es nicht, dann Agile. Sei ehrlich, in welcher Situation du steckst.\n","date":"31. August 2020","externalUrl":null,"permalink":"/de/blogs/unterschied-zwischen-waterfall-und-agile/","section":"Blogs","summary":"Waterfall und Agile sind nicht einfach zwei Geschmacksrichtungen von Projektmanagement. Es sind zwei grundlegend verschiedene Arten, mit Unsicherheit umzugehen. Wer das versteht, versteht den Rest fast von selbst.\nWaterfall: Linear und sequenziell # Waterfall ist ein linearer, sequenzieller Lebenszyklus. Das Team geht erst in die nächste Phase, wenn die vorherige erfolgreich abgeschlossen ist. Zuerst Anforderungen, dann Design, dann Implementierung, dann Test, dann Deployment, dann Betrieb. Jede Phase hat eine Übergabe und eine Freigabe. Jede Phase erzeugt ein Dokument, das die nächste Phase konsumiert.\n","title":"Was ist der Unterschied zwischen Waterfall und Agile?","type":"blogs"},{"content":"Waterfall and Agile are not just two flavours of project management. They are two fundamentally different ways of dealing with uncertainty. If you understand that, the rest follows.\nWaterfall: Linear and Sequential # Waterfall is a linear sequential life cycle model. The team only moves to the next phase if the previous one finished successfully. Requirements first, then design, then implementation, then testing, then deployment, then operation. Each phase has a hand-off and a sign-off. Each phase produces a document that the next phase consumes.\nThe model has its strengths. It is predictable on paper. It looks neat in a Gantt chart. It works reasonably well when the requirements are stable, the technology is well understood and the scope will not change. Civil engineering is a good fit. Software, most of the time, is not.\nWhy Waterfall Struggles with Software # Software has uncertainty baked in. Requirements change as users see the product. Technology shifts under your feet. The market moves while you build. Waterfall handles all of this badly because it assumes you can decide everything up front and then execute. By the time you are testing — six, nine, twelve months in — the requirements have moved, but you have already built against the old ones. The defect cost is enormous, and the value cost (building the wrong thing) can be even bigger.\nAgile: Iterative and Incremental # Agile takes the opposite stance. It assumes uncertainty is the default. So instead of one big sequence, you do many small loops. Each loop produces something usable, you put it in front of users, you learn, and you adjust. The product grows incrementally, and the plan adjusts as you learn.\nThe mechanics matter less than the mindset. Scrum, Kanban, SAFe, XP — these are all flavours. The shared core is: short cycles, continuous feedback, working software over comprehensive documentation, responding to change over following a plan.\nThe Real Difference: How You Treat Uncertainty # This is the part most people miss. Waterfall says: \u0026ldquo;We will reduce uncertainty by planning everything up front.\u0026rdquo; Agile says: \u0026ldquo;We accept uncertainty and reduce it by learning fast.\u0026rdquo; Both are valid responses — but only one of them works when the world keeps changing on you. For software in 2026, the answer is almost always Agile. Not because Agile is fashionable, but because the underlying assumption — uncertainty is the default — is the honest one.\nWhere Agile Connects to DevOps # Agile gives you short cycles in development. DevOps extends those short cycles all the way to operation. An Agile team that ships to production once per quarter is not really getting the feedback the loop is supposed to give. DevOps is what makes the Agile feedback loop reach the user. The two belong together.\nWhen Waterfall Still Has a Place # I am not religious about this. There are still situations where Waterfall is the right call: heavily regulated environments with frozen specs, hardware projects with long manufacturing lead times, integrations with legacy systems that cannot be tested incrementally. The honest test is: how much will the requirements change while you build? If the answer is \u0026ldquo;barely at all\u0026rdquo;, Waterfall is fine. If the answer is \u0026ldquo;we do not really know yet\u0026rdquo;, Agile.\nKey Takeaways # Waterfall is sequential, Agile is iterative. That is the surface difference. The deeper difference is how each model handles uncertainty.\nWaterfall assumes you can plan everything up front. That assumption holds for some domains. It rarely holds for software.\nAgile reduces uncertainty by learning fast. Short cycles, working software, continuous feedback. The plan adapts as the team learns.\nThe framework matters less than the mindset. Scrum, Kanban, SAFe — all flavours. The core is short loops and feedback.\nAgile without DevOps stops short. If you ship to production once per quarter, the feedback loop never reaches the user. Agile and DevOps belong together.\nPick based on uncertainty, not fashion. If requirements are truly stable, Waterfall is fine. If they are not, Agile. Be honest about which one you are in.\n","date":"31 August 2020","externalUrl":null,"permalink":"/en/blogs/difference-between-waterfall-and-agile/","section":"Blogs","summary":"Waterfall and Agile are not just two flavours of project management. They are two fundamentally different ways of dealing with uncertainty. If you understand that, the rest follows.\nWaterfall: Linear and Sequential # Waterfall is a linear sequential life cycle model. The team only moves to the next phase if the previous one finished successfully. Requirements first, then design, then implementation, then testing, then deployment, then operation. Each phase has a hand-off and a sign-off. Each phase produces a document that the next phase consumes.\n","title":"What is the difference between Waterfall and Agile?","type":"blogs"},{"content":"","date":"20 August 2020","externalUrl":null,"permalink":"/en/tags/continuous-learning/","section":"Tags","summary":"","title":"Continuous Learning","type":"tags"},{"content":"","date":"20 August 2020","externalUrl":null,"permalink":"/en/tags/psychological-safety/","section":"Tags","summary":"","title":"Psychological Safety","type":"tags"},{"content":"","date":"20 August 2020","externalUrl":null,"permalink":"/en/tags/three-ways/","section":"Tags","summary":"","title":"Three Ways","type":"tags"},{"content":"Der dritte Weg, DevOps einzuführen, besteht darin, eine Vertrauenskultur zu schaffen, die Experimente und Risikobereitschaft trägt. Das ist der Third Way im Three-Ways-Framework von Gene Kim — und er bringt das Team auf eine Lernkurve, die steil genug ist, um die Konkurrenz hinter sich zu lassen.\nWarum Kultur in der Reihenfolge zuletzt kommt — nicht in der Bedeutung # Die Three Ways sind aus einem Grund in dieser Reihenfolge sortiert. Flow zuerst, weil ohne Flow nichts da ist, worauf Feedback gegeben werden kann. Feedback zweitens, weil ohne Feedback nichts zum Lernen da ist. Lernen drittens, weil Lernen die ersten beiden über die Zeit potenziert.\nAber dass Kultur in der Sequenz an dritter Stelle steht, macht sie nicht weniger wichtig. Sie ist der Multiplikator. Ein Team mit mittelmässigem Flow und Feedback, aber starker Lernkultur wird ein Team mit grossartigen Tools und ohne psychologische Sicherheit überholen. Tools kannst du kaufen. Kultur musst du bauen.\nEine Kultur des Vertrauens # Vertrauen ist das Fundament. Vertrauen unter Teammitgliedern, Vertrauen zwischen Teams, Vertrauen zwischen Teams und Führung. Ohne es verstecken Leute Probleme, verteidigen Entscheidungen statt sie zu revidieren und meiden alles, was sie schlecht aussehen lassen könnte. Mit ihm kommen Probleme früh an die Oberfläche, Entscheidungen werden hinterfragt, und Leute teilen, was sie gelernt haben — auch die peinlichen Teile.\nVertrauen aufzubauen ist keine einmalige Übung. Es ist das kumulierte Ergebnis davon, wie Führungskräfte reagieren, wenn etwas schiefgeht, wie Teams mit Meinungsverschiedenheiten umgehen und wie die Organisation ehrliches Reporting belohnt. Ein einziges schuldzuweisendes Incident Review kann ein Jahr Vertrauensaufbau zunichtemachen.\nExperimentieren und Risiken eingehen # Eine Lernkultur behandelt jede Veränderung als Experiment. Du hast eine Hypothese, schickst einen kleinen Test raus, misst, entscheidest. Manche Experimente funktionieren. Manche nicht. Die, die nicht funktionieren, sind keine Misserfolge — sie sind Datenpunkte, die weniger gekostet haben als die falsche Entscheidung gekostet hätte.\nExperimentieren funktioniert nur, wenn Risikobereitschaft tatsächlich erlaubt ist. Wenn jeder Fehlschuss bestraft und jeder Erfolg der lautesten Stimme gutgeschrieben wird, hören die Leute auf zu experimentieren. Sie bleiben auf dem sicheren Pfad. Der sichere Pfad ist auch der Pfad, auf dem nichts Neues gelernt wird und die Konkurrenz die Lücke schliesst.\nSteilere Lernkurve, schnellere Marktanpassung # Worum es bei alledem geht: Lerngeschwindigkeit. Märkte bewegen sich. Kundenbedürfnisse verschieben sich. Technologie-Stacks entwickeln sich weiter. Das Team, das schneller lernt, als sich der Markt verändert, bleibt vorn. Das Team, das das nicht schafft, fällt zurück — egal wie gut sein ursprüngliches Produkt war.\nGenau das macht den Third Way zum nachhaltigen Wettbewerbsvorteil. Jeder kann deine Features kopieren. Jeder kann Engineers anstellen, die so gut sind wie deine. Wenige Organisationen können eine Lernkultur kopieren, weil Kultur kein Feature ist — sie ist die kumulierte Art, wie sich die Organisation unter Druck tatsächlich verhält.\nLernen explizit machen # Lernen passiert nicht automatisch, nur weil Experimente laufen. Es muss explizit gemacht werden. Blameless Post-mortems bei Incidents. Retrospektiven, die konkrete Änderungen produzieren, nicht nur Dampf ablassen. Game Days und Chaos-Experimente, die unbekannte Failure Modes aufdecken, bevor Kunden das tun. Internes Teilen — Brown Bags, Demos, Write-ups —, damit das, was ein Team lernt, der ganzen Organisation zur Verfügung steht.\nHier zählt Führung am meisten. Leader machen vor, wie Lernen aussieht. Geben sie Fehler offen zu, tun es andere auch. Verstecken sie sie, verstecken alle anderen ihre auch.\nKey Takeaways # Kultur kommt in der Sequenz zuletzt, in der Bedeutung zuerst. Tools kaufst du; Kultur baust du. Vertrauen ist das Fundament. Ohne es verstecken sich Probleme und Lernen hört auf. Veränderungen als Experimente behandeln. Manche funktionieren, manche nicht. Beide liefern Signal — solange Bestrafung den Brunnen nicht vergiftet. Lerngeschwindigkeit ist der nachhaltige Vorteil. Features und Engineers sind kopierbar. Kultur nicht. Lernen explizit machen. Post-mortems, Retros, Game Days, internes Teilen — ohne Ritual geht Gelerntes verloren. Leader machen vor, was erlaubt ist. Geben Leader Fehler zu, tut es das Team auch. Sonst nicht. ","date":"20. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-der-dritte-weg-von-devops/","section":"Blogs","summary":"Der dritte Weg, DevOps einzuführen, besteht darin, eine Vertrauenskultur zu schaffen, die Experimente und Risikobereitschaft trägt. Das ist der Third Way im Three-Ways-Framework von Gene Kim — und er bringt das Team auf eine Lernkurve, die steil genug ist, um die Konkurrenz hinter sich zu lassen.\n","title":"Was ist der dritte Weg von DevOps? Continuous Learning und eine Kultur des Vertrauens","type":"blogs"},{"content":"The third way to introduce DevOps is to create a culture of trust that supports experimentation and risk-taking. This is the Third Way in Gene Kim\u0026rsquo;s Three Ways framework — and it is what puts the team on a learning curve steep enough to outpace the competition.\nWhy Culture Comes Last in Order, Not in Importance # The Three Ways are sequenced for a reason. Flow first, because without flow there is nothing to feed back on. Feedback second, because without feedback there is nothing to learn from. Learning third, because learning is what compounds the first two over time.\nBut culture being third in sequence does not make it less important. It is the multiplier. A team with mediocre flow and feedback but a strong learning culture will out-improve a team with great tools and no psychological safety. Tools you can buy. Culture you have to build.\nA Culture of Trust # Trust is the foundation. Trust between team members, trust between teams, trust between teams and leadership. Without it, people hide problems, defend decisions instead of revising them, and avoid anything that might make them look bad. With it, problems surface early, decisions get challenged, and people share what they learned — including the embarrassing parts.\nBuilding trust is not a one-off exercise. It is the cumulative result of how leaders respond when something goes wrong, how teams handle disagreement, and how the organisation rewards honest reporting. One blame-driven incident review can undo a year of trust-building.\nExperimentation and Risk-Taking # A learning culture treats every change as an experiment. You have a hypothesis, you ship a small test, you measure, you decide. Some experiments work. Some do not. The ones that do not are not failures — they are data points that cost less than the wrong decision would have.\nExperimentation only works if risk-taking is genuinely allowed. If every miss gets punished and every win gets credited to the loudest voice, people stop experimenting. They stick to the safe path. The safe path is also the path where nothing new is learned and the competition closes the gap.\nSteeper Learning Curve, Faster Market Adjustment # The point of all this is speed of learning. Markets move. Customer needs shift. Technology stacks evolve. The team that learns faster than the market changes stays ahead. The team that does not falls behind, regardless of how good its initial product was.\nThis is what makes the Third Way the durable competitive edge. Anyone can copy your features. Anyone can hire engineers as good as yours. Few organisations can copy a learning culture, because culture is not a feature — it is the accumulated way the organisation actually behaves under pressure.\nMake Learning Explicit # Learning does not happen automatically just because experiments are run. It has to be made explicit. Blameless post-mortems on incidents. Retrospectives that produce concrete changes, not just venting. Game days and chaos experiments that surface unknown failure modes before customers do. Internal sharing — brown bags, demos, write-ups — so what one team learns becomes available to the whole organisation.\nThis is also where leadership matters most. Leaders model what learning looks like. If they admit mistakes openly, others will too. If they hide them, everyone else will hide theirs.\nKey Takeaways # Culture is third in sequence, first in importance. Tools you buy; culture you build. Trust is the foundation. Without it, problems hide and learning stops. Treat changes as experiments. Some work, some do not. Both produce signal — if punishment does not poison the well. Speed of learning is the durable edge. Features and engineers are copyable. Culture is not. Make learning explicit. Post-mortems, retros, game days, internal sharing — without ritual, learning gets lost. Leaders model what is allowed. If leaders admit mistakes, the team will too. If not, the team will not. ","date":"20 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-the-third-way-of-devops/","section":"Blogs","summary":"The third way to introduce DevOps is to create a culture of trust that supports experimentation and risk-taking. This is the Third Way in Gene Kim’s Three Ways framework — and it is what puts the team on a learning curve steep enough to outpace the competition.\n","title":"What Is the Third Way of DevOps? Continuous Learning and a Culture of Trust","type":"blogs"},{"content":"","date":"19 August 2020","externalUrl":null,"permalink":"/en/tags/feedback/","section":"Tags","summary":"","title":"Feedback","type":"tags"},{"content":"Der zweite Weg, DevOps einzuführen, ist ein starker Feedback-Fluss in die Gegenrichtung des Value Flows — vom Kunden und aus der Produktion zurück ins Business und ins Development. Das ist der Second Way im Three-Ways-Framework von Gene Kim, und er verhindert, dass der First Way im Blindflug optimiert.\nWarum Feedback an zweiter Stelle kommt # Der First Way optimiert, wie Wert zum Kunden fliesst. Der Second Way stellt sicher, dass du tatsächlich weisst, was passiert, sobald er dort ankommt. Ohne Feedback bedeutet schneller Flow nur, dass du das Falsche schneller ausspielst. Mit Feedback wird jedes Release zum kontrollierten Experiment — du lieferst, du misst, du entscheidest, was als Nächstes kommt.\nFeedback schliesst auch den Loop zwischen Development und Operations. Das Team, das das Feature gebaut hat, sollte das Team sein, das vom Produktionsproblem hört. Genau das verändert Verhalten langfristig.\nProduktionsprobleme fliessen schnell zurück # Die erste Art von Feedback ist operativ. Wenn etwas in Produktion bricht, muss das Signal die Leute erreichen, die es beheben können — schnell und mit genug Kontext, um zu handeln. Logs, Metriken, Traces, Alerts, die das richtige Team pagen, Dashboards, die zeigen, was ungewöhnlich ist. Das Ziel ist nicht nur Detektion; es geht darum, früh genug zu erkennen, um das Problem zu beheben, bevor Kunden es merken — oder es zumindest zurückzurollen, bevor es sich ausbreitet.\nEin Team, das seine eigene Produktionsdaten nicht sieht, baut Features auf einem Modell des Systems, das nicht der Realität entspricht. Ein Team, das sie sieht, baut andere Features und schreibt anderen Code.\nKundenfeedback erreicht das Business # Die zweite Art von Feedback ist Kundenverhalten. Welche Features nutzen die Leute tatsächlich? Welche ignorieren sie? Wo brechen sie in einem Workflow ab? Diese Fragen beantwortest du mit gezielter Messung und Usage Analysis — instrumentierte Features, Funnels, Kohortenanalysen, qualitative Feedback-Kanäle.\nDas ist es, was dem Business echten Input für die nächste Entscheidung liefert. Sollen wir dieses Feature ausbauen oder einstellen? Sollen wir eine dritte Option hinzufügen oder auf eine reduzieren? Ohne Nutzungsdaten werden diese Entscheidungen von der lautesten Stimme im Raum getroffen. Mit Nutzungsdaten werden sie davon getroffen, was Kunden tatsächlich tun.\nFeedback-Loops kurz und spezifisch halten # Ein Feedback-Loop zählt nur, wenn er eine Entscheidung verändert. Wenn ein Kunde heute ein Problem meldet und das Team davon nächstes Quartal im Status Report hört, ist der Loop zu lang, um zu handeln. Wenn Usage Analytics in einem Tool leben, das niemand öffnet, ist der Loop zu weit weg.\nKurze Loops, spezifische Signale, vor den richtigen Leuten. Produktions-Telemetrie auf einem Screen, den das Engineering-Team sieht. Nutzungsdaten im Planungsritual des Product Managers. Support-Tickets, die zum Team durchgestellt werden, das das Feature besitzt. Jeder Loop sollte auf die konkrete Entscheidung gerichtet sein, die er informieren soll.\nBlameless Response gehört zum Loop # Feedback fliesst nur frei, wenn es sicher ist, es auszusprechen. Führt das Melden eines Problems zu Schuldzuweisungen, hören die Leute auf, Probleme zu melden — und der Loop stirbt. Blameless Post-mortems, Fokus auf systemische Ursachen statt individuelle Fehler, Incidents als Lerngelegenheiten behandeln. Das ist das kulturelle Stück, das den Second Way wirklich funktionieren lässt — und es ist die Brücke zum Third Way.\nKey Takeaways # Ohne Feedback liefert schneller Flow das Falsche schneller. Der Second Way macht den First Way sicher. Produktionsprobleme müssen zum Team zurückfliessen, das sie beheben kann. Dasselbe Team baut und betreibt. Nutzungsdaten treiben Produktentscheidungen. Ohne sie entscheidet die lauteste Stimme. Kurze, spezifische Loops verändern Verhalten. Lange oder generische Loops nicht. Blameless Response hält den Loop am Leben. Bestrafung tötet Feedback schneller, als es ein Tool wiederbeleben kann. Der Second Way ist die Brücke zum Third. Feedback erzeugt nur dann Lernen, wenn die Kultur ehrliches Signal trägt. ","date":"19. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-der-zweite-weg-von-devops/","section":"Blogs","summary":"Der zweite Weg, DevOps einzuführen, ist ein starker Feedback-Fluss in die Gegenrichtung des Value Flows — vom Kunden und aus der Produktion zurück ins Business und ins Development. Das ist der Second Way im Three-Ways-Framework von Gene Kim, und er verhindert, dass der First Way im Blindflug optimiert.\n","title":"Was ist der zweite Weg von DevOps? Feedback verstärken","type":"blogs"},{"content":"The second way to introduce DevOps is to build a strong flow of feedback going in the opposite direction of the value flow — from customers and production back into the business and into development. This is the Second Way in Gene Kim\u0026rsquo;s Three Ways framework, and it is what stops the First Way from optimising in the dark.\nWhy Feedback Comes Second # The First Way optimises how value flows to the customer. The Second Way makes sure you actually know what is happening once it gets there. Without feedback, fast flow just means you ship the wrong thing faster. With feedback, every release becomes a controlled experiment — you ship, you measure, you decide what to do next.\nFeedback also closes the loop between development and operations. The team that built the feature should be the team that hears about the production issue. That is what changes behaviour over the long run.\nProduction Problems Flow Back Fast # The first kind of feedback is operational. When something breaks in production, the signal needs to reach the people who can fix it — fast and with enough context to act. Logs, metrics, traces, alerts that page the right team, dashboards that show what is unusual. The goal is not just to detect; it is to detect early enough that you can fix the issue before customers notice, or at least roll it back before it spreads.\nA team that does not see its own production data will keep building features in a model of the system that does not match reality. A team that does see it builds different features and writes different code.\nCustomer Feedback Reaches the Business # The second kind of feedback is customer behaviour. Which features are people actually using? Which ones do they ignore? Where do they drop off in a workflow? You answer these questions with focused measurement and usage analysis — instrumented features, funnels, cohort analysis, qualitative feedback channels.\nThis is what gives the business real input for the next decision. Should we expand this feature, or kill it? Should we add a third option, or simplify down to one? Without usage data, those decisions get made by the loudest voice in the room. With usage data, they get made by what customers actually do.\nMake Feedback Loops Short and Specific # A feedback loop only matters if it changes a decision. If a customer reports an issue today and the team hears about it next quarter in a status report, the loop is too long to act on. If usage analytics live in a tool nobody opens, the loop is too distant.\nShort loops, specific signals, in front of the right people. Production telemetry on a screen the engineering team sees. Usage data in the product manager\u0026rsquo;s planning ritual. Support tickets surfaced to the team that owns the feature. Each loop should be aimed at the specific decision it is meant to inform.\nBlameless Response Is Part of the Loop # Feedback only flows freely when it is safe to surface it. If reporting a problem leads to blame, people stop reporting problems — and the loop dies. Blameless post-mortems, focus on system causes rather than individual mistakes, treating incidents as learning opportunities. This is the cultural piece that makes the Second Way actually work, and it is also what bridges into the Third Way.\nKey Takeaways # Without feedback, fast flow ships the wrong thing faster. The Second Way is what makes the First Way safe. Production problems must flow back to the team that can fix them. Same team builds and runs. Usage data drives product decisions. Without it, decisions get made by the loudest voice. Short, specific loops change behaviour. Long or generic loops do not. Blameless response keeps the loop alive. Punishment kills feedback faster than any tool can revive it. The Second Way bridges to the Third. Feedback only generates learning if the culture supports honest signal. ","date":"19 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-the-second-way-of-devops/","section":"Blogs","summary":"The second way to introduce DevOps is to build a strong flow of feedback going in the opposite direction of the value flow — from customers and production back into the business and into development. This is the Second Way in Gene Kim’s Three Ways framework, and it is what stops the First Way from optimising in the dark.\n","title":"What Is the Second Way of DevOps? Amplify Feedback","type":"blogs"},{"content":"","date":"18 August 2020","externalUrl":null,"permalink":"/en/tags/flow/","section":"Tags","summary":"","title":"Flow","type":"tags"},{"content":"Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.\nWert entsteht beim Kunden # Diese Erkenntnis muss sitzen: Wert entsteht erst, wenn der Kunde das Feature nutzen kann. Code auf einem Entwickler-Laptop ist kein Wert. Ein gemergter Pull Request ist kein Wert. Ein Binary in der Artifact Registry ist kein Wert. Die ganze Strecke von \u0026ldquo;wir hatten eine Idee\u0026rdquo; bis \u0026ldquo;der Kunde nutzt sie\u0026rdquo; ist der Value Flow — und das Ziel des First Way ist, diesen Flow so schnell und vorhersehbar wie möglich zu machen.\nBraucht ein Feature sechs Monate für diese Strecke, hast du ein Flow-Problem. Die Lösung ist nicht, die Entwickler härter rangzunehmen. Die Lösung ist, die gesamte Pipeline anzuschauen — Handoffs, Queues, Approvals, Environment Provisioning, Deployments — und alles zu entfernen, was den Flow bremst.\nArbeit sichtbar machen # Was du nicht siehst, kannst du nicht verbessern. Der erste konkrete Schritt: Mach die Arbeit über den gesamten Value Stream sichtbar. Jedes Stück Arbeit, in jedem Schritt, auf einem Board, das alle sehen. Nicht nur Dev-Tickets — auch Ops-Tickets, Deployment-Requests, Change-Approvals, Security-Reviews. In dem Moment, in dem alles an einem Ort sichtbar ist, werden die Bottlenecks offensichtlich. Es gibt immer eine Spalte, in der sich Karten stapeln.\nHier beginnt auch der Kulturwandel. Wenn Dev und Ops dasselbe Board sehen, hören sie auf, ihre lokale Queue zu optimieren, und denken anfangen, in Systemen zu denken.\nBatch Size verkleinern # Grosse Batches sind langsame Batches. Ein Release, das 80 Features bündelt, dauert länger im Test, länger im Deployment, länger im Debugging, wenn etwas schiefgeht — und länger im Rollback. Ein Release mit einem Feature ist auf jeder dieser Dimensionen schnell.\nDie Batch Size zu verkleinern ist der mit Abstand wirkungsvollste Flow-Hebel, den du hast. Kleinere Commits, kleinere Pull Requests, kleinere Deployments, kleinere Releases. Mit sinkender Batch Size sinkt die Lead Time, steigt die Qualität und steigt das Vertrauen des Teams — weil jede Änderung klein genug ist, um durchdacht zu werden.\nArbeitsintervalle verkürzen # Neben der Batch Size lohnt der Blick auf die Arbeitsintervalle. Wie oft deployst du? Wie oft releaset du? Wie oft läuft die Test Suite? Lautet die Antwort \u0026ldquo;wöchentlich\u0026rdquo; oder \u0026ldquo;monatlich\u0026rdquo;, ist jedes Intervall eine Warteschlange, in der Arbeit liegt. Kürzere Intervalle — tägliche Deployments, kontinuierliche Test-Runs, On-Demand-Releases — verwandeln diese Queues in Flow.\nSo wird Deployment zum Non-Event. Wenn du zehnmal am Tag deployst, ist Deployment Routine. Wenn du einmal im Quartal deployst, wird Deployment zur High-Stakes-Zeremonie mit War Room und Rollback-Plan.\nQualität an der Quelle # Flow optimieren heisst nicht, Abkürzungen nehmen. Es heisst, Qualität dort einzubauen, wo sie hingehört — an der Quelle. Automatisierte Tests, Code Review, Static Analysis, Security Scans bei jedem Commit. Ein Defekt beim Commit zu erwischen kostet Minuten. Denselben Defekt in Produktion zu erwischen kostet Tage, plus Kundenkosten, plus Vertrauenskosten. Flow wird gerade deshalb schneller, weil Qualität von Anfang an drin ist, nicht am Ende drangeflanscht.\nKey Takeaways # Wert entsteht beim Kunden, nicht im Repo. Optimiere die gesamte Strecke von der Idee bis zur Kundennutzung. Arbeit über den gesamten Value Stream sichtbar machen. Bottlenecks bleiben verborgen, bis alles auf einem Board steht. Batch Size aggressiv verkleinern. Kleinere Commits, kleinere Deployments, kleinere Releases — jede Dimension gewinnt. Intervalle verkürzen. Häufige Deployments machen Deployment zur Routine. Seltene Deployments machen es gefährlich. Qualität an der Quelle einbauen. Schnellerer Flow funktioniert nur, wenn Defekte nicht mitfliessen. Der First Way bereitet den Second vor. Sinnvolles Feedback (Second Way) gibt es erst, wenn Wert tatsächlich fliesst. ","date":"18. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-der-erste-weg-von-devops/","section":"Blogs","summary":"Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.\n","title":"Was ist der erste Weg von DevOps? Den Flow optimieren","type":"blogs"},{"content":"The first way to introduce DevOps is to optimise the value flow from development, through operations, all the way to the customer. This is the First Way in Gene Kim\u0026rsquo;s Three Ways framework — and it is where every transformation should start.\nValue Lives at the Customer # The thing to internalise is this: value only exists when the customer can use the feature. Code on a developer laptop is not value. A merged pull request is not value. A binary in an artifact registry is not value. The full distance from \u0026ldquo;we had an idea\u0026rdquo; to \u0026ldquo;the customer is using it\u0026rdquo; is the value flow, and the goal of the First Way is to make that flow as fast and predictable as possible.\nIf a feature takes six months to travel that distance, you have a flow problem. The fix is not to push developers harder. It is to look at the entire pipeline — handoffs, queues, approvals, environment provisioning, deployments — and remove what slows the flow down.\nMake the Work Visible # You cannot improve what you cannot see. The first concrete move is to make work visible across the whole value stream. Every piece of work in flight, in every stage, on a board everyone can look at. Not just dev tickets — also ops tickets, deployment requests, change approvals, security reviews. The moment you see it all in one place, the bottlenecks become obvious. There is always a column where cards pile up.\nThis is also where the cultural shift starts. When dev and ops see the same board, they stop optimising their local queue and start thinking about the system.\nShrink the Batch Size # Big batches are slow batches. A release that bundles 80 features takes longer to test, longer to deploy, longer to debug when something goes wrong, and longer to roll back. A release that contains one feature is fast on every one of those dimensions.\nShrinking batch size is the single most powerful flow lever you have. Smaller commits, smaller pull requests, smaller deployments, smaller releases. As batch size goes down, lead time goes down, quality goes up, and the team\u0026rsquo;s confidence goes up — because each change is small enough to reason about.\nShorten the Work Intervals # Alongside batch size, look at work intervals. How often do you deploy? How often do you release? How often do you run the test suite? If the answer is \u0026ldquo;weekly\u0026rdquo; or \u0026ldquo;monthly\u0026rdquo;, every interval is a queue where work waits. Shortening the interval — daily deployments, continuous test runs, on-demand releases — converts those queues into flow.\nThis is what makes deployment a non-event. When you deploy ten times a day, deployment becomes routine. When you deploy once a quarter, deployment becomes a high-stakes ceremony with a war room and a rollback plan.\nQuality at the Source # Optimising flow does not mean cutting corners. It means putting quality where it belongs — at the source. Automated tests, code review, static analysis, security scans on every commit. The cost of catching a defect at commit time is minutes. The cost of catching it in production is days, plus the customer cost, plus the trust cost. Flow gets faster precisely because quality is built in from the start, not bolted on at the end.\nKey Takeaways # Value lives at the customer, not in the repo. Optimise the whole distance from idea to customer use. Make work visible across the entire value stream. Bottlenecks hide until everything is on one board. Shrink batch size aggressively. Smaller commits, smaller deployments, smaller releases — every dimension wins. Shorten the intervals. Frequent deployments make deployment routine. Rare deployments make it dangerous. Build quality in at the source. Faster flow only works if defects do not flow with it. The First Way prepares the Second. You cannot have meaningful feedback (Second Way) until value actually flows. ","date":"18 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-the-first-way-of-devops/","section":"Blogs","summary":"The first way to introduce DevOps is to optimise the value flow from development, through operations, all the way to the customer. This is the First Way in Gene Kim’s Three Ways framework — and it is where every transformation should start.\n","title":"What Is the First Way of DevOps? Optimise the Flow","type":"blogs"},{"content":"Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein \u0026ldquo;Deploy\u0026rdquo;-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.\nWas Continuous Deployment tatsächlich ist # Mit Continuous Deployment wird jede Änderung, die die CI-Checks und die Staging-Tests besteht, automatisch in Produktion deployed. Die Pipeline ist der Release-Prozess. Es gibt kein separates Release-Event, kein manuelles Approval, kein \u0026ldquo;sind wir bereit?\u0026quot;-Meeting. Sind die Tests grün, ist Produktion aktualisiert.\nDie Auswirkungen sind enorm. Ein Entwickler, der um 10:14 eine kleine Änderung committet, sieht diese Änderung um, sagen wir, 10:32 live bei den Kunden. Der Feedback-Loop schliesst sich in Minuten. Die Kosten, eine einzelne Änderung zu releasen, sinken auf fast null — und die Folge ist, dass die Änderungseinheit winzig wird. Winzige Änderungen sind leicht zu debuggen, leicht zurückzurollen und leicht zu verstehen.\nContinuous Deployment vs. Continuous Delivery # Diese Unterscheidung ist wichtig und wird ständig verwischt:\nContinuous Delivery endet bei Staging. Das Artefakt ist nachweislich releasebar; ein Mensch entscheidet, wann released wird. Continuous Deployment geht den ganzen Weg bis Produktion. Es gibt kein menschliches Gate. Beide werden CD abgekürzt. Wenn jemand sagt \u0026ldquo;wir machen CD\u0026rdquo;, frag nach, was gemeint ist. Wenn es irgendein manuelles Approval vor Produktion gibt, machst du Continuous Delivery, nicht Continuous Deployment. Beides ist legitim; das eine fürs andere zu halten, ist es nicht.\nWas Continuous Deployment verlangt # Continuous Deployment ist nicht nur eine Tooling-Änderung. Es verlangt ein Mass an Disziplin, das die meisten Organisationen unterschätzen:\nTestabdeckung, der man wirklich vertraut. Wenn du das Geschäft nicht auf die Test-Suite verwetten würdest, lass sie nicht unbeaufsichtigt deployen. Continuous Deployment legt jede Lücke in den Tests direkt vor die Kunden. Schnelles, zuverlässiges Rollback. Es wird etwas durchrutschen. Die richtige Antwort ist nicht \u0026ldquo;wir hören auf zu deployen\u0026rdquo;, sondern \u0026ldquo;wir machen Rollback schneller als das nächste Deploy\u0026rdquo;. Monitoring und Alerting, das in Minuten reagiert. Wenn du Dutzende Male pro Tag deployst, kannst du nicht warten, bis der Support meldet, dass etwas kaputt ist. Feature Toggles, um Deployment vom Release zu trennen. Code kann in Produktion sein, ohne für Nutzer sichtbar zu sein. Genau das macht das Deployment wirkungsstarker Änderungen sicher. Kleine, fokussierte Commits. Big-Bang-Änderungen und Continuous Deployment vertragen sich nicht. Das ganze Modell setzt voraus, dass die Änderungseinheit klein ist. Fehlt eines dieser Stücke, ist Continuous Deployment nicht aggressiv — es ist fahrlässig.\nWarum sich Continuous Deployment auszahlt # Wenn es funktioniert, kumuliert sich der Effekt. Releases werden zum Nicht-Ereignis. Hotfixes gehen in Minuten raus, statt auf ein Release-Fenster zu warten. Experimente sind günstig, also macht das Team mehr davon. In Produktion gefundene Bugs sind schneller gefixt und deployed, als sie in einem langsameren Modell triagiert werden könnten. Time-to-Market kollabiert für die Dinge, die wirklich zählen.\nDas meistzitierte Beispiel ist Amazon, das bekanntermassen tausende Male pro Tag über seine Services deployed. Der Punkt ist nicht die absolute Zahl — der Punkt ist, dass Releases so routiniert geworden sind, dass niemand mehr darüber nachdenkt. Die Aufmerksamkeit des Teams geht dahin zurück, wo sie hingehört: Dinge zu bauen, die Kunden interessieren.\nWann du Continuous Deployment nicht machen solltest # Continuous Deployment ist nicht immer die richtige Antwort. Regulierte Umgebungen verlangen unter Umständen aus Compliance-Gründen ein explizites menschliches Sign-off. Mobile Apps durchlaufen Store Approval — es gibt kein \u0026ldquo;Auto-Deploy in den App Store\u0026rdquo;. Koordinierte Marketing-Launches brauchen einen kontrollierten Release-Moment. In allen diesen Fällen ist Continuous Delivery mit einem manuellen Release-Button das richtige Modell. Sei ehrlich mit deinen Rahmenbedingungen; jag Continuous Deployment nicht als Statussymbol hinterher.\nKey Takeaways # Continuous Deployment entfernt das letzte manuelle Gate. Jede bestandene Änderung geht automatisch in Produktion. Es ist nicht dasselbe wie Continuous Delivery. Delivery endet bei Staging; Deployment geht den ganzen Weg. Die Trade-offs sind unterschiedlich. Die Änderungseinheit muss klein sein. Grosse Releases und Continuous Deployment sind unvereinbar. Tests, Rollback und Monitoring müssen stehen, bevor du den Schalter umlegst. Ohne sie ist automatisches Deployment automatischer Schaden. Trenne Deployment vom Release mit Feature Toggles. Code in Produktion muss nicht heissen, dass Features für Nutzer sichtbar sind. Es ist nicht immer das richtige Ziel. Regulierung, Store Approval oder koordinierte Launches machen Continuous Delivery für manche Produkte zur besseren Antwort. ","date":"6. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-continuous-deployment/","section":"Blogs","summary":"Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein “Deploy”-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.\n","title":"Was ist Continuous Deployment (CD)?","type":"blogs"},{"content":"Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No \u0026ldquo;deploy\u0026rdquo; button, no Friday-afternoon release window, no human in the loop for the final step.\nWhat Continuous Deployment Actually Is # With Continuous Deployment, every change that passes the CI checks and the staging tests is automatically deployed to production. The pipeline is the release process. There is no separate release event, no manual approval, no \u0026ldquo;are we ready?\u0026rdquo; meeting. If the tests are green, production is updated.\nThe implications are huge. A developer who commits a small change at 10:14 sees that change live to customers at, say, 10:32. The feedback loop closes in minutes. The cost of releasing a single change drops to almost zero, which means the unit of change becomes tiny — and tiny changes are easy to debug, easy to roll back, and easy to reason about.\nContinuous Deployment vs. Continuous Delivery # This distinction matters and gets blurred constantly:\nContinuous Delivery stops at staging. The artifact is provably releasable; a human decides when to release it. Continuous Deployment goes all the way to production. There is no human gate. Both abbreviate to CD. When someone says \u0026ldquo;we do CD,\u0026rdquo; ask which one. If there is any manual approval before production, you are doing Continuous Delivery, not Continuous Deployment. Both are valid; conflating them is not.\nWhat Continuous Deployment Demands # Continuous Deployment is not just a tooling change. It demands a level of discipline most organisations underestimate:\nTest coverage you actually trust. If you would not bet the business on the test suite, do not let it deploy unattended. Continuous Deployment exposes every gap in the tests directly to customers. Fast, reliable rollback. Things will slip through. The right answer is not \u0026ldquo;stop deploying\u0026rdquo; but \u0026ldquo;make rollback faster than the next deploy.\u0026rdquo; Monitoring and alerting that catch issues in minutes. When you deploy dozens of times a day, you cannot wait for the support queue to tell you something broke. Feature toggles to separate deployment from release. Code can be in production without being visible to users. That is what makes deploying high-impact changes safe. Small, focused commits. Big-bang changes and Continuous Deployment do not mix. The whole model assumes the unit of change is small. If any of those pieces is missing, Continuous Deployment is not aggressive — it is reckless.\nWhy Continuous Deployment Pays Off # When it works, Continuous Deployment compounds. Releasing becomes a non-event. Hotfixes ship in minutes instead of waiting for a release window. Experiments are cheap, so the team runs more of them. Bugs found in production are fixed and deployed faster than they could be triaged in a slower model. Time-to-market collapses for the things that actually matter.\nThe most often-cited example is Amazon, which famously deploys thousands of times per day across its services. The point is not the absolute number — it is that releasing has become so routine that nobody thinks about it. The team\u0026rsquo;s attention goes back where it belongs: building things customers care about.\nWhen You Should Not Do Continuous Deployment # Continuous Deployment is not always the right answer. Regulated environments may require explicit human sign-off for compliance reasons. Mobile apps go through store approval — there is no \u0026ldquo;auto-deploy to App Store.\u0026rdquo; Coordinated marketing launches need a controlled release moment. In all of these cases, Continuous Delivery with a manual release button is the right model. Be honest about your constraints; do not chase Continuous Deployment as a status symbol.\nKey Takeaways # Continuous Deployment removes the last manual gate. Every passing change ships to production automatically. It is not the same as Continuous Delivery. Delivery stops at staging; Deployment goes all the way. The trade-offs are different. The unit of change must be small. Big releases and Continuous Deployment are incompatible. Tests, rollback, and monitoring must be ready before you flip the switch. Without them, automatic deployment is automatic damage. Separate deployment from release with feature toggles. Code in production does not have to mean features visible to users. It is not always the right destination. Regulation, store approval, or coordinated launches make Continuous Delivery the better answer for some products. ","date":"6 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-continuous-deployment/","section":"Blogs","summary":"Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No “deploy” button, no Friday-afternoon release window, no human in the loop for the final step.\n","title":"What Is Continuous Deployment (CD)?","type":"blogs"},{"content":"","date":"5 August 2020","externalUrl":null,"permalink":"/en/tags/deployment/","section":"Tags","summary":"","title":"Deployment","type":"tags"},{"content":"Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.\nWas Continuous Delivery tatsächlich ist # Continuous Delivery nimmt das Artefakt aus der CI und deployed es automatisch in eine produktionsähnliche Umgebung — meist Staging genannt — wo ein weiteres Set automatisierter Tests dagegen läuft. End-to-End-Tests, Performance-Tests, Contract Tests, Security-Tests wie DAST, manchmal sogar Penetration Tests. Ziel ist es, die Probleme zu finden, die erst auftauchen, wenn die Software wirklich läuft, mit echten Services spricht und echte Datenformen verarbeitet.\nWichtig: Das Deployment nach Staging ist automatisch, aber das Release in Produktion nicht. Continuous Delivery bedeutet, dass die Software jederzeit releasbar ist — aber ein Mensch (oder eine Business-Regel) entscheidet, wann sie tatsächlich an die Kunden geht. Du bekommst einen Knopf. Du drückst ihn, wenn das Business bereit ist.\nContinuous Delivery vs. Continuous Deployment # Das ist die häufigste Verwechslung im gesamten CI/CD-Vokabular, deshalb hier ganz explizit:\nContinuous Delivery = jede Änderung wird automatisch nach Staging deployed und könnte nach Produktion released werden. Die Release-Entscheidung ist manuell. Continuous Deployment = jede Änderung, die alle automatisierten Tests besteht, geht automatisch in Produktion. Es gibt kein manuelles Gate. Beide teilen sich die Abkürzung CD — das ist tatsächlich unglücklich. Wenn jemand sagt \u0026ldquo;wir machen CD\u0026rdquo;, frag nach, welches gemeint ist. Die Trade-offs sind unterschiedlich, die nötige organisatorische Reife ist unterschiedlich, und das Risikoprofil ist unterschiedlich.\nWarum Continuous Delivery für die meisten Teams der Sweet Spot ist # Die meisten Organisationen sind noch nicht reif für Continuous Deployment, und das ist in Ordnung. Regulierte Industrien, Consumer-Produkte mit marketingkoordinierten Launches, mobile Apps mit Store Approval — alle haben legitime Gründe, einen Menschen für die finale Release-Entscheidung im Loop zu behalten.\nContinuous Delivery liefert fast alle Vorteile, ohne diese Entscheidung zu erzwingen. Die Pipeline beweist, dass jede Änderung theoretisch live gehen könnte. Das Artefakt ist gebaut, getestet, nach Staging deployed, nochmal getestet. Das Risiko beim Release ist klein, weil beim Release nichts Überraschendes passiert. Der Deployment-Mechanismus ist schon Hunderte Male gelaufen. Releases werden zur Routine statt zum Event.\nWas im Continuous-Delivery-Schritt läuft # Ein typischer Continuous-Delivery-Schritt ergänzt zur CI:\nAutomatisches Provisioning oder Update der Staging-Umgebung. Deployment des Artefakts nach Staging mit demselben Mechanismus, den Produktion verwendet. End-to-End-Tests gegen das laufende System. Performance- und Load-Tests mit repräsentativen Daten. Dynamic Application Security Testing (DAST), das nur gegen ein laufendes System funktioniert. Smoke Tests, die Integrationen mit nachgelagerten Systemen prüfen. Alles, was ein laufendes System, echte Datenformen oder echtes Netzwerkverhalten braucht, gehört hier hin.\nDie Disziplin, die Continuous Delivery verlangt # Continuous Delivery funktioniert nur, wenn die Staging-Umgebung wie Produktion aussieht — gleiches Configuration Management, gleicher Deployment-Mechanismus, gleiches Datenbanksystem, im Idealfall gleicher Massstab. Unterschiede zwischen Staging und Produktion sind die Stellen, an denen Bugs sich verstecken. Behandle Configuration Drift zwischen Umgebungen als Defekt, nicht als Feature.\nAusserdem muss der Deployment-Prozess selbst Code sein. Manuelle Schritte, Notizen in einem Wiki, \u0026ldquo;frag den Karl, der weiss es\u0026rdquo; — das skaliert nicht. Wenn ein Mensch während des Deployments etwas tun muss, ist das Deployment noch nicht wirklich automatisiert.\nKey Takeaways # Continuous Delivery deployed jedes Artefakt automatisch in eine produktionsähnliche Umgebung. Das Release nach Produktion bleibt eine menschliche Entscheidung. Verwechsle Delivery nicht mit Deployment. Beide werden CD abgekürzt, aber das zweite entfernt das manuelle Gate. Sei präzise, was du tatsächlich machst. Es geht darum, jederzeit releasebar zu sein. Egal ob du den Knopf bei jeder Änderung drückst — die Option muss da sein. Staging muss wie Produktion aussehen. Drift zwischen Umgebungen ist die Stelle, an der Bugs sich verstecken. Deployment muss Code sein, nicht Schritte in einem Wiki. Manuelle Schritte brechen die Kette und das Vertrauen. Für die meisten Teams ist Continuous Delivery das richtige Ziel. Continuous Deployment ist der nächste Schritt — aber erst, wenn Organisation, Tests und Monitoring dafür bereit sind. ","date":"5. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-continuous-delivery/","section":"Blogs","summary":"Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.\n","title":"Was ist Continuous Delivery (CD)?","type":"blogs"},{"content":"Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.\nWhat Continuous Delivery Actually Is # Continuous Delivery takes the artifact produced by CI and automatically deploys it into a production-like environment — usually called staging — where another set of automated tests runs against it. End-to-end tests, performance tests, contract tests, security tests like DAST, sometimes even penetration tests. The goal is to find the problems that only appear when the software is actually running, talking to real services, against real-shaped data.\nCrucially, deployment to staging is automatic, but the release to production is not. Continuous Delivery means the software is always in a releasable state — but a human (or a business rule) decides when to actually push it to customers. You get a button. You press it when the business is ready.\nContinuous Delivery vs. Continuous Deployment # This is the most common source of confusion in the whole CI/CD vocabulary, so it is worth being explicit:\nContinuous Delivery = every change is automatically deployed to staging and could be released to production. The decision to release is manual. Continuous Deployment = every change that passes all automated tests is automatically released to production. There is no manual gate. Both share the same abbreviation — CD — and that is genuinely unhelpful. When someone says \u0026ldquo;we do CD,\u0026rdquo; ask which one. The trade-offs are different, the organisational maturity required is different, and the risk profile is different.\nWhy Continuous Delivery Is the Sweet Spot for Most Teams # Most organisations are not ready for Continuous Deployment, and that is fine. Regulated industries, customer-facing products with marketing-coordinated launches, mobile apps that need store approval — all of these have legitimate reasons to keep a human in the loop for the final release decision.\nContinuous Delivery gives you almost all the benefits without forcing that decision. The pipeline proves that every change could go live. The artifact is built, tested, deployed to staging, tested again. The risk of release is small because nothing surprising happens at release time. The deployment mechanism has run hundreds of times before. Releasing becomes routine instead of an event.\nWhat Runs in the Continuous Delivery Stage # A typical Continuous Delivery stage adds, on top of CI:\nAutomated provisioning or update of the staging environment. Deployment of the artifact to staging using the same mechanism that production will use. End-to-end tests against the running system. Performance and load tests on representative data. Dynamic application security testing (DAST), which can only run against a live service. Smoke tests that verify integrations with downstream systems. Everything that needs a running system, real data shapes, or real network behaviour belongs here.\nThe Discipline Continuous Delivery Demands # Continuous Delivery only works if the staging environment looks like production — same configuration management, same deployment mechanism, same database engine, ideally the same scale. Differences between staging and production are where bugs hide. Treat configuration drift between environments as a defect, not a feature.\nIt also requires the deployment process itself to be code. Manual steps, side notes in a wiki, \u0026ldquo;ask Karl, he knows\u0026rdquo; — none of that scales. If a human has to do something during deployment, the deployment is not really automated yet.\nKey Takeaways # Continuous Delivery deploys every artifact to a production-like environment automatically. The release to production stays a human decision. Don\u0026rsquo;t confuse Delivery with Deployment. Both are abbreviated CD, but the second one removes the manual gate. Be precise about which one you actually do. The point is being always releasable. Whether or not you press the button on every change, the option must be there. Staging must look like production. Drift between environments is where bugs hide. Deployment must be code, not steps in a wiki. Manual steps break the chain and break the trust. For most teams, Continuous Delivery is the right destination. Continuous Deployment is the next step — but only when the organisation, the tests, and the monitoring are ready for it. ","date":"5 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-continuous-delivery/","section":"Blogs","summary":"Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.\n","title":"What Is Continuous Delivery (CD)?","type":"blogs"},{"content":"In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.\nInsight in brief # In the Continuous Integration (CI) step, the new code is merged with the source code, built and tested In the Continuous Deployment (CD) step, the software package is automatically deployed to production With Continuous Integration and Continuous Delivery/Deployment, companies can increase the feedback cycle and throughput speed Continuous integration (CI) # In modern software development, this step is carried out every time the source code is changed, using a method known as «continuous integration». The changed source code is merged with the remaining source code, built and tested. The developer receives immediate feedback on whether their changes are acceptable.\nBy doing continuous integration the changes are merged and tested immediately. And because the changes are smaller, there is less risk of them resulting in problems. Should a change nevertheless lead to a problem, it can be spotted right away, assigned and fixed. Continuous integration forms the basis for continuous delivery or continuous deployment.\nContinuous delivery (CD) # Although continuous integration is used to integrate the software, the software is not yet deployed in a production-like environment, where it can be tested. With continuous delivery, the software package is deployed in a production-like environment and automatically tested once it has passed all tests on the continuous integration server. This additional step makes it possible to spot problems that could otherwise only be identified when deploying the software live or during operation.\nContinuous deployment (CD) # With continuous deployment, each change is automatically deployed to production once it has passed all tests on the continuous integration server and the automatic tests in the production-like environment. Continuous deployment builds on continuous delivery and continuous integration, which form the basis of it.\nCompanies are increasingly confronted with the challenge of enhancing efficiency while lowering costs. And approved changes to a product often take too long to reach customers in the marketplace. Continuous integration and continuous delivery/deployment enable companies to accelerate the feedback cycle and throughput speed, which means they can react more quickly to changes and keep their customers happy.\nOriginal Post: Medium\n","date":"4 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-ci-cd/","section":"Blogs","summary":"In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.\n","title":"What is CI/CD?","type":"blogs"},{"content":"In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.\nWas Continuous Integration tatsächlich ist # Continuous Integration ist die Praxis, jede Code-Änderung sofort in die gemeinsame Codebasis zu mergen — und gleich zu beweisen, dass sie noch funktioniert. Jeder Commit löst einen automatisierten Prozess auf einem CI-Server aus: Der neue Code wird mit dem bestehenden Source gemergt, das Projekt wird gebaut, und eine automatisierte Test-Suite läuft gegen das Ergebnis. Der Entwickler, der den Commit gemacht hat, bekommt sofort Feedback, ob die Änderung in Ordnung ist.\nDas Schlüsselwort ist sofort. Nicht am Ende des Sprints, nicht vor dem nächsten Release — innerhalb von Minuten nach dem Commit.\nWarum kleine, häufige Merges gewinnen # Wenn Integrationen selten und gross sind, ist jeder Merge riskant. Wenn Integrationen häufig und klein sind, ist jeder Merge sicher. Das ist die ganze Erkenntnis.\nWeil jede Änderung winzig ist, sind auch die Konflikte winzig. Wenn doch etwas kaputtgeht, weiss man genau, welcher Commit es war — es gibt nur eine Handvoll Zeilen, die man anschauen muss. Der Fix ist schnell. Vergleich das mit einer Regression in einem dreimonatigen Integrationsfenster mit Hunderten Commits von einem Dutzend Entwicklern und ohne offensichtlichen Startpunkt für die Suche.\nCI hält die Codebasis ausserdem ehrlich. Der Code auf main ist immer in einem bekannten Zustand: gebaut und getestet. Es gibt keine \u0026ldquo;Integrationsphase\u0026rdquo; mehr im Kalender. Die Integrationsphase ist jetzt.\nWas in einer CI-Pipeline läuft # Eine typische CI-Pipeline macht mindestens das hier bei jedem Commit:\nHolt den aktuellen Source und mergt die Änderung. Kompiliert oder baut das Projekt. Führt statische Code-Analyse aus (Linting, Style-Checks). Führt Unit Tests und die schnellen Integrationstests aus. Erzeugt ein deploybares Artefakt (Binary, Container Image, Package). Moderne Pipelines ergänzen statische Security-Analyse (SAST), Secret Detection und Dependency Scanning im selben Schritt. Der Punkt ist: Alles, was günstig und schnell ist, passiert hier, bei jedem Commit, ohne dass jemand daran denken muss.\nFeedback-Zeit ist die eigentliche Metrik # Die wichtigste Eigenschaft einer CI-Pipeline ist, wie lange sie braucht, um dem Entwickler eine Antwort zu geben. Ist der Build schnell — Minuten, nicht Stunden — ist der Entwickler noch im Kontext der Änderung, wenn das Feedback kommt. Er kann das Problem sofort beheben, während sein Kopf noch in diesem Stück Code ist.\nDauert die Pipeline Stunden, hat der Entwickler längst etwas anderes angefangen. Wenn der Fehler dann erscheint, muss er den Kontext zurück in ein Problem laden, das er als gelöst betrachtet hat. Der Aufwand für diesen Kontextwechsel frisst den Vorteil des frühen Findens fast komplett wieder auf. Behandle die Pipeline-Dauer als Feature, nicht als Implementierungsdetail.\nDie Grundlage, auf der alles andere aufbaut # CI ist nicht die ganze Geschichte — es endet mit einem getesteten Artefakt, nicht mit einem Deployment. Aber es ist die Grundlage, auf der Continuous Delivery und Continuous Deployment aufbauen. Ohne vertrauenswürdige CI bedeutet Deployment-Automatisierung nur, schlechten Code schneller auszuliefern. Mach CI zuerst richtig.\nKey Takeaways # Jeder Commit wird automatisch integriert, gebaut und getestet. Integration ist kein Event mehr, sondern ein Dauerzustand. Kleine Änderungen sind sichere Änderungen. Winzige Commits machen Konflikte trivial und Ursachen offensichtlich. Feedback in Minuten ist das eigentliche Ziel. Eine langsame Pipeline zerstört den grössten Teil des Vorteils des frühen Findens. CI endet mit einem Artefakt, nicht mit einem Deployment. Es ist die Grundlage für Continuous Delivery und Continuous Deployment, kein Ersatz dafür. Security gehört von Anfang an in die Pipeline. SAST, Secret Scanning und Dependency Checks gehören in die CI, nicht in ein separates Gate am Ende. ","date":"4. August 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-continuous-integration/","section":"Blogs","summary":"In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.\n","title":"Was ist Continuous Integration (CI)?","type":"blogs"},{"content":"In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.\nWhat Continuous Integration Actually Is # Continuous Integration is the practice of merging every code change into the shared codebase as soon as it is made — and proving it still works. Each commit triggers an automated process on a CI server: the new code is merged with the existing source, the project is built, and an automated test suite runs against the result. The developer who pushed the change gets immediate feedback on whether the change is acceptable.\nThe keyword is immediate. Not at the end of the sprint, not before the next release — within minutes of the commit.\nWhy Small, Frequent Merges Win # When integrations are rare and big, every merge is risky. When integrations are frequent and small, every merge is safe. That is the whole insight.\nBecause each change is tiny, conflicts are tiny too. If something does break, you know exactly which commit caused it — there are only a handful of lines to inspect. The fix is fast. Compare that with finding a regression in a three-month integration window, where you have hundreds of commits from a dozen developers and no obvious place to look.\nCI also keeps the codebase honest. The code on main is always in a known state: built and tested. There is no \u0026ldquo;integration phase\u0026rdquo; looming on the calendar. The integration phase is now.\nWhat Runs in a CI Pipeline # A typical CI pipeline does at least these things on every commit:\nPulls the latest source and merges the change. Compiles or builds the project. Runs static code analysis (linting, style checks). Runs unit tests and the fast integration tests. Produces a deployable artifact (a binary, a container image, a package). Modern pipelines add static security analysis (SAST), secret detection, and dependency scanning to the same step. The point is that everything cheap and fast happens here, on every commit, without anyone having to remember.\nFeedback Time Is the Real Metric # The single most important property of a CI pipeline is how long it takes to give the developer an answer. If the build is fast — minutes, not hours — the developer is still in the context of the change when feedback arrives. They can fix the issue immediately, while their head is still in that piece of code.\nIf the pipeline takes hours, the developer has already moved on. By the time the failure shows up, they have to context-switch back into a problem they already considered solved. The cost of that switch wipes out most of the value of catching issues early. Treat pipeline duration as a feature, not an implementation detail.\nThe Foundation Everything Else Builds On # CI is not the whole story — it ends with a tested artifact, not a deployed one. But it is the foundation that Continuous Delivery and Continuous Deployment build on. Without trustworthy CI, automating deployment just means shipping bad code faster. Get CI right first.\nKey Takeaways # Every commit is integrated, built, and tested automatically. Integration stops being an event and becomes a continuous state. Small changes are safe changes. Tiny commits make conflicts trivial and root causes obvious. Feedback in minutes is the real goal. A slow pipeline destroys most of the value of catching issues early. CI ends with an artifact, not a deployment. It is the foundation for Continuous Delivery and Continuous Deployment, not a replacement for them. Bake security in from the start. SAST, secret scanning, and dependency checks belong in CI, not in a separate gate at the end. ","date":"4 August 2020","externalUrl":null,"permalink":"/en/blogs/what-is-continuous-integration/","section":"Blogs","summary":"In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.\n","title":"What Is Continuous Integration (CI)?","type":"blogs"},{"content":"A value stream is the path that value takes from the first idea all the way into production. It is the sum of every step, handover, and wait in between. In this video, I walk through a simple seven-step approach for identifying a value stream, measuring how it really performs, designing a target state, and then improving it step by step. The numbers in the example are simplified on purpose, so the method shines through more clearly than any single result.\nStep 1: Identify the Value Stream # The first move is always the same: pick a value stream and draw it. In my example I use a very classical, simplified flow. It starts with an idea, for instance a new feature. From there, we move on to writing the specification, implementing the feature, manually testing it, and finally manually deploying it into production.\nThis is not a complicated diagram. Five boxes in a row are enough. What matters is that you make the steps explicit, because you cannot improve what you have not seen. Once the value stream is on paper, everyone looks at the same picture and suddenly the conversation changes from opinions to observations.\nStep 2: Identify the People in the Stream # The next step is to identify who is actually working in each step of the value stream. In my example, the business has the idea and also writes the business specification. The developers implement the feature. A quality engineer manually tests it. And operations manually deploys it into production.\nDoing this exercise sounds trivial, but it quickly exposes how many handovers there are. Every transition between these groups is a potential source of delay, rework, and miscommunication. When you can literally see which hands touch a feature between idea and production, you start to understand why things take so long, even though no single person seems to be slow.\nStep 3: Measure What Really Happens # Now we measure. For every step I look at three numbers: process time, lead time, and percentage complete and accurate.\nProcess time is the time actual work is being done. Lead time is the time from when a task enters a step until it leaves it, including all the waiting in between. Percentage complete and accurate tells us how often the work going into the next step is actually good enough, or how often it gets rejected and has to come back.\nIn the example, the numbers look like this:\nIdea: process time 8 hours, lead time 8 hours, percentage complete and accurate 75 percent. Writing specification: process time 40 hours, lead time 80 hours, percentage complete and accurate 50 percent. Implementation: process time 40 hours, lead time 80 hours, percentage complete and accurate 75 percent. Manual testing: process time 16 hours, lead time 40 hours, percentage complete and accurate 50 percent. Manual deployment: process time 1 hour, lead time 8 hours, percentage complete and accurate 80 percent. These three numbers per step are enough to have a very honest conversation about the state of the system. They are also something you can actually collect, without having to buy expensive tooling.\nStep 4: Analyze the Current State # With the measurements on the table, we sum things up. In this example, the total process time is 105 hours and the total lead time is 216 hours. The rolling percentage complete and accurate is only 11 percent, which means that only 11 out of 100 ideas make it cleanly through this pipeline without rework somewhere. The activity ratio, total process time divided by total lead time, is roughly 48 percent.\nDuring the analysis I also look at where the bottlenecks are, where handovers cause long waiting times, and where the gap between process time and lead time is the biggest. That gap is where your ideas are sitting in queues, not being worked on. In most value streams, that is where the biggest opportunities for improvement hide.\nStep 5: Design the Target Value Stream # Once we understand the current state, we design the future. The target value stream uses the same structure, but the steps and the numbers are different.\nIdea by the business: process time 8 hours, lead time 8 hours, percentage complete and accurate 100 percent. Instead of writing specifications, the team writes user stories: process time 8 hours, lead time 8 hours, percentage complete and accurate 100 percent. Implementation, again by the team: process time 20 hours, lead time 40 hours, percentage complete and accurate 80 percent. Continuous integration replaces manual testing. The build server builds and tests automatically: process time 0.1 hour, lead time 0.1 hour, percentage complete and accurate 100 percent. Continuous deployment replaces manual deployment, going into UAT and then production automatically: process time 0.1 hour, lead time 0.1 hour, percentage complete and accurate 100 percent. The implementation step looks less perfect at 80 percent complete and accurate, and that is by design. The continuous integration system is allowed to reject implementations when a test fails. That is exactly what automated testing is for. The rework happens in seconds, not in days.\nAdding it all up: the target has a total process time of 36.2 hours, a total lead time of 56.2 hours, a rolling percentage complete and accurate of 80 percent, and an activity ratio of roughly 64 percent. In plain terms: 80 percent of ideas go straight to production, and your people spend a much larger share of their time on actual work instead of waiting.\nStep 6: Define the Measures to Get There # The target is not the plan. The plan is the set of concrete steps you take to move from the current state to the target. I compare both value streams side by side and identify exactly what needs to change: what has to be automated, which handovers can be removed, which roles need to shift, which architectural changes are needed for continuous integration and continuous deployment to work.\nThen I prioritize those measures and put them into a backlog. This is important: improving a value stream is not a big-bang project. It is a sequence of small, prioritized changes that you execute together with the people in the stream.\nStep 7: Repeat the Exercise # The last step is the most important one, and it is the one most organizations forget. Value stream analysis is not a one-off exercise. It is something you repeat. I would typically do it every three months and look at how the stream has moved toward the target.\nThe reality on the ground changes. New tooling becomes available. The team learns. Bottlenecks shift. Without regular reviews, the value stream drifts back into old patterns, and all the effort you invested earlier quietly evaporates. If you repeat the exercise, improvement becomes a habit instead of an event.\nKey Takeaways # Make the value stream visible first. Draw the steps from idea to production and name the people in each step. You cannot improve what you have not made explicit.\nMeasure process time, lead time, and percentage complete and accurate. These three numbers are simple, honest, and enough to expose where the real problems are.\nPay attention to the gap between process time and lead time. That is where your work sits in queues. Most of your lead time reduction will come from removing waiting, not from working faster.\nDesign a target value stream, then engineer toward it. Replace manual testing with continuous integration, manual deployment with continuous deployment, and specifications with user stories written by the team.\nPrioritize a backlog of concrete improvements. Compare current and target, identify the measures needed, prioritize them, and execute them like any other piece of work.\nRepeat every three months. Continuous improvement is the real output of this exercise. One analysis alone changes very little; a cadence changes the organization.\n","date":"3 August 2020","externalUrl":null,"permalink":"/en/blogs/how-to-improve-value-streams/","section":"Blogs","summary":"A value stream is the path that value takes from the first idea all the way into production. It is the sum of every step, handover, and wait in between. In this video, I walk through a simple seven-step approach for identifying a value stream, measuring how it really performs, designing a target state, and then improving it step by step. The numbers in the example are simplified on purpose, so the method shines through more clearly than any single result.\n","title":"How to Improve Value Streams: A Seven-Step Approach","type":"blogs"},{"content":"","date":"3. August 2020","externalUrl":null,"permalink":"/de/tags/wertstr%C3%B6me/","section":"Tags","summary":"","title":"Wertströme","type":"tags"},{"content":"Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.\nSchritt 1: Den Wertstrom identifizieren # Der erste Schritt ist immer derselbe: einen Wertstrom auswählen und aufzeichnen. In meinem Beispiel nehme ich einen sehr klassischen, vereinfachten Ablauf. Er beginnt mit einer Idee, zum Beispiel einem neuen Feature. Danach wird die Spezifikation geschrieben, das Feature implementiert, manuell getestet und schliesslich manuell in die Produktion deployed.\nDas ist kein kompliziertes Diagramm. Fünf Boxen hintereinander reichen. Entscheidend ist, dass man die Schritte explizit macht, denn verbessern kann man nur, was man sichtbar gemacht hat. Sobald der Wertstrom auf dem Papier steht, schauen alle auf dasselbe Bild und das Gespräch dreht sich plötzlich nicht mehr um Meinungen, sondern um Beobachtungen.\nSchritt 2: Die Menschen im Wertstrom identifizieren # Im nächsten Schritt schaut man, wer in jedem Schritt tatsächlich arbeitet. In meinem Beispiel hat das Business die Idee und schreibt auch die Business-Spezifikation. Die Entwickler implementieren das Feature. Ein Quality Engineer testet manuell. Und Operations deployt das Feature manuell in die Produktion.\nDiese Übung klingt trivial, macht aber schnell deutlich, wie viele Übergaben im Spiel sind. Jede Übergabe zwischen diesen Gruppen ist eine potenzielle Quelle für Verzögerung, Rework und Missverständnisse. Wenn man buchstäblich sieht, wie viele Hände ein Feature zwischen Idee und Produktion berühren, versteht man schnell, warum alles so lange dauert, obwohl niemand wirklich langsam ist.\nSchritt 3: Messen, was wirklich passiert # Jetzt wird gemessen. Für jeden Schritt schaue ich auf drei Zahlen: Process Time, Lead Time und Percentage Complete and Accurate.\nProcess Time ist die Zeit, in der tatsächlich gearbeitet wird. Lead Time ist die Zeit vom Eintritt einer Aufgabe in einen Schritt bis zum Austritt, inklusive aller Wartezeiten dazwischen. Percentage Complete and Accurate sagt, wie oft die Arbeit, die weitergegeben wird, gut genug ist, oder wie oft sie zurückgeschickt und erneut gemacht werden muss.\nIm Beispiel sehen die Zahlen so aus:\nIdee: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 75 Prozent. Spezifikation schreiben: Process Time 40 Stunden, Lead Time 80 Stunden, Percentage Complete and Accurate 50 Prozent. Implementierung: Process Time 40 Stunden, Lead Time 80 Stunden, Percentage Complete and Accurate 75 Prozent. Manuelles Testen: Process Time 16 Stunden, Lead Time 40 Stunden, Percentage Complete and Accurate 50 Prozent. Manuelles Deployment: Process Time 1 Stunde, Lead Time 8 Stunden, Percentage Complete and Accurate 80 Prozent. Diese drei Zahlen pro Schritt reichen, um eine sehr ehrliche Diskussion über den Zustand des Systems zu führen. Und sie sind etwas, das man ohne teures Tooling wirklich erheben kann.\nSchritt 4: Den Ist-Zustand analysieren # Mit den Messungen auf dem Tisch wird zusammengezählt. Im Beispiel ergibt das eine Total Process Time von 105 Stunden und eine Total Lead Time von 216 Stunden. Die Rolling Percentage Complete and Accurate liegt bei nur 11 Prozent. Das heisst: Von 100 Ideen kommen nur 11 sauber durch diese Pipeline, ohne irgendwo nachgebessert zu werden. Die Activity Ratio, also Total Process Time geteilt durch Total Lead Time, liegt bei rund 48 Prozent.\nIn der Analyse schaue ich auch darauf, wo die Bottlenecks liegen, wo Übergaben lange Wartezeiten erzeugen und wo die Differenz zwischen Process Time und Lead Time am grössten ist. Genau in dieser Differenz sitzen die Ideen in Warteschlangen und werden gerade nicht bearbeitet. In den meisten Wertströmen steckt dort das grösste Verbesserungspotenzial.\nSchritt 5: Den Ziel-Wertstrom entwerfen # Sobald wir den Ist-Zustand verstehen, entwerfen wir die Zukunft. Der Ziel-Wertstrom nutzt dieselbe Struktur, aber die Schritte und Zahlen sehen anders aus.\nIdee durch das Business: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 100 Prozent. Statt Spezifikationen schreibt das Team User Stories: Process Time 8 Stunden, Lead Time 8 Stunden, Percentage Complete and Accurate 100 Prozent. Implementierung, wieder durch das Team: Process Time 20 Stunden, Lead Time 40 Stunden, Percentage Complete and Accurate 80 Prozent. Continuous Integration ersetzt das manuelle Testen. Der Build-Server baut und testet automatisch: Process Time 0,1 Stunden, Lead Time 0,1 Stunden, Percentage Complete and Accurate 100 Prozent. Continuous Deployment ersetzt das manuelle Deployment, zuerst in UAT und dann automatisch in die Produktion: Process Time 0,1 Stunden, Lead Time 0,1 Stunden, Percentage Complete and Accurate 100 Prozent. Dass die Implementierung nur bei 80 Prozent Complete and Accurate liegt, ist kein Versehen. Die Continuous-Integration-Pipeline darf Implementierungen zurückweisen, wenn ein Test fehlschlägt. Genau dafür sind automatisierte Tests da. Das Rework passiert in Sekunden, nicht in Tagen.\nZusammengezählt ergibt das Zielbild eine Total Process Time von 36,2 Stunden, eine Total Lead Time von 56,2 Stunden, eine Rolling Percentage Complete and Accurate von 80 Prozent und eine Activity Ratio von rund 64 Prozent. Im Klartext: 80 Prozent der Ideen gehen direkt in die Produktion, und die Leute verbringen einen deutlich grösseren Teil ihrer Zeit mit echter Arbeit statt mit Warten.\nSchritt 6: Massnahmen definieren # Das Zielbild ist nicht der Plan. Der Plan ist die Liste konkreter Schritte, mit denen ich vom Ist-Zustand zum Zielbild komme. Ich lege beide Wertströme nebeneinander und identifiziere genau, was sich ändern muss: was automatisiert werden kann, welche Übergaben wegfallen, welche Rollen sich verschieben, welche architektonischen Anpassungen nötig sind, damit Continuous Integration und Continuous Deployment überhaupt funktionieren.\nDiese Massnahmen priorisiere ich und packe sie in ein Backlog. Das ist wichtig: Einen Wertstrom zu verbessern ist kein Big-Bang-Projekt. Es ist eine Folge kleiner, priorisierter Änderungen, die zusammen mit den Menschen im Wertstrom umgesetzt werden.\nSchritt 7: Die Übung wiederholen # Der letzte Schritt ist der wichtigste, und er wird in den meisten Organisationen vergessen. Value Stream Mapping ist keine einmalige Übung. Es ist etwas, das wiederholt wird. Ich würde es typischerweise alle drei Monate machen und anschauen, wie sich der Wertstrom in Richtung Zielbild bewegt hat.\nDie Realität vor Ort verändert sich. Neues Tooling kommt dazu. Das Team lernt. Bottlenecks verschieben sich. Ohne regelmässige Reviews driftet der Wertstrom in alte Muster zurück, und der Aufwand, den man früher investiert hat, verpufft leise. Wer die Übung wiederholt, macht aus Verbesserung eine Gewohnheit statt eines Ereignisses.\nWichtigste Erkenntnisse # Den Wertstrom zuerst sichtbar machen. Die Schritte von der Idee bis zur Produktion aufzeichnen und die Menschen in jedem Schritt benennen. Verbessern kann man nur, was man explizit gemacht hat.\nProcess Time, Lead Time und Percentage Complete and Accurate messen. Diese drei Zahlen sind einfach, ehrlich und reichen aus, um die echten Probleme sichtbar zu machen.\nAuf die Differenz zwischen Process Time und Lead Time achten. Dort sitzt die Arbeit in Warteschlangen. Die meisten Verkürzungen der Lead Time entstehen durch das Entfernen von Wartezeit, nicht durch schnelleres Arbeiten.\nEin Zielbild entwerfen und konsequent darauf hinarbeiten. Manuelles Testen durch Continuous Integration ersetzen, manuelles Deployment durch Continuous Deployment, Spezifikationen durch User Stories aus dem Team.\nEin priorisiertes Backlog an Massnahmen führen. Ist und Ziel vergleichen, nötige Massnahmen ableiten, priorisieren und wie jede andere Arbeit umsetzen.\nAlle drei Monate wiederholen. Continuous Improvement ist das eigentliche Ergebnis dieser Übung. Eine einzelne Analyse verändert wenig, ein Rhythmus verändert die Organisation.\n","date":"3. August 2020","externalUrl":null,"permalink":"/de/blogs/wie-koennen-wir-wertstroeme-verbessern/","section":"Blogs","summary":"Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.\n","title":"Wie können wir Wertströme verbessern? Ein Vorgehen in sieben Schritten","type":"blogs"},{"content":"At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.\nInsight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success. It’s important to start small. Getting started, it’s best to tackle small to medium-sized projects or products. These offer the advantage that changes require much less time and energy because decisions have less impact and involve fewer people. And you will encounter less resistance, as the teams and decision-makers will not feel overwhelmed or paralysed. This will increase self-confidence and create strong momentum.\nPutting together a winning DevOps team # Getting the right people on board is a must. And the golden rule here is: generalists before specialists. It’s also important that your team include innovators, early adopters and people who are respected throughout the company. This ensures that you have sufficient credibility and influence.\nThe brand new DevOps team needs to be freed up from any other work so that they can focus completely on the project. If possible, all team members should work in the same location and be exempted from corporate rules and guidelines wherever possible. This new team will then transform the first project or product thanks to DevOps.\nValue flow # The first step is to optimise the value flow from development, to operations, right through to the customer. The goal is to have features flowing through to the customer as quickly as possible, as it is only there where value is generated. To achieve this, you need to make the work visible, reduce batch volumes and work intervals, and thereby increase quality.\nFeedback # The second step is to introduce a flow of feedback. This ensures that feedback from customers, as well as any production problems, flows through to the business and back into development. And this means that you can discover problems more quickly and resolve them efficiently. You can use focused measurement and usage analysis to show the business which features are used, and how often. This helps the business decide whether a given feature should be expanded or not.\nThis is what the DevOps culture looks like # The third step is to create a culture of trust, which will support experimentation and risk-taking. It will also put the team on a steeper learning curve, enabling it to adjust to market demand faster than the competition.\nCritical mass # As soon as the requested improvements are incorporated into the first product, you should be selecting and transforming the next project or product. This enables you to reach a critical mass, which makes it easier to undertake further transformations with DevOps and build alliances. Repeat this procedure until all desired projects and products are transformed.\nNo magic # A DevOps transformation is not magic. Any company can do it. The important thing is to start small, select the right people for the team and then constantly, continuously improve.\nOriginal Post: Zühlke | Medium\n","date":"30 July 2020","externalUrl":null,"permalink":"/en/blogs/how-to-start-a-devops-transformation/","section":"Blogs","summary":"At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.\nInsight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success. ","title":"How to start a DevOps transformation","type":"blogs"},{"content":"A DevOps transformation is not magic. Any company can do it. What makes the difference is who you put on the first team — because that team has to deliver the proof that DevOps actually works in your context.\nStart Small, Then Pick the Team # Before you choose people, choose the right project. Start with something small to medium in size. Decisions have less impact, fewer stakeholders need to be aligned, and the team can move fast enough to build momentum. With a manageable scope on the table, you can be deliberate about who joins the team — instead of grabbing whoever happens to be available.\nGeneralists Before Specialists # The golden rule when staffing a DevOps team is generalists before specialists. A team of T-shaped people who can pick up build, test, deploy, monitor, and respond to incidents will outperform a team of deep specialists who hand work over a wall. DevOps is about closing loops, and loops close faster when the same people can pull the next thread.\nThat does not mean you ban specialists. It means the centre of gravity is generalist, with specialists pulled in for specific problems. If your first team is mostly siloed experts, the silos will follow them into the new way of working.\nInnovators, Early Adopters, and Respected Voices # The team needs three kinds of people. Innovators who genuinely want to try a new approach. Early adopters who will follow them quickly and bring others along. And at least one or two people who carry weight across the company — engineers or leaders that others listen to. The first two give you energy. The third one gives you credibility. Without credibility, every result you produce will be dismissed as a special case.\nFree Them From Everything Else # The new team needs to be freed up from any other work. No part-time DevOps experiments. No \u0026ldquo;they will help on the side.\u0026rdquo; If people are split across multiple commitments, the transformation gets the leftover hours, and leftover hours are not enough.\nWhere you can, put them in the same location. Co-location is not mandatory in 2020-and-beyond, but reducing communication friction matters more in the early phase than almost anywhere else. They are inventing a way of working — they need to be able to turn around and ask each other questions.\nExempt Them From the Old Rules # Be willing to exempt the team from corporate rules and guidelines wherever possible. Change requests, ticket-driven handoffs, mandatory architecture review boards — these processes were built for the old way. If you force the new team to live inside them, you are testing whether the old process can survive DevOps, which is the wrong experiment. The right experiment is whether the team can deliver value faster and safer with a new way of working. You will reintroduce governance later, redesigned around what the team learns.\nCritical Mass # Once the first team has delivered the requested improvements on the first product, pick the next product and start again. As more teams transform, you reach critical mass. Alliances form, success stories spread, and further transformations get easier — because now you have proof, not promises.\nKey Takeaways # Pick the project, then pick the team. Small to medium scope keeps the experiment honest and the feedback loop tight. Generalists before specialists. Closing loops needs people who can pick up the next part of the work, not pass it on. Mix innovators, early adopters, and respected voices. Energy plus credibility is what makes results stick. Free the team from everything else. Part-time DevOps does not work. Full focus or no focus. Exempt them from old rules. Test the new way of working, not whether the old process can survive it. Repeat until critical mass. Each transformed product makes the next one easier. ","date":"30 July 2020","externalUrl":null,"permalink":"/en/blogs/how-to-build-a-winning-devops-team/","section":"Blogs","summary":"A DevOps transformation is not magic. Any company can do it. What makes the difference is who you put on the first team — because that team has to deliver the proof that DevOps actually works in your context.\n","title":"How to Build a Winning DevOps Team","type":"blogs"},{"content":"","date":"30 July 2020","externalUrl":null,"permalink":"/en/tags/team/","section":"Tags","summary":"","title":"Team","type":"tags"},{"content":"Eine DevOps-Transformation ist keine Magie. Jede Firma kann sie schaffen. Den Unterschied macht, wen du in das erste Team setzt — denn dieses Team muss den Beweis liefern, dass DevOps in deinem Kontext tatsächlich funktioniert.\nKlein anfangen, dann das Team auswählen # Bevor du Leute auswählst, wähle das richtige Projekt. Starte mit etwas Kleinem bis Mittelgrossem. Entscheidungen haben weniger Tragweite, weniger Stakeholder müssen abgestimmt werden, und das Team kann schnell genug liefern, um Momentum aufzubauen. Mit einem überschaubaren Scope auf dem Tisch kannst du gezielt entscheiden, wer dazustösst — statt einfach diejenigen zu nehmen, die gerade verfügbar sind.\nGeneralisten vor Spezialisten # Die goldene Regel beim Staffing eines DevOps-Teams: Generalisten vor Spezialisten. Ein Team aus T-shaped Leuten, die Build, Test, Deploy, Monitoring und Incident Response übernehmen können, schlägt ein Team aus tiefen Spezialisten, die ihre Arbeit über die Wand werfen. DevOps geht es darum, Loops zu schliessen — und Loops schliessen sich schneller, wenn dieselben Leute den nächsten Faden aufnehmen können.\nDas heisst nicht, dass du Spezialisten verbannst. Es heisst, der Schwerpunkt liegt bei Generalisten, und Spezialisten werden für konkrete Probleme dazugeholt. Besteht dein erstes Team mehrheitlich aus Silo-Experten, ziehen die Silos mit ins neue Arbeitsmodell ein.\nInnovatoren, Early Adopters und respektierte Stimmen # Das Team braucht drei Sorten von Menschen. Innovatoren, die wirklich einen neuen Ansatz ausprobieren wollen. Early Adopters, die schnell folgen und andere mitnehmen. Und mindestens eine oder zwei Personen, die im Unternehmen Gewicht haben — Engineers oder Leader, auf die andere hören. Die ersten beiden geben dir Energie. Die dritte gibt dir Glaubwürdigkeit. Ohne Glaubwürdigkeit wird jedes Resultat als Spezialfall abgetan.\nVollständig freistellen # Das neue Team muss von jeder anderen Arbeit freigestellt werden. Keine Teilzeit-DevOps-Experimente. Kein \u0026ldquo;die helfen nebenbei mit\u0026rdquo;. Sind die Leute auf mehrere Verpflichtungen verteilt, bekommt die Transformation die Reststunden — und Reststunden reichen nicht.\nWo möglich, bring sie an einen Ort. Co-Location ist im Jahr 2020 und danach nicht zwingend, aber Kommunikationsreibung zu reduzieren ist in der Anfangsphase wichtiger als fast irgendwo sonst. Die Leute erfinden eine neue Arbeitsweise — sie müssen sich umdrehen und einander Fragen stellen können.\nVon alten Regeln befreien # Sei bereit, das Team von Konzernregeln und Guidelines zu befreien, wo immer möglich. Change Requests, ticketgetriebene Handoffs, verpflichtende Architecture Review Boards — diese Prozesse wurden für das alte Arbeitsmodell gebaut. Wenn du das neue Team in sie hineinzwingst, testest du, ob der alte Prozess DevOps überleben kann. Das ist das falsche Experiment. Das richtige Experiment ist, ob das Team mit einer neuen Arbeitsweise schneller und sicherer Wert liefern kann. Governance führst du später wieder ein — neu gebaut um das, was das Team gelernt hat.\nKritische Masse # Sobald das erste Team die gewünschten Verbesserungen am ersten Produkt geliefert hat, nimmst du das nächste Produkt und beginnst von vorn. Mit jedem weiteren Team erreichst du kritische Masse. Allianzen entstehen, Erfolgsgeschichten verbreiten sich, weitere Transformationen werden einfacher — weil du jetzt Beweise statt Versprechen hast.\nKey Takeaways # Erst das Projekt wählen, dann das Team. Kleiner bis mittlerer Scope hält das Experiment ehrlich und die Feedback-Schleife eng. Generalisten vor Spezialisten. Loops schliessen braucht Leute, die den nächsten Teil der Arbeit übernehmen, nicht weiterreichen. Innovatoren, Early Adopters und respektierte Stimmen mischen. Energie plus Glaubwürdigkeit lässt Resultate stehen. Team von allem anderen freistellen. Teilzeit-DevOps funktioniert nicht. Voller Fokus oder kein Fokus. Von alten Regeln befreien. Teste die neue Arbeitsweise, nicht ob der alte Prozess sie überlebt. Wiederholen bis zur kritischen Masse. Jedes transformierte Produkt macht das nächste leichter. ","date":"30. July 2020","externalUrl":null,"permalink":"/de/blogs/wie-baut-man-ein-erfolgreiches-devops-team/","section":"Blogs","summary":"Eine DevOps-Transformation ist keine Magie. Jede Firma kann sie schaffen. Den Unterschied macht, wen du in das erste Team setzt — denn dieses Team muss den Beweis liefern, dass DevOps in deinem Kontext tatsächlich funktioniert.\n","title":"Wie man ein erfolgreiches DevOps-Team aufbaut","type":"blogs"},{"content":"","date":"29. July 2020","externalUrl":null,"permalink":"/de/tags/reinvestition/","section":"Tags","summary":"","title":"Reinvestition","type":"tags"},{"content":"","date":"29 July 2020","externalUrl":null,"permalink":"/en/tags/reinvestment/","section":"Tags","summary":"","title":"Reinvestment","type":"tags"},{"content":"","date":"29 July 2020","externalUrl":null,"permalink":"/en/tags/release-cycles/","section":"Tags","summary":"","title":"Release Cycles","type":"tags"},{"content":"","date":"29. July 2020","externalUrl":null,"permalink":"/de/tags/release-zyklen/","section":"Tags","summary":"","title":"Release-Zyklen","type":"tags"},{"content":"","date":"29 July 2020","externalUrl":null,"permalink":"/en/tags/roi/","section":"Tags","summary":"","title":"ROI","type":"tags"},{"content":"","date":"29 July 2020","externalUrl":null,"permalink":"/en/tags/time-to-market/","section":"Tags","summary":"","title":"Time to Market","type":"tags"},{"content":"Der DevOps-Business-Case scheitert selten daran, dass die Technologie nicht funktioniert. Er scheitert, weil niemand in Geldbegriffen erklären kann, warum schneller wichtig ist. Die Version, die beim CFO ankommt, geht so: Ein Dollar heute ist mehr wert als ein Dollar morgen — und ein Feature, das heute in Produktion ist, verdient Geld, das ein Feature im nächsten Quartals-Release nicht verdient.\nDie Kosten eines langen Release-Zyklus # In vielen grossen Organisationen werden Release-Zyklen immer noch in Monaten gemessen. Ein Quartal ist normal. Zweimal pro Jahr ist nichts Ungewöhnliches. Das heisst: Eine typische Idee wartet mindestens drei Monate im Value Stream, bevor ein einziger Kunde sie sieht — und in diesen drei Monaten zahlt die Firma Gehälter, Infrastruktur, Lizenzen und Overhead, um etwas zu produzieren, das noch nichts verdient hat.\nWenn ROI der Tag ist, an dem die kumulierten Einnahmen aus einem Feature den kumulierten Kosten entsprechen, dann verschiebt jede Woche, die das Feature unreleased bleibt, den ROI weiter in die Zukunft. Der Break-even-Punkt ist keine Eigenschaft des Features. Er ist eine Eigenschaft davon, wie lang der Value Stream ist.\nWas DevOps tatsächlich komprimiert # Ein konsequenter DevOps-Ansatz hat nichts mit Heldentaten oder härter arbeiten zu tun. Es geht darum, den Weg von \u0026ldquo;Idee\u0026rdquo; zu \u0026ldquo;Kunde kann es nutzen\u0026rdquo; kürzer und planbarer zu machen. Kleinere Batches. Automatisierte Builds, Tests und Deployments. Feature Toggles statt Release-Branches. Continuous Integration statt Integrationsphasen. Jede dieser Änderungen zieht ein paar Tage, manchmal ein paar Wochen, aus dem Value Stream heraus.\nDer kumulierte Effekt ist das Entscheidende. Wenn dieselbe Idee, die früher fünf Monate brauchte, um den Kunden zu erreichen, jetzt fünf Wochen braucht, rückt der ROI um vier Monate nach vorn. Nicht weil das Feature wertvoller geworden ist — sondern weil der Kunde früher dafür bezahlt.\nDer Compounding-Effekt der Reinvestition # Hier wird es interessant. Sobald ein Feature seine Kosten eingespielt hat, hat die Firma Cash, das es vorher nicht gab. Mit diesem Cash kann sie zwei Dinge tun.\nSie kann die nächste Idee finanzieren — die nun durch denselben Value Stream fliesst und ihren eigenen ROI erwirtschaftet. Oder sie kann weitere Verbesserungen am Value Stream selbst finanzieren: bessere Tools, bessere Test-Infrastruktur, der nächste Bottleneck weg. Beides ist gut. Reinvestition in den Value Stream ist Compounding: Jede Verbesserung sorgt dafür, dass jedes zukünftige Feature die Kunden schneller erreicht — und jedes zukünftige Feature seinen ROI früher erreicht.\nGenau diesen Teil verkaufen die meisten DevOps-Business-Cases unter Wert. Das erste Feature, das mit einer schnelleren Pipeline geliefert wird, ist ein kleiner Gewinn. Das hundertste Feature, das mit einer kontinuierlich verbesserten Pipeline geliefert wird, ist eine fundamental andere Kostenstruktur, als sie die Konkurrenz hat.\nDie eigentliche Frage # Die Frage ist nicht \u0026ldquo;sollen wir DevOps einführen?\u0026rdquo;. Die Frage ist \u0026ldquo;wie viel Geld lassen wir liegen, indem wir fertige Features in einer Release-Queue parken?\u0026rdquo;. Sobald du die Antwort in Tagen verzögerter Umsätze ausdrückst, ändert sich das Gespräch. Es ist nicht mehr ein Antrag auf Engineering-Tooling. Es ist ein Working-Capital-Problem.\nEin Team, das wöchentlich released, ist nicht einfach agiler als ein Team, das quartalsweise released. Es operiert mit einem dreizehnmal kürzeren Cash-Conversion-Cycle pro ausgeliefertem Feature. Das ist der Business Case. Time-to-Market ist keine Vanity-Metric. Es ist die Rate, mit der du Engineering-Investitionen wieder zu Cash machst.\nKey Takeaways # Schnellere Releases bedeuten früheren ROI. Jede Woche, die ein fertiges Feature in der Release-Queue wartet, ist eine Woche Umsatz, die du nicht einnimmst. Time Value of Money gilt auch für Features. Ein Dollar, der diesen Monat verdient wird, finanziert die nächste Idee; ein Dollar im nächsten Quartal nicht. DevOps komprimiert den Value Stream End-to-End. Kleinere Batches, Automatisierung und Feature Toggles zusammen schneiden Wochen aus der Lead Time heraus. Reinvestierte Gewinne wirken compounding. Steck einen Teil des verdienten Cash in den Value Stream, und jedes zukünftige Feature erreicht die Kunden schneller. Drücke die Kosten in Geld aus, nicht in Tools. \u0026ldquo;Tage verzögerter Umsätze\u0026rdquo; macht aus einem Tooling-Request eine Working-Capital-Entscheidung. ","date":"29. July 2020","externalUrl":null,"permalink":"/de/blogs/warum-wert-schneller-liefern/","section":"Blogs","summary":"Der DevOps-Business-Case scheitert selten daran, dass die Technologie nicht funktioniert. Er scheitert, weil niemand in Geldbegriffen erklären kann, warum schneller wichtig ist. Die Version, die beim CFO ankommt, geht so: Ein Dollar heute ist mehr wert als ein Dollar morgen — und ein Feature, das heute in Produktion ist, verdient Geld, das ein Feature im nächsten Quartals-Release nicht verdient.\n","title":"Warum Wert schneller liefern","type":"blogs"},{"content":"The DevOps business case rarely fails because the technology does not work. It fails because nobody can explain, in money terms, why doing it faster matters. Here is the version that lands with a CFO: a dollar today is worth more than a dollar tomorrow, and a feature in production today earns money that a feature in next quarter\u0026rsquo;s release does not.\nThe Cost of a Long Release Cycle # In a lot of large organisations, release cycles are still measured in months. A quarter is normal. Twice a year is not unusual. That means the typical idea waits at least three months in the value stream before a single customer ever sees it — and during that three months, the company has been paying salaries, infrastructure, license fees and overhead to produce something that has not yet earned anything.\nIf ROI is the day the cumulative revenue from a feature equals the cumulative cost of building it, then every week the feature stays unreleased is a week ROI moves further away. The break-even point is not a property of the feature. It is a property of how long the value stream is.\nWhat DevOps Actually Compresses # A consistent DevOps approach is not about heroics or working harder. It is about making the path from \u0026ldquo;idea\u0026rdquo; to \u0026ldquo;customer can use it\u0026rdquo; shorter and more predictable. Smaller batches. Automated builds, tests, and deployments. Feature toggles instead of release branches. Continuous integration instead of integration phases. Each of these changes pulls a few days, sometimes a few weeks, out of the value stream.\nThe cumulative effect is what matters. When the same idea that used to take five months to reach a customer takes five weeks, ROI moves forward by four months. Not because the feature is more valuable, but because the customer pays for it sooner.\nThe Compounding Effect of Reinvestment # Here is where it gets interesting. Once a feature has earned back its cost, the company has cash that did not exist before. That cash can do one of two things.\nIt can fund the next idea — which now flows through the same value stream and earns its own ROI. Or it can fund further improvements to the value stream itself: better tooling, better test infrastructure, removing the next bottleneck. Both are good. Reinvesting in the value stream compounds: every improvement makes every future feature reach customers faster, and every future feature earns its ROI sooner.\nThis is the part most DevOps business cases under-sell. The first feature delivered with a faster pipeline is a small win. The hundredth feature delivered with a continuously improving pipeline is a fundamentally different cost structure than the competition has.\nThe Real Question # The question is not \u0026ldquo;should we adopt DevOps?\u0026rdquo; The question is \u0026ldquo;how much money are we leaving on the table by holding finished features in a release queue?\u0026rdquo; Once you express the answer in days of delayed revenue, the conversation changes. It is no longer a request for engineering tooling. It is a working capital problem.\nA team that releases weekly is not just more agile than a team that releases quarterly. It is operating with a thirteen-times shorter cash conversion cycle on every feature it ships. That is the business case. Time-to-market is not a vanity metric. It is the rate at which you turn engineering investment back into cash.\nKey Takeaways # Faster releases mean earlier ROI. Every week a finished feature waits in a release queue is a week of revenue you do not collect. Time value of money applies to features. A dollar earned this month funds the next idea; a dollar earned next quarter does not. DevOps compresses the value stream end to end. Smaller batches, automation and feature toggles together cut weeks out of lead time. Reinvested gains compound. Use part of the earned cash to improve the value stream, and every future feature reaches customers faster. Express the cost in money, not tooling. \u0026ldquo;Days of delayed revenue\u0026rdquo; turns a tooling request into a working capital decision. ","date":"29 July 2020","externalUrl":null,"permalink":"/en/blogs/why-to-create-value-faster/","section":"Blogs","summary":"The DevOps business case rarely fails because the technology does not work. It fails because nobody can explain, in money terms, why doing it faster matters. Here is the version that lands with a CFO: a dollar today is worth more than a dollar tomorrow, and a feature in production today earns money that a feature in next quarter’s release does not.\n","title":"Why to Create Value Faster","type":"blogs"},{"content":"","date":"27 July 2020","externalUrl":null,"permalink":"/en/tags/cost-savings/","section":"Tags","summary":"","title":"Cost Savings","type":"tags"},{"content":"","date":"27 July 2020","externalUrl":null,"permalink":"/en/tags/economics/","section":"Tags","summary":"","title":"Economics","type":"tags"},{"content":"","date":"27. July 2020","externalUrl":null,"permalink":"/de/tags/investition/","section":"Tags","summary":"","title":"Investition","type":"tags"},{"content":"","date":"27. July 2020","externalUrl":null,"permalink":"/de/tags/kosteneinsparungen/","section":"Tags","summary":"","title":"Kosteneinsparungen","type":"tags"},{"content":"Everyone is talking about DevOps. What organisation doesn’t want to develop software more efficiently? So what exactly is the business case for DevOps?\nInsight in brief # Value is only created when the product or feature reaches the customer side. Economic concept: “A dollar today is worth more than a dollar tomorrow.” Focus on rapid Value creation so that You can offer customers Value as quickly as possible. A business case examines the profitability of a venture. It weighs the benefits and opportunities against the costs and risks, and analyses when Return on Investment (ROI) will be achieved.\nWhere is value created? # A development process starts with an idea, which is defined as a user story and then developed, deployed and released. This process chain is known as the value stream. It is important to understand that no value is being created during the whole process. Value is only created when the product or feature reaches the customer side.\nHow do you invest in DevOps? # Customers only pay for that value once the product or feature is effectively available. The company can then invest this earned money in new ideas, which then flow through the value stream of definition, development, deployment and release. Investment in DevOps works when some of the money is used for improving the value stream, rather than investing in more new ideas.\nTime value of money (TVM) # To understand the DevOps business case, it is crucial to understand the economic concept of the time value of money. A dollar today is worth more than a dollar tomorrow. This means that money available at the present moment is worth more than an identical sum of money in the future, due to its potential earning capacity.\nROI without DevOps # These days, the release cycles of large companies are three months or longer. This means that development takes at least a quarter, and customers receive new products or features approximately every twelve weeks. No value is created during the three-month development period. So, in this example, it takes at least five months to achieve ROI.\nROI with DevOps # A consistent DevOps approach allows for shorter release cycles, meaning that new products or features can be made available to customers more quickly. This reduces development time and means that ROI is achieved sooner. With that, businesses can invest the money back into new ideas, or into further improvements of the value stream.\nThe DevOps business case # The first step in a DevOps transformation aims to improve the value stream so that products and features can be delivered more quickly through shorter releases.\nIt is crucial for modern businesses to focus on rapid value creation so that they can offer customers value as quickly as possible. That is the business case for DevOps.\nOriginal Post: Zühlke | Medium\n","date":"27 July 2020","externalUrl":null,"permalink":"/en/blogs/what-is-the-business-case-for-devops/","section":"Blogs","summary":"Everyone is talking about DevOps. What organisation doesn’t want to develop software more efficiently? So what exactly is the business case for DevOps?\nInsight in brief # Value is only created when the product or feature reaches the customer side. Economic concept: “A dollar today is worth more than a dollar tomorrow.” Focus on rapid Value creation so that You can offer customers Value as quickly as possible. ","title":"What is the business case for DevOps?","type":"blogs"},{"content":"","date":"27. July 2020","externalUrl":null,"permalink":"/de/tags/wirtschaftlichkeit/","section":"Tags","summary":"","title":"Wirtschaftlichkeit","type":"tags"},{"content":"If you ask a development team where value is created, you will hear a dozen different answers. In the planning workshop. In the sprint. At the demo. At deployment. They are all wrong — and getting this wrong is what makes most DevOps business cases fall apart on contact with the CFO.\nThe Value Stream, Step by Step # Every piece of software starts as an idea. The idea gets refined into a user story. The user story gets developed. The code gets built and tested. The artifact gets deployed to an environment. And eventually, the feature gets released to a customer. That whole chain — from idea to customer — is the value stream.\nThe reason it is called a stream and not a process is important. A stream is something things flow through. The interesting question is not \u0026ldquo;how busy is each stage?\u0026rdquo; but \u0026ldquo;how fast does an idea get from the source to the sea?\u0026rdquo; Lead time, not utilisation, is the measure that matters.\nWhere No Value Is Created # Here is the part most teams miss. From the moment an idea enters the value stream until the moment it reaches a customer, no value is created. None. Not when the story is groomed, not when it is coded, not when it is deployed to staging, not when it sits in a release queue. All of that work is necessary, but it is cost — not value.\nValue only appears at one point: when the customer can actually use the feature. Until then, you have invested money. Until then, the idea is inventory sitting in a warehouse, depreciating while it waits.\nWhy This Reframing Matters # Once you accept that value is only created at the customer side, two things change about how you run engineering.\nFirst, anything that shortens the time between \u0026ldquo;idea\u0026rdquo; and \u0026ldquo;customer can use it\u0026rdquo; is value-creating work, even if it does not feel like it. Improving the build pipeline, removing a manual approval gate, killing a flaky test — none of those add features, but all of them shorten lead time. They are direct investments in value.\nSecond, anything that lengthens that gap is destroying value, even if it looks like progress. A three-month release train. A staging environment that takes a week to provision. A change advisory board that meets on Wednesdays. They all keep ideas trapped in the value stream where they generate cost without generating value.\nThe Test # Here is a simple test for any DevOps initiative: does it move ideas through the value stream faster, or does it just make one stage of the stream more comfortable for the people working in it? Local optimisations that do not shorten end-to-end lead time are a trap. They feel like improvements. They show up in team metrics. They do not move the business case.\nThis is why DevOps is not a tools conversation. The tools matter, but only as a means to compress the time between idea and customer. If a new tool makes the build faster but the change still waits two weeks for a release window, you have not improved the value stream. You have improved a piece of it that was not the bottleneck.\nKey Takeaways # Value is created at the customer side, not in development. Everything before release is investment, not value. The value stream goes from idea to released feature. Lead time across the whole chain is what matters, not productivity in any single stage. Work that shortens lead time is value-creating. Pipeline improvements and removing manual gates count, even if they ship no new features. Local optimisations are a trap. Speeding up a stage that is not the bottleneck does not move the business case. DevOps is a value stream conversation, not a tools conversation. Tools matter only insofar as they compress idea-to-customer time. ","date":"27 July 2020","externalUrl":null,"permalink":"/en/blogs/where-value-is-created-in-software-development/","section":"Blogs","summary":"If you ask a development team where value is created, you will hear a dozen different answers. In the planning workshop. In the sprint. At the demo. At deployment. They are all wrong — and getting this wrong is what makes most DevOps business cases fall apart on contact with the CFO.\n","title":"Where Value Is Created in Software Development","type":"blogs"},{"content":"Wenn du ein Entwicklungsteam fragst, wo Wert entsteht, bekommst du ein Dutzend unterschiedliche Antworten. Im Planning-Workshop. Im Sprint. Beim Demo. Beim Deployment. Sie liegen alle falsch — und genau dieser Denkfehler ist der Grund, warum die meisten DevOps-Business-Cases beim CFO auseinanderfallen.\nDer Value Stream, Schritt für Schritt # Jede Software beginnt als Idee. Die Idee wird zu einer User Story verfeinert. Die User Story wird entwickelt. Der Code wird gebaut und getestet. Das Artefakt wird in eine Umgebung deployed. Und irgendwann wird das Feature für einen Kunden released. Diese gesamte Kette — von der Idee bis zum Kunden — ist der Value Stream.\nDass es Stream heisst und nicht Prozess, ist kein Zufall. Ein Stream ist etwas, durch das Dinge fliessen. Die spannende Frage ist nicht \u0026ldquo;wie ausgelastet ist jede Stufe?\u0026rdquo;, sondern \u0026ldquo;wie schnell kommt eine Idee von der Quelle ins Meer?\u0026rdquo;. Lead Time — nicht Auslastung — ist die Kennzahl, die zählt.\nWo kein Wert entsteht # Hier kommt der Teil, den die meisten Teams übersehen. Vom Moment, in dem eine Idee in den Value Stream eintritt, bis zu dem Moment, in dem sie den Kunden erreicht, entsteht kein Wert. Null. Nicht beim Grooming, nicht beim Coden, nicht beim Deployment auf Staging, nicht im Release-Queue. Diese Arbeit ist notwendig — aber sie ist Kosten, nicht Wert.\nWert entsteht an genau einem Punkt: wenn der Kunde das Feature tatsächlich nutzen kann. Bis dahin hast du Geld investiert. Bis dahin ist die Idee Inventar im Lager, das beim Warten an Wert verliert.\nWarum dieses Umdenken etwas verändert # Sobald du akzeptierst, dass Wert nur auf der Kundenseite entsteht, ändern sich zwei Dinge in der Art, wie du Engineering führst.\nErstens: Alles, was die Zeit zwischen \u0026ldquo;Idee\u0026rdquo; und \u0026ldquo;Kunde kann es nutzen\u0026rdquo; verkürzt, ist wertschöpfende Arbeit — auch wenn es sich nicht so anfühlt. Die Build-Pipeline verbessern, ein manuelles Approval-Gate entfernen, einen flaky Test rauswerfen — keines davon liefert Features, aber alle verkürzen die Lead Time. Es sind direkte Investitionen in Wert.\nZweitens: Alles, was diese Lücke vergrössert, vernichtet Wert — auch wenn es nach Fortschritt aussieht. Ein Drei-Monats-Release-Train. Eine Staging-Umgebung, die eine Woche zum Provisionieren braucht. Ein Change Advisory Board, das mittwochs tagt. Sie alle halten Ideen im Value Stream fest, wo sie Kosten erzeugen, ohne Wert zu erzeugen.\nDer Test # Hier ist ein einfacher Test für jede DevOps-Initiative: Bewegt sie Ideen schneller durch den Value Stream — oder macht sie einfach eine Stufe des Streams für die dort arbeitenden Menschen bequemer? Lokale Optimierungen, die die End-to-End-Lead-Time nicht verkürzen, sind eine Falle. Sie fühlen sich wie Verbesserungen an. Sie tauchen in Team-Metriken auf. Sie bewegen den Business Case nicht.\nGenau deshalb ist DevOps keine Tool-Diskussion. Tools sind wichtig, aber nur als Mittel, um die Zeit zwischen Idee und Kunde zu komprimieren. Wenn ein neues Tool den Build schneller macht, die Änderung aber zwei Wochen auf ein Release-Fenster wartet, hast du den Value Stream nicht verbessert. Du hast einen Teil davon verbessert, der nicht der Bottleneck war.\nKey Takeaways # Wert entsteht beim Kunden, nicht in der Entwicklung. Alles vor dem Release ist Investition, nicht Wert. Der Value Stream geht von der Idee bis zum released Feature. Es zählt die Lead Time über die gesamte Kette, nicht die Produktivität einer einzelnen Stufe. Arbeit, die Lead Time verkürzt, ist wertschöpfend. Pipeline-Verbesserungen und das Entfernen manueller Gates zählen — auch wenn sie kein neues Feature liefern. Lokale Optimierungen sind eine Falle. Eine Stufe zu beschleunigen, die nicht der Bottleneck ist, bewegt den Business Case nicht. DevOps ist eine Value-Stream-Diskussion, keine Tool-Diskussion. Tools zählen nur insoweit, als sie die Zeit von der Idee bis zum Kunden komprimieren. ","date":"27. July 2020","externalUrl":null,"permalink":"/de/blogs/wo-wert-in-der-softwareentwicklung-entsteht/","section":"Blogs","summary":"Wenn du ein Entwicklungsteam fragst, wo Wert entsteht, bekommst du ein Dutzend unterschiedliche Antworten. Im Planning-Workshop. Im Sprint. Beim Demo. Beim Deployment. Sie liegen alle falsch — und genau dieser Denkfehler ist der Grund, warum die meisten DevOps-Business-Cases beim CFO auseinanderfallen.\n","title":"Wo in der Softwareentwicklung Wert entsteht","type":"blogs"},{"content":"","date":"26 July 2020","externalUrl":null,"permalink":"/en/tags/customer-satisfaction/","section":"Tags","summary":"","title":"Customer Satisfaction","type":"tags"},{"content":"","date":"26. July 2020","externalUrl":null,"permalink":"/de/tags/kundenzufriedenheit/","section":"Tags","summary":"","title":"Kundenzufriedenheit","type":"tags"},{"content":"Companies today are confronted with the challenge of enhancing efficiency while lowering costs. Changes to products often take much too long to reach end customers on the market. A consistent DevOps approach can aid this process.\nInsight in brief # Teamwork is the foundation of DevOps Companies can increase feedback cycles and throughput speed with DevOps You will notice a cultural transformation and a change in mindset when doing DevOps Certain companies succeed in always reacting promptly to changes. A study shows that high-performing IT organisations are able to achieve the following figures compared to the competition thanks to DevOps:\n208 times more frequent deployment 106 times faster lead time from commit to deploy 2'604 times faster time to recovery from incidents 7 times lower change failure rate What is DevOps? # But what\u0026rsquo;s hidden behind this methodical recipe for success? DevOps is the term used to describe the group of concepts that improve the development (Dev) and operation (Ops) of software. This involves the two areas working together on the entire life cycle of the software, from the idea to operation.\nAs part of this, both cultural transformation and a change in mindset are of central significance. It’s no longer about ‘them’, but about ‘us’. Teamwork is the foundation of DevOps. Mutual trust, empowerment, responsibility and continuous improvement, data-based decision-making and customer empathy are the DevOps values.\nThe goal of DevOps is to support a faster time to market, experimentation, small frequent software release, shorten the lead time for fixes and improve the mean time for recovery.\nIncrease in efficiency and lower change costs # Thanks to DevOps, companies can increase feedback cycles and throughput speed. As a result, they can react more quickly and impress their customers with constant innovation. With DevOps a company can optimise and automate processes, from the idea over development to production. This increases efficiency, which in turn lowers costs.\nSummary # Technology # Process # People # Feedback # Original Post: Medium\n","date":"26 July 2020","externalUrl":null,"permalink":"/en/blogs/satisfied-end-users-thanks-to-devops/","section":"Blogs","summary":"Companies today are confronted with the challenge of enhancing efficiency while lowering costs. Changes to products often take much too long to reach end customers on the market. A consistent DevOps approach can aid this process.\n","title":"Satisfied end users thanks to DevOps","type":"blogs"},{"content":"","date":"26 July 2020","externalUrl":null,"permalink":"/en/tags/user-experience/","section":"Tags","summary":"","title":"User Experience","type":"tags"},{"content":"Die Corona-Krise zeigt, wie Unternehmen mit einem agilen DevOps-Mindset besser auf neue Umstände und Herausforderungen reagieren können als Unternehmen mit starren Strukturen und Prozessen.\nVon Romano Roth und Romeo Weber\nZusammenfassung # Die vier Aspekte Technologie, Prozess, Mensch und Feedback tragen wesentlich dazu bei, dass Unternehmen in Krisen schnell und gezielt reagieren können. Dank DevOps sind Unternehmen in der Lage, ohne grössere Probleme und Reibungsverluste vollständig auf Remote Work umzustellen und schnell auf neue Anforderungen zu reagieren. Wo immer man hinschaut, sind die aktuellen Nachrichten von Angst und Unsicherheit geprägt. Trotzdem schreitet die Digitalisierung weiter voran und wird letztendlich jeden Aspekt unseres Lebens beeinflussen. Unternehmen mit einem agilen Mindset, die DevOps bereits implementiert haben, stehen vor weniger grossen Herausforderungen und können sich besser an die neuen Umstände anpassen als Unternehmen mit starren Strukturen und Prozessen. Warum ist das so? Folgende vier Aspekte tragen wesentlich zur Fähigkeit eines Unternehmens bei, in Krisenzeiten schnell und überlegt zu reagieren.\nTechnologie # DevOps setzt Tools ein, die den kontinuierlichen Delivery- und Deployment-Prozess unterstützen. Anpassungen am Quellcode setzen primär auf einen hohen Automatisierungsgrad, der sich durch das Deployment verschiedener Test- und Produktionsumgebungen manifestiert. Im Rahmen von Continuous Delivery wird angestrebt, jederzeit ein lauffähiges Softwareprodukt bereitzustellen, das bereits einen standardisierten Testprozess durchlaufen hat. Dies ermöglicht Unternehmen, schnell auf Veränderungen zu reagieren. Je nach Aufgabe können verschiedene Tools eingesetzt werden, etwa Jenkins, TeamCity, Octopus Deploy, Azure DevOps und GitLab.\nDarüber hinaus verfügt DevOps über eine hochentwickelte Kollaborationsstruktur, die eine enge Zusammenarbeit zwischen verschiedenen Akteuren in der Softwareentwicklung erleichtert. Im Fokus stehen dabei Tools, die eine standortunabhängige und länderübergreifende Zusammenarbeit ermöglichen, etwa Microsoft Teams, Slack, Skype und WebEx.\nProzess # DevOps wird von kontinuierlichen Verbesserungen und Lernergebnissen geprägt, was eine positive Fehlerkultur fördert. Natürlich wirken sich Fehler nicht immer positiv auf den Geschäftserfolg aus. Das Fehlen einer solchen Kultur wirft jedoch die Frage auf, ob ein Unternehmen bereits Fehler macht, ohne es zu merken. Scheitern bedeutet, etwas Neues auszuprobieren, Grenzen auszuloten und den Status quo zu hinterfragen. Nur so können Unternehmen experimentieren und schnell reagieren, was auch wesentlich zum langfristigen Unternehmenserfolg beiträgt.\nMensch # Die Fähigkeit, eine Kultur der kontinuierlichen Verbesserung und des Lernens einzuführen, erfordert eine vertrauensbasierte Grundlage, die eine offene Feedback-Kultur unterstützt, Fehler zulässt und die Stärken jedes Mitarbeitenden fördert, anstatt auf Schwächen hinzuweisen. Es ist entscheidend, dass eine offene Fehlerkultur auf jeder Ebene und in allen Strukturen der Organisation gelebt wird und nicht nur im Leitbild auf der Unternehmenswebsite existiert. Eine solche Entwicklung lässt sich nicht über Nacht etablieren. Vielmehr erfordert sie einen umfassenden Kulturwandel, der alle Bereiche des Unternehmens einbezieht.\nFeedback # DevOps zielt darauf ab, den Erfolg, oder Misserfolg, agiler Softwareprojekte messbar und damit auch sichtbar zu machen. Dazu sollten Standardmetriken verwendet werden, die für alle Beteiligten anwendbar und akzeptiert sind. Dieses Feedback ist essenziell für kontinuierliche Verbesserung und Lernen und damit auch für die Gesamtumsetzung von DevOps.\nFazit # Die Erfahrung zeigt, dass Unternehmen dank DevOps ohne grössere Schwierigkeiten ins Homeoffice wechseln und schnell auf neue Anforderungen reagieren können. Etablierte DevOps-Prozesse und das richtige Tooling können wesentlich dazu beitragen, dass ein Unternehmen einer Krise standhalten kann.\nZuehlke Medium ","date":"26. July 2020","externalUrl":null,"permalink":"/de/blogs/besser-durch-die-krise-dank-devops/","section":"Blogs","summary":"Die Corona-Krise zeigt, wie Unternehmen mit einem agilen DevOps-Mindset besser auf neue Umstände und Herausforderungen reagieren können als Unternehmen mit starren Strukturen und Prozessen.\nVon Romano Roth und Romeo Weber\n","title":"Besser durch die Krise dank DevOps","type":"blogs"},{"content":"The coronavirus crisis is demonstrating how companies with an agile DevOps mindset can better respond to new circumstances and challenges than companies with rigid structures and processes.\nBy Romano Roth and Romeo Weber\nSummary # The four aspects of technology, process, people and feedback make a significant contribution to enabling companies to react quickly and in a targeted manner in crises. Thanks to DevOps, companies are able to switch completely to remote working without major problems and frictional losses and can react quickly to new requirements. Everywhere you turn, the current news is permeated by fear and insecurity. Nevertheless, digitalisation continues to make inroads and will eventually impact every aspect of our lives. Companies with an agile mindset that have already implemented DevOps face fewer major challenges and can better adapt to the new circumstances than companies with rigid structures and processes. Why is that the case? The following four aspects significantly contribute to a company’s ability to respond quickly and deliberately in times of crisis.\nTechnology # DevOps employs tools that support the continuous delivery and deployment process. Adaptations made to the source code primarily focus on a high degree of automation, which manifests through the deployment of various test and production environments. As part of continuous delivery, the aim is to always provide an executable software product that has already undergone a standardised test process. This enables companies to respond quickly to changes. Various tools can be employed depending on the task, such as Jenkins, TeamCity, Octopus Deploy, Azure DevOps and GitLab.\nFurthermore, DevOps has a highly developed collaborative structure that facilitates close collaboration between different players in software development. Here, the focus is on tools that allow collaboration irrespective of location and across national borders, such as Microsoft Teams, Slack, Skype and WebEx.\nProcess # DevOps is influenced by continuous improvements and learning outcomes, which promotes a positive culture around mistakes. Of course, mistakes don’t always have a positive effect on business success. However, the absence of such a culture begs the question of whether a company is already making mistakes without realising it. Failing means trying out something new, exploring boundaries and questioning the status quo. This is the only way to enable companies to experiment and respond quickly and it also greatly contributes to ensuring long-term success for the company.\nPeople # The ability to introduce a culture of continuous improvement and learning requires a foundation based on trust that supports a culture of open feedback, allows mistakes and promotes the strengths of each employee rather than pointing out weaknesses. It is essential that a culture of openness around mistakes is demonstrated at every level and in all structures of the organisation and doesn’t just exist in the mission statement on the company website. This kind of process cannot be established overnight. Rather, it requires a comprehensive cultural shift involving all areas of the company.\nFeedback # DevOps aims to make the success, or failure, of agile software projects measurable and thus also visible. To do this, standard metrics should be used that can be applied to and accepted by all involved parties. This feedback is essential for continuous improvement and learning and thus also for the overall implementation of DevOps.\nConclusion # Experience shows that, thanks to DevOps, companies can switch to working from home and respond quickly to new requirements without major difficulties. Established DevOps processes and the right tooling can significantly contribute to a company’s ability to withstand a crisis.\nZuehlke Medium ","date":"26 July 2020","externalUrl":null,"permalink":"/en/blogs/better-through-the-crisis-thanks-to-devops/","section":"Blogs","summary":"The coronavirus crisis is demonstrating how companies with an agile DevOps mindset can better respond to new circumstances and challenges than companies with rigid structures and processes.\nBy Romano Roth and Romeo Weber\n","title":"Better through the crisis thanks to DevOps","type":"blogs"},{"content":"","date":"26 July 2020","externalUrl":null,"permalink":"/en/tags/business-resilience/","section":"Tags","summary":"","title":"Business Resilience","type":"tags"},{"content":"","date":"26 July 2020","externalUrl":null,"permalink":"/en/tags/crisis-management/","section":"Tags","summary":"","title":"Crisis Management","type":"tags"},{"content":"Unternehmen stehen heute von zwei Seiten unter Druck: mehr liefern, schneller liefern und das zu geringeren Kosten. Gleichzeitig brauchen Änderungen am Produkt oft Monate, bis sie beim Kunden ankommen. DevOps schliesst genau diese Lücke — und deshalb ist es wichtig.\nDer reale Druck auf Unternehmen # Jedes Unternehmen, mit dem ich arbeite, steht unter demselben Druck. Märkte bewegen sich schneller als früher. Wettbewerber liefern. Kunden erwarten Updates so, wie sie Updates von einer Smartphone-App erwarten — klein, häufig, reibungslos. Trotzdem laufen die meisten IT-Organisationen noch in einem Liefertakt von Monaten oder Quartalen. Das Business fordert mehr, aber das System, das liefern soll, wurde nicht für dieses Tempo gebaut. DevOps ist in diesem Kontext kein Buzzword. Es ist die Antwort auf diesen Druck.\nWarum lange Lead Times echte Kosten sind # Wenn eine Änderung sechs Monate braucht, bis sie in Produktion ist, passieren drei Dinge. Erstens: Die ursprüngliche Anforderung ist schon veraltet, wenn sie ankommt. Zweitens: Das Feedback, das das Team gebraucht hätte, um zu lernen, kommt zu spät, um darauf zu reagieren. Drittens: Jedes Problem, das in Produktion auftaucht, hat sechs Monate Arbeit hinter sich — die Kosten für die Behebung sind entsprechend hoch. Lange Lead Times sind nicht nur langsam, sondern teuer auf eine Art, die auf keiner einzelnen Rechnung auftaucht.\nWas die High Performer wirklich anders machen # Die DORA-Forschung ist seit Jahren eindeutig: High-Performing IT-Organisationen deployen 208-mal häufiger, erholen sich 2'604-mal schneller von Incidents und haben eine 7-mal tiefere Change-Failure-Rate. Das liegt nicht daran, dass sie bessere Entwickler haben. Es liegt daran, dass sie kürzere Feedback-Loops haben, ihre Pipelines automatisiert haben und Entwicklung und Betrieb auf dieselben Ziele ausgerichtet haben. Der Unterschied ist das System, nicht die Menschen.\nDevOps dreht sich um den Endnutzer # Es ist leicht, in die Falle zu tappen, DevOps als IT-Thema zu behandeln — Pipelines, Tooling, Monitoring. Aber der Grund, warum DevOps wichtig ist, ist der Endnutzer. Schnelleres Feedback bedeutet, dass du auf das reagieren kannst, was Nutzer wirklich brauchen. Kleinere Releases bedeuten weniger Risiko pro Änderung. Kürzere Recovery-Zeiten bedeuten weniger Downtime, wenn etwas schiefläuft. Der ganze Sinn ist, den Nutzer glücklich zu machen — nicht ein internes Effizienz-Award zu gewinnen.\nWarum es schwierig ist # Wäre DevOps einfach, würden es alle schon machen. Die schwierigen Teile sind die kulturellen. Dev und Ops wurden historisch an gegensätzlichen Zielen gemessen: Dev will Veränderung, Ops will Stabilität. DevOps verlangt, dass sie ein gemeinsames Ziel haben — Wert für den Kunden liefern — und gemeinsam Verantwortung dafür übernehmen. Das braucht Vertrauen, Transparenz und Führung, die das Team beim Lernen schützt. Tooling ist der einfache Teil.\nKey Takeaways # Geschwindigkeit ist nicht mehr optional. Märkte und Kunden erwarten schnelle Iteration. Wer in Monaten liefert, ist bereits abgehängt.\nLange Lead Times verstecken hohe Kosten. Spätes Feedback, veraltete Anforderungen und teure Bugfixes haben alle dieselbe Wurzel: der Zyklus ist zu lang.\nDie DORA-Zahlen sind der Beweis. 208x Deployment-Frequenz, 2'604x schnellere Recovery, 7x tiefere Failure-Rate — High Performer sind nicht ein bisschen besser, sondern eine Klasse besser.\nDevOps existiert für den Endnutzer. Pipelines und Tools sind Mittel, nicht der Zweck. Es geht um zufriedenere Kunden und schnellere Antwort auf das, was sie wirklich brauchen.\nKultur ist der schwierige Teil. Tools kannst du kaufen. Gemeinsame Ziele zwischen Dev und Ops musst du aufbauen — und genau das macht DevOps wichtig und schwierig zugleich.\n","date":"26. July 2020","externalUrl":null,"permalink":"/de/blogs/warum-ist-devops-wichtig/","section":"Blogs","summary":"Unternehmen stehen heute von zwei Seiten unter Druck: mehr liefern, schneller liefern und das zu geringeren Kosten. Gleichzeitig brauchen Änderungen am Produkt oft Monate, bis sie beim Kunden ankommen. DevOps schliesst genau diese Lücke — und deshalb ist es wichtig.\n","title":"Warum ist DevOps wichtig?","type":"blogs"},{"content":"DevOps ist eines der am stärksten überladenen Wörter in unserer Branche. Leute meinen damit ein Tool, ein Team, einen Jobtitel oder gar ein Hersteller-Produkt. Nichts davon trifft es. DevOps ist die Summe der kulturellen und technischen Praktiken, die Entwicklung (Dev) und Betrieb (Ops) von Software verbessern — gemeinsam, über den gesamten Lebenszyklus.\nVom \u0026ldquo;die\u0026rdquo; zum \u0026ldquo;wir\u0026rdquo; # Die grösste Veränderung in DevOps ist kulturell. Über Jahrzehnte wurden Dev und Ops an gegensätzlichen Zielen gemessen. Entwickler wurden für Veränderung belohnt, Operations für Stabilität. Das Ergebnis war eine Mauer zwischen den beiden — und ein permanentes Hin- und Herschieben der Schuld. DevOps reisst diese Mauer ein. Es ist nicht mehr \u0026ldquo;die\u0026rdquo; gegen \u0026ldquo;uns\u0026rdquo;. Es ist ein Team mit einem gemeinsamen Ziel: Wert für den Kunden liefern und das System am Laufen halten.\nDer gesamte Lebenszyklus, kein Übergabe-Spiel # DevOps deckt den gesamten Lebenszyklus der Software ab, von der ersten Idee bis zum Betrieb in Produktion. Das ist bewusst weit gefasst. Der Punkt ist: Keine einzelne Phase lässt sich isoliert optimieren — du kannst nicht clevere Architektur machen und Deployment ignorieren, du kannst nicht schnell deployen und Monitoring ignorieren, du kannst nicht gut betreiben, wenn der Code über die Mauer geworfen wurde. Der ganze Loop muss zusammen funktionieren.\nDie DevOps-Werte # Wenn ich Leadership-Teams DevOps erkläre, komme ich immer wieder auf dieselben Werte zurück:\nGegenseitiges Vertrauen — zwischen Dev und Ops, zwischen Teams und Management Empowerment — das Team, das am nächsten an der Arbeit ist, entscheidet Verantwortung — you build it, you run it Continuous Improvement — jeder Loop ist eine Lernchance Datenbasierte Entscheidungen — messen, nicht raten Kundenempathie — jede Änderung dient dem Nutzer Keiner dieser Werte ist technisch. Genau das ist der Punkt. Die Technologie dient den Werten, nicht umgekehrt.\nWas DevOps erreichen will # Die Ziele sind konkret und messbar:\nSchnellere Time to Market — Wert früher zum Kunden bringen Experimentieren — billig machen, Dinge auszuprobieren und zu lernen Kleine, häufige Releases — Risiko pro Änderung reduzieren Kürzere Lead Time für Fixes — wenn etwas falsch ist, schnell beheben Bessere Mean Time to Recovery — Incidents passieren; entscheidend ist die Erholung Diese Ergebnisse kommen nur, wenn Kultur, Prozess und Tooling zusammenpassen.\nWas DevOps nicht ist # Es lohnt sich, genauso klar zu sein, was DevOps nicht ist. Es ist kein Jobtitel — \u0026ldquo;DevOps Engineer\u0026rdquo; bedeutet meist \u0026ldquo;der, der die Pipeline pflegt\u0026rdquo;, was eine Verkürzung des Begriffs ist. Es ist keine Abteilung — ein \u0026ldquo;DevOps Team\u0026rdquo; zwischen Dev und Ops zu schaffen, baut nur eine dritte Mauer. Es ist kein Tool — Jenkins, GitLab, Azure DevOps sind alle nützlich, aber ein Tool zu kaufen macht dich nicht zu einer DevOps-Organisation. Und es ist kein Projekt mit Enddatum — es ist eine Arbeitsweise, die du laufend weiterentwickelst.\nKey Takeaways # DevOps ist Kultur zuerst, Technik danach. Ohne Vertrauen, gemeinsame Ziele und Empowerment liefert das beste Tooling der Welt nicht die erwarteten Ergebnisse.\nEs deckt den gesamten Lebenszyklus ab. Idee bis Betrieb, alles in einem Loop. Eine Phase isoliert zu optimieren funktioniert nicht.\nDie Werte sind wichtiger als die Praktiken. Kundenempathie, Continuous Improvement, datenbasierte Entscheidungen — wenn die Werte stimmen, folgen die Praktiken.\nDas Ziel ist schnellere, sicherere Wertschöpfung. Schnellere Time to Market, kleinere Releases, kürzere Lead Times, bessere Recovery. Das sind die Dinge, die du messen solltest.\nDevOps ist kein Team und kein Titel. Wer dir sagt, er sei \u0026ldquo;das DevOps-Team\u0026rdquo;, hat die Idee nicht verstanden. Es geht darum, wie die ganze Organisation arbeitet — nicht um einen Slot im Orgchart.\n","date":"26. July 2020","externalUrl":null,"permalink":"/de/blogs/was-ist-devops/","section":"Blogs","summary":"DevOps ist eines der am stärksten überladenen Wörter in unserer Branche. Leute meinen damit ein Tool, ein Team, einen Jobtitel oder gar ein Hersteller-Produkt. Nichts davon trifft es. DevOps ist die Summe der kulturellen und technischen Praktiken, die Entwicklung (Dev) und Betrieb (Ops) von Software verbessern — gemeinsam, über den gesamten Lebenszyklus.\n","title":"Was ist DevOps?","type":"blogs"},{"content":"DevOps is one of the most overloaded words in our industry. People use it to mean a tool, a team, a job description, even a vendor product. None of those are right. DevOps is the set of cultural and technical practices that improve the development (Dev) and operation (Ops) of software — together, across the entire life cycle.\nFrom \u0026ldquo;Them\u0026rdquo; to \u0026ldquo;Us\u0026rdquo; # The single biggest shift in DevOps is cultural. For decades, Dev and Ops were measured against opposing goals. Developers were rewarded for change; operations were rewarded for stability. The result was a wall between the two — and a constant blame game across it. DevOps removes that wall. It is no longer \u0026ldquo;them\u0026rdquo; versus \u0026ldquo;us\u0026rdquo;. It is one team, with one shared goal: deliver value to the customer, and keep it running.\nThe Whole Life Cycle, Not a Hand-off # DevOps covers the entire life cycle of the software, from the initial idea all the way through to operation in production. That is a deliberately wide scope. The point is that no single phase can be optimised in isolation — you cannot do clever architecture and ignore deployment, you cannot deploy fast and ignore monitoring, you cannot operate well if the code was thrown over the wall to you. The whole loop has to work together.\nThe DevOps Values # When I explain DevOps to leadership teams, I keep coming back to the same set of values:\nMutual trust — between Dev and Ops, and between teams and management Empowerment — the team closest to the work makes the decisions Responsibility — you build it, you run it Continuous improvement — every loop is an opportunity to learn Data-based decision-making — measure, do not guess Customer empathy — every change is in service of the user None of these values are technical. That is the point. The technology serves the values, not the other way around.\nWhat DevOps Aims to Achieve # The goals are concrete and measurable:\nFaster time to market — get value to customers sooner Experimentation — make it cheap to try things and learn Small, frequent releases — reduce risk per change Shorter lead time for fixes — when something is wrong, fix it fast Better mean time to recovery — incidents happen; recovery is what matters These outcomes only happen if culture, process and tooling all line up.\nWhat DevOps Is Not # It is worth being equally clear about what DevOps is not. It is not a job title — \u0026ldquo;DevOps Engineer\u0026rdquo; usually means \u0026ldquo;the person who runs the pipeline\u0026rdquo;, which is a misuse of the term. It is not a department — creating a \u0026ldquo;DevOps Team\u0026rdquo; between Dev and Ops just builds a third wall. It is not a tool — Jenkins, GitLab, Azure DevOps are all useful, but buying a tool does not make you a DevOps organisation. And it is not a project with an end date — it is a way of working that you keep refining.\nKey Takeaways # DevOps is culture first, technology second. Without trust, shared goals and empowerment, the best tooling in the world will not deliver the outcomes.\nIt covers the entire life cycle. Idea to operation, all in one loop. Optimising one phase in isolation does not work.\nThe values matter more than the practices. Customer empathy, continuous improvement, data-based decisions — get the values right and the practices follow.\nThe goal is faster, safer value delivery. Faster time to market, smaller releases, shorter lead times, better recovery. These are the things to measure.\nDevOps is not a team or a title. Anyone who tells you they \u0026ldquo;are the DevOps team\u0026rdquo; has misunderstood the idea. It is how the whole organisation works, not a slot on the org chart.\n","date":"26 July 2020","externalUrl":null,"permalink":"/en/blogs/what-is-devops/","section":"Blogs","summary":"DevOps is one of the most overloaded words in our industry. People use it to mean a tool, a team, a job description, even a vendor product. None of those are right. DevOps is the set of cultural and technical practices that improve the development (Dev) and operation (Ops) of software — together, across the entire life cycle.\n","title":"What is DevOps?","type":"blogs"},{"content":"Companies today are squeezed from both sides: deliver more, deliver faster, and do it at lower cost. At the same time, changes to products often take months to reach the customer. DevOps is what closes that gap — and that is why it matters.\nThe Real Pressure on Companies # Every company I work with is under the same pressure. Markets move faster than they used to. Competitors ship. Customers expect updates the way they expect updates from a phone app — small, frequent, low-friction. Yet most IT organisations are still running on a delivery cadence of months or quarters. The business demands more, and the system that has to deliver was not built for that pace. DevOps is not a buzzword in this context. It is the response to that pressure.\nWhy Long Lead Times Are a Real Cost # When a change takes six months to reach production, three things happen. First, the original requirement is already stale by the time it lands. Second, the feedback the team needed in order to learn arrives too late to act on. Third, every issue found in production took six months of work to surface — so the cost of fixing it is huge. Long lead times are not just slow; they are expensive in ways that do not show up on a single invoice.\nWhat High Performers Actually Do Differently # The DORA research has been clear on this for years: high-performing IT organisations deploy 208 times more frequently, recover from incidents 2,604 times faster, and have a 7 times lower change failure rate. That is not because they have better engineers. It is because they have shorter feedback loops, automated their pipelines, and aligned development and operations around the same goals. The capability gap is the system, not the people.\nDevOps Is About the End User # It is easy to fall into the trap of treating DevOps as an IT topic — pipelines, tooling, monitoring. But the reason DevOps matters is the end user. Faster feedback means you can respond to what users actually need. Smaller releases mean less risk per change. Shorter recovery times mean less downtime when something does go wrong. The whole point is to keep the user happy, not to win an internal efficiency award.\nWhy It Is Hard # If DevOps were easy, everyone would already be doing it. The hard parts are the cultural ones. Dev and Ops have historically been measured against opposing goals: Dev wants change, Ops wants stability. DevOps demands that they share a goal — delivering value to the customer — and share the responsibility for getting there. That requires trust, transparency, and leadership that protects the team while it learns. Tooling is the easy part.\nKey Takeaways # Speed is no longer optional. Markets and customers expect fast iteration. If your delivery cadence is measured in months, you are already behind.\nLong lead times hide huge costs. Late feedback, stale requirements and expensive bug fixes all stem from the same root cause: the cycle is too long.\nThe DORA numbers are the proof. 208x deployment frequency, 2,604x faster recovery, 7x lower failure rate — high performers are not slightly better, they are categorically better.\nDevOps exists for the end user. Pipelines and tools are means, not the goal. The point is happier customers and faster response to what they actually need.\nCulture is the hard part. Tools you can buy. Shared goals between Dev and Ops you have to build, and that is what makes DevOps important — and difficult.\n","date":"26 July 2020","externalUrl":null,"permalink":"/en/blogs/why-is-devops-important/","section":"Blogs","summary":"Companies today are squeezed from both sides: deliver more, deliver faster, and do it at lower cost. At the same time, changes to products often take months to reach the customer. DevOps is what closes that gap — and that is why it matters.\n","title":"Why is DevOps important?","type":"blogs"},{"content":"","date":"18 June 2019","externalUrl":null,"permalink":"/en/tags/architecture-decisions/","section":"Tags","summary":"","title":"Architecture Decisions","type":"tags"},{"content":" My chapter from the book: Machines, Code, People: 50 things Zühlke engineers are passionate about\nRead Online GitHub Repository Buy on Amazon Imagine on a Monday morning you come into the office, start up your computer and ba-bam a manager is standing beside you, telling you to follow him into a escalation meeting.\nThere is a problem with the software you are building in production. In the meeting there is the CIO, your line manager, the technology line manager, the operation line manager, the central architect line manager and you.\nThere is a problem with a library you introduced into your software a year ago, which is causing crashes of the software in production and the company is losing money because the users cannot work.\nThe managers want to know why you have chosen to use this library and who gave you the sign off to use this library. There are now two possibilities:\nA) You start like hmmmm, this was a year ago and hmmm, actually I don’t know, but this is not of interest now, let me go and fix the problem…. very bad idea! You\u0026rsquo;re screwed…\nB) You take the laptop and navigate to the list of architecture decisions, you show them the architecture decision with the evaluation and the approval. And now you say: “Can you excuse me? I have a problem to fix.”\nOf course: All characters and events in this article are entirely fictional ;-).\nI know you hate to document things and I know that you think you will remember everything. But just take my advice for your career. Use CYA = Cover your ass. CYA has one simple rule: Document EVERY Decision =\u0026gt; DED\nYes, document every decision. Whether you are a Software Architect, Business Analyst, Consultant, Engineer, Developer, Manager or a fluffy unicorn dancing on a rainbow.\nSo, how do you document a decision? # You create a decision log in a tabular form in a suitable medium (Git, wiki, SharePoint, Word, Excel, …).\nNumber: Every Decision has an id or number. Which can be used as a reference.\nWhat: What is the decision that was taken\nWhy: The reasoning and arguments, constraints, implications and references.\nContext: In this part, we document the context of the decision. We give the reader some extra information, so he/she can understand the context of the decision. Problem: The problem or the challenge giving rise to this decision. Decision: The decision that is made. Document the evaluation you have done that has led to this decision here. Consequences: The consequences of the decision. When: When was the decision taken?\nWho: Who was involved in taking this decision? Hint: The more people who agreed on a decision the better.\nWe will use a decision log in our project\nDecisions need to be documented so that everyone knows why a decision was made.\nNot everyone remembers after more than a year why a decision was made.\nKnowledge drain: People leave the project\nWe introduce a decision log.\nEvery decision is documented in the decision log\nHans Muster Simon Stucki\nWhat happens if a decision is revoked? Strikethrough the decision and define a new decision, where you document why decision No. X was revoked.\nCYA = Cover your ass will make your life easy and everybody in your team will know where to look to see why a decision was taken, so that you can move on to the next project without being haunted by unknown old decisions from the past.\n","date":"18 June 2019","externalUrl":null,"permalink":"/en/blogs/cya-cover-your-ass/","section":"Blogs","summary":" My chapter from the book: Machines, Code, People: 50 things Zühlke engineers are passionate about\nRead Online GitHub Repository Buy on Amazon Imagine on a Monday morning you come into the office, start up your computer and ba-bam a manager is standing beside you, telling you to follow him into a escalation meeting.\n","title":"CYA: Cover your ass","type":"blogs"},{"content":"","date":"18 June 2019","externalUrl":null,"permalink":"/en/tags/decision-log/","section":"Tags","summary":"","title":"Decision Log","type":"tags"},{"content":"","date":"18 June 2019","externalUrl":null,"permalink":"/en/tags/documentation/","section":"Tags","summary":"","title":"Documentation","type":"tags"},{"content":"","date":"18 June 2019","externalUrl":null,"permalink":"/en/tags/knowledge-management/","section":"Tags","summary":"","title":"Knowledge Management","type":"tags"},{"content":"","date":"31 January 2019","externalUrl":null,"permalink":"/en/tags/enterprise/","section":"Tags","summary":"","title":"Enterprise","type":"tags"},{"content":"","date":"31 January 2019","externalUrl":null,"permalink":"/en/tags/experience-report/","section":"Tags","summary":"","title":"Experience Report","type":"tags"},{"content":"Introducing DevOps in a large enterprise is difficult. But wait, why do we want to introduce DevOps in the first place? Good question.\nThe Full Story # In this talk, I answer the question and show you what happens when you introduce DevOps, and what does not happen.\nWhat We Changed # I show you how we:\nChanged the CI pipeline to enable faster, more reliable builds Changed the architecture to support continuous delivery Scaled up delivery from 1 team to 7 teams Automated the deployment for consistent, repeatable releases Automated the testing across all levels Improved operations with better monitoring and incident response Started scanning for security issues as part of the pipeline Analyzed performance issues proactively Monitored the application end-to-end Changed the culture to support collaboration and continuous improvement A real-world experience report, with all the successes and lessons learned along the way.\n","date":"31 January 2019","externalUrl":null,"permalink":"/en/speaking/experience-report-devops-in-large-enterprise/","section":"Speaking","summary":"Introducing DevOps in a large enterprise is difficult. But wait, why do we want to introduce DevOps in the first place? Good question.\nThe Full Story # In this talk, I answer the question and show you what happens when you introduce DevOps, and what does not happen.\n","title":"Experience Report: How to Introduce DevOps in a Large Enterprise?","type":"speaking"},{"content":"Everyone wants to do DevOps. But only a few understand what DevOps is and what it does with your company.\nThe Challenge # When you want to introduce DevOps in a company you need to convince decision-makers that it is worth investing money, time, and resources into the DevOps transformation. They will ask you about the business case and the return on investment of DevOps.\nWhat You Will Learn # In this talk, I show you how to convince the decision-maker about the business case and the return on investment of DevOps, so that you get the money, time, and resources for your DevOps transformation.\nKey Topics # 1. The Business Case How to frame DevOps in business terms that decision-makers understand. Not technology jargon, but value, risk, and competitive advantage.\n2. Return on Investment Concrete methods to calculate and demonstrate the ROI of DevOps investments. With real numbers from real transformations.\n3. The Cost of Inaction A mathematical model to calculate the cost of unused features or poorly developed features, making the case for why doing nothing is the most expensive option.\n","date":"31 January 2019","externalUrl":null,"permalink":"/en/speaking/what-is-the-business-case-for-devops/","section":"Speaking","summary":"Everyone wants to do DevOps. But only a few understand what DevOps is and what it does with your company.\nThe Challenge # When you want to introduce DevOps in a company you need to convince decision-makers that it is worth investing money, time, and resources into the DevOps transformation. They will ask you about the business case and the return on investment of DevOps.\n","title":"What is the Business Case for DevOps?","type":"speaking"},{"content":"Game of Thrones is more than epic fantasy. The series shows in exaggerated form how violence, power, revenge, and ideologies drive conflict.\nWhat This Talk Covers # In this talk, Romano Roth uses the world of Westeros as a mirror for real human dynamics: from the \u0026ldquo;five demons\u0026rdquo; of violence to the \u0026ldquo;four angels\u0026rdquo; like empathy, self-control, morality, and reason. Building on this, central conflict types, escalation levels, and de-escalation strategies are presented, complemented by personal survival strategies like meditation and regeneration.\nKey Messages # 1. Understanding the Drivers of Conflict The \u0026ldquo;five demons\u0026rdquo; of violence and how they manifest in everyday life. Recognizing these patterns is the first step to managing conflict effectively.\n2. De-Escalation Strategies Central conflict types, escalation levels, and practical strategies for de-escalation. The \u0026ldquo;four angels\u0026rdquo;, empathy, self-control, morality, and reason, provide the counterbalance.\n3. Personal Resilience Personal survival strategies like meditation and regeneration help us deal with conflict more consciously, wisely, and humanely.\n","date":"5 September 2018","externalUrl":null,"permalink":"/en/speaking/how-to-survive-game-of-thrones/","section":"Speaking","summary":"Game of Thrones is more than epic fantasy. The series shows in exaggerated form how violence, power, revenge, and ideologies drive conflict.\nWhat This Talk Covers # In this talk, Romano Roth uses the world of Westeros as a mirror for real human dynamics: from the “five demons” of violence to the “four angels” like empathy, self-control, morality, and reason. Building on this, central conflict types, escalation levels, and de-escalation strategies are presented, complemented by personal survival strategies like meditation and regeneration.\n","title":"How to Survive Game of Thrones: What Westeros Teaches Us About Conflict, Violence, and Personal Resilience","type":"speaking"},{"content":"","date":"12 September 2014","externalUrl":null,"permalink":"/en/tags/personal-kanban/","section":"Tags","summary":"","title":"Personal Kanban","type":"tags"},{"content":"In a world overflowing with tasks, to-do lists, and competing priorities, staying productive and focused has never been more challenging. Personal Kanban is a lightweight, visual workflow management method rooted in the Toyota Production System and adapted for individual use by Jim Benson and Tonianne DeMaria Barry.\nWhat This Talk Covers # Drawing on just two foundational rules, visualize your work and limit work in progress (WIP), Personal Kanban offers a simple yet powerful alternative to traditional to-do lists, which often leave us feeling overwhelmed rather than accomplished.\nAttendees learn how to set up a Personal Kanban board using nothing more than sticky notes and a whiteboard, how to build and prioritize a backlog, and how to pull tasks through a Backlog, Doing, Done workflow.\nKey Messages # 1. Visualize Your Work Making work visible is the first step to managing it. A simple board with sticky notes creates clarity about what you are working on, what is waiting, and what is done.\n2. Limit Work in Progress Doing less at once means finishing more. By setting WIP limits, you reduce context switching and increase focus and throughput.\n3. Continuously Improve The presentation explores advanced board patterns including blocked task columns, time-horizon lanes (Today / This Week / This Month), and personal retrospectives for continuous self-improvement.\n","date":"12 September 2014","externalUrl":null,"permalink":"/en/speaking/personal-kanban/","section":"Speaking","summary":"In a world overflowing with tasks, to-do lists, and competing priorities, staying productive and focused has never been more challenging. Personal Kanban is a lightweight, visual workflow management method rooted in the Toyota Production System and adapted for individual use by Jim Benson and Tonianne DeMaria Barry.\n","title":"Personal Kanban: Visualize Your Work, Limit Your WIP, Transform Your Life","type":"speaking"},{"content":"I believe the next competitive edge isn\u0026rsquo;t AI itself, it\u0026rsquo;s the organisation around it. Feedback loops, governance, and continuous adaptation across people, process, and technology.\nMy Story # With over two decades in the technology sector, I focus on AI-augmented delivery, platform engineering, and enterprise evolution. As Group Chief AI Officer (CAIO) at Zühlke, I shape the global strategy and service portfolio for AI-Augmented Delivery \u0026amp; Platform, AI integration, platform engineering, and cloud solutions. My work redefines how organizations innovate, adapt, and scale in industries such as finance, insurance, cybersecurity, energy, healthcare, and aerospace.\nIn a world reshaped by Artificial Intelligence (AI), I believe the key to resilience and competitiveness lies in becoming AI-augmented, AI-enabled, and ultimately AI-native: a new operating model driven by feedback loops, intelligent workflows, and self-learning systems that place customer success at the center. I empower companies to continuously create value by harmonizing people, processes, technology, and AI.\nI began my journey at Zühlke more than two decades ago, evolving from software engineer and architect to trusted consultant, and now to my leadership role as Chief AI Officer. My passion for value creation through automation and quality led me from engineering into the DevOps movement and further into the forefront of enterprise transformation.\nI organize the monthly DevOps Meetup in Zürich and serve as president of DevOpsDays Zürich, an annual conference within the global DevOps movement. I share my insights via my YouTube channel, with over 500 videos, and through well over 30 blog articles focused on DevOps, architecture, leadership, and transformation.\nMy commitment to thought leadership and education extends to my role as a lecturer in DevOps leadership, agile methodologies, digital transformation, and enterprise architecture at the Lucerne University of Applied Sciences and Arts. I champion a culture of innovation and agility, helping enterprises evolve into adaptive systems capable of thriving in complex, fast-changing environments.\nMy work has been recognized through several awards and honors, reflecting my contributions to technology leadership and digital transformation.\nLet\u0026rsquo;s discuss your transformation →\n","externalUrl":null,"permalink":"/en/about/","section":"About","summary":"I believe the next competitive edge isn’t AI itself, it’s the organisation around it. Feedback loops, governance, and continuous adaptation across people, process, and technology.\nMy Story # With over two decades in the technology sector, I focus on AI-augmented delivery, platform engineering, and enterprise evolution. As Group Chief AI Officer (CAIO) at Zühlke, I shape the global strategy and service portfolio for AI-Augmented Delivery \u0026 Platform, AI integration, platform engineering, and cloud solutions. My work redefines how organizations innovate, adapt, and scale in industries such as finance, insurance, cybersecurity, energy, healthcare, and aerospace.\n","title":"About","type":"about"},{"content":"","externalUrl":null,"permalink":"/en/awards/","section":"Awards","summary":"","title":"Awards","type":"awards"},{"content":"","externalUrl":null,"permalink":"/en/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"I\u0026rsquo;m always looking for new and exciting opportunities. Let\u0026rsquo;s connect.\nConnect with me # Professional # LinkedIn: Professional networking \u0026amp; thought leadership GitHub: Code \u0026amp; open source projects Content # YouTube: Videos, talks \u0026amp; tutorials TikTok: Short videos Spotify: My Sound Social # X/Twitter: Updates \u0026amp; discussions Mastodon: Decentralized social Instagram: Behind the scenes ","externalUrl":null,"permalink":"/en/contact/","section":"Contact","summary":"I’m always looking for new and exciting opportunities. Let’s connect.\nConnect with me # Professional # LinkedIn: Professional networking \u0026 thought leadership GitHub: Code \u0026 open source projects Content # YouTube: Videos, talks \u0026 tutorials TikTok: Short videos Spotify: My Sound Social # X/Twitter: Updates \u0026 discussions Mastodon: Decentralized social Instagram: Behind the scenes ","title":"Contact","type":"contact"},{"content":"Practical, hands-on trainings for teams and leaders who want to build AI-native organisations, scale DevOps and Agile delivery, and develop cyber-physical products the lean-agile way. All courses are delivered through Zühlke Academy and include official certification where applicable.\nClick any course below to see the full programme and register at Zühlke Academy.\n","externalUrl":null,"permalink":"/en/courses/","section":"Courses","summary":"Practical, hands-on trainings for teams and leaders who want to build AI-native organisations, scale DevOps and Agile delivery, and develop cyber-physical products the lean-agile way. All courses are delivered through Zühlke Academy and include official certification where applicable.\n","title":"Courses","type":"courses"},{"content":" Core Expertise # AI-Augmented Delivery \u0026amp; Platform # Operating models for AI-powered enterprises: feedback loops, decision rights, governance, and platform foundations.\nEnterprise Architecture # Aligning capabilities, governance, and platforms so teams deliver measurable outcomes.\nPlatform Engineering \u0026amp; DevOps # Self-service platforms, developer experience, and delivery performance at scale.\nProfessional Track Record # Zühlke Group: more than two decades # Period Role 2026-Present Group Chief AI Officer \u0026amp; Partner 2025-2026 Global Chief of Cybernetic Transformation \u0026amp; Partner 2024-2025 Global Chief DevOps \u0026amp; Partner 2021-2024 Chief of DevOps \u0026amp; Partner 2016-2020 Principal Consultant \u0026amp; Partner 2009-2016 Lead Software Architect → Principal Consultant 2002-2009 Software Engineer → Expert Engineer Academia # Institution Role HSLU Co-Lead CAS Enterprise Architecture HSLU Lecturer CAS Digital Transformation HSLU Lecturer CAS DevOps Leadership FHNW Bachelor Thesis Expert Project Experience # 40+ enterprise projects across 8 industries over more than two decades\nIndustries # Banking \u0026amp; Finance: Major Swiss banks, private banks, fintech, global financial services. Agile transformation, digital transformation, DevOps transformation, platform engineering, architecture review Insurance, Health: Agile transformation, reinsurance risk modeling Pharmaceutical, Biotech: DevOps strategy, digital transformation Government: Federal Cybersecurity Office, architecture review Logistics: Digital transformation Energy: Power plant systems, electricity market platforms Defense: Secure communications, device administration Retail: Scaled agile transformation, HR digitalization Education # EMBA, Service Management, PHW Bern (2006)\nBSc, Computer Science, FHNW (2001)\nSelected Credentials # 18x SAFe Certified (SPC, Architect, LPM, DevOps, etc.) Certified AI-Native Foundations Professional iSAQB CPSA Foundation Level 45+ professional certifications Recognition # Digital Shapers 2026 (The Mentors) by BILANZ / Handelszeitung / digitalswitzerland DevOpsDays Zürich: Best DevOps Event of the Year 2026 (Organizer) LinkedIn Top Voice DevOps Dozent Finalist 2025 Author: The Cybernetic Enterprise ","externalUrl":null,"permalink":"/en/experience/","section":"Experience","summary":"Core Expertise # AI-Augmented Delivery \u0026 Platform # Operating models for AI-powered enterprises: feedback loops, decision rights, governance, and platform foundations.\n","title":"Experience","type":"experience"},{"content":"Download official photos and media assets for conferences, talks, and publications.\nProfessional Headshots # Click on any image to preview it. Use the download button to save the high-resolution version.\nAll Photos # Click on any image to preview it. Use the download button to save the high-resolution version.\nBio (Short) # Romano Roth is Chief AI Officer at Zühlke. He helps CTOs/CIOs turn AI ambition into an operating model with clear feedback loops, decision rights, governance, and platform foundations that make execution repeatable.\nBio (Full) # Romano Roth is Chief AI Officer at Zühlke. He helps CTOs/CIOs turn AI ambition into an operating model with clear feedback loops, decision rights, governance, and platform foundations that make execution repeatable.\nWith more than two decades of experience spanning software engineering, architecture, consulting, and executive leadership, Romano bridges strategy and execution to help organizations deliver outcomes in complex environments.\nHe is the author of \u0026ldquo;The Cybernetic Enterprise: How to Build a Future-Ready Organization\u0026rdquo; and a regular speaker at industry conferences. Romano also contributes to the tech community as a lecturer and organizer of DevOps Meetup Zurich and DevOpsDays Zurich.\nUsage Guidelines # These photos are provided for press and promotional use in connection with Romano Roth\u0026rsquo;s speaking engagements, publications, and professional activities. Please credit \u0026ldquo;Romano Roth\u0026rdquo; or \u0026ldquo;Zühlke\u0026rdquo; when using these images.\nIf you need the full resolution picture, please contact me.\nFor any questions about usage rights or to request additional materials, please contact me.\n","externalUrl":null,"permalink":"/en/media-kit/","section":"Media Kit","summary":"Download official photos and media assets for conferences, talks, and publications.\nProfessional Headshots # Click on any image to preview it. Use the download button to save the high-resolution version.\n","title":"Media Kit","type":"media-kit"},{"content":"Talks, interviews, and video content about DevOps, Platform Engineering, AI, and AI-augmented organizations.\n","externalUrl":null,"permalink":"/en/videos/","section":"Videos","summary":"Talks, interviews, and video content about DevOps, Platform Engineering, AI, and AI-augmented organizations.\n","title":"Videos","type":"videos"}]