Wir sind eine zertifizierte B Corporation.

Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

AKTUELLES

Community

Keycloak

News

Thomas Darimont ist erster Keycloak-Maintainer außerhalb von RedHat

Thomas Darimont von der codecentric AG wurde zum ersten offiziellen Maintainer von Keycloak außerhalb von RedHat berufen.

Thomas Darimont von codecentric ist Keycloak-Maintainer

Warum sollte man Dotfiles bei Github lagern? Ist man seltsam, nur weil man introvertiert ist? Ist Typisierung für die Frontend-Entwicklung Fluch oder Segen? Ist es OK, Band-Shirts, Meggins oder Crocs beim Kunden zu tragen? Und was haben alle diese Themen überhaupt miteinander zu tun? – Solche und viele andere Fragen stellen und beantworten <a href="https://www.codecentric.de/team/holger-gp/">Holger Grosse-Plankermann</a> und <a href="https://www.codecentric.de/team/benedikt-ritter/">Benedikt Ritter</a> in ihrem “launigen Bier-Talk”-Podcast <a href="http://autoweird.fm" target="_blank">@Autoweird.fm</a> .Im November 2016 gestartet, gibt es zu Beginn jeder Folge erstmal ein Bierchen, über das auch – mal mehr, mal weniger – gefachsimpelt wird. Dann aber geht es direkt über zum Tagesthema. Und das kann im Grunde alles sein, denn Holger und Benedikt podcasten über das, was sie erleben, was sie bewegt und interessiert. Das ist mal technischer, mal privater Natur, hat aber immer irgendwie einen Software-Bezug.<a href="https://media.graphassets.com/6TIk6GZTJqNZE8POJ8bg"><img width="700" height="525" src="https://media.graphassets.com/6TIk6GZTJqNZE8POJ8bg" alt="Benedikt Ritter und Holger Grosse-Plankermann vom Podcast @Autoweird.fm" /></a> <h2>Podcast als Community-Beitrag</h2>Bei der codecentric AG wird Community Engagement groß geschrieben – zum Beispiel hier im Blog. Benedikt, der auch privat gerne Podcasts hört, wollte aber lieber ein ganz eigenes Format entwickeln. Kollege Holger hatte zwar von Podcasts noch keinen Schimmer, aber dafür von Tontechnik, da er Musik macht. “Bei uns stimmte gleich die Chemie”, sagt Benedikt. So manifestierte sich die Idee zum eigenen Podcast bei ein paar Bier, und dem sind die beiden auch treu geblieben.Zunächst haben sie einfach ein iPhone-Mikro verwendet und waren bei der Aufzeichnung nicht mal im gleichen Raum. Gepublished wurde über eine Online-Plattform: “Es sollte nichts kosten”, erklärt Benedikt. Denn die beiden bestreiten ihren Podcast in ihrer Freizeit. Warum eigentlich? – codecentric bietet doch <a href="https://www.codecentric.de/karriere/?">+1-Zeit</a> , in der die beiden das machen könnten!? Das erklären sie so: “Wir wollen unsere Freiheit haben. Klar reden wir auch viel über unsere Arbeit hier, aber wir wollen eben über alles reden können, worauf wir gerade Lust haben, auch wenn das nicht zur Firma gehört.” In den letzten Monaten haben sie ihre Vorgehensweise immer wieder angepasst: Die Dropbox stieß an’s Datenlimit, so erfolgte der Umstieg auf Amazon S3, die Tonqualität wurde durch ein hochwertiges Mikrofon verbessert. Auch haben beide gemerkt, dass die Dynamik ihres Gesprächs viel besser ist, wenn sie zusammensitzen. Die Software Zencastr haben sie ausgetauscht durch GarageBand. Ausgeliefert wird der Podcast über Github. Vor Kurzem haben sie noch ein Intro hinzugefügt, und wer sich nicht für Bier interessiert, der kann dieses Chapter einfach überspringen.<h2>Unterhaltsame Sicht auf Software-Branche</h2>Perfekt sei @Autoweird.fm deswegen immernoch nicht, aber beide stehen zu ihren “Ähs” und “Öhs”, schneiden hinterher auch nichts mehr raus. “Als wir angefangen haben, haben wir das eigentlich nur für uns gemacht. Zwei Typen, die über Bier und Unsinn reden – wen das nicht interessiert, der muss ja nicht zuhören. Aber es stellte sich heraus, dass das den Leuten tatsächlich ganz gut gefällt.” Wie viele eigentlich zuhören, können sie nicht genau sagen, auch daran wollen sie noch etwas ändern. Und mehr Interaktion mit den Hörern wäre auch schön. Warum also sollte man Benedikt und Holger alle zwei Wochen einschalten? – “Wir sprechen über Themen, die für Softwerker im deutschen Raum relevant sind, aber nicht ausschließlich über Programmierung und auch nicht immer nur bierernst. Wir wollen die Themen aus verschiedenen Blickwinkeln betrachten, frei darüber brainstormen und dabei keiner einstudierten Choreographie folgen, sondern authentisch bleiben.” Letzte Frage: Was ist das eigentlich für ein Name “@Autoweird.fm”? – “Das ist eine Abwandlung der Annotation @Autowired aus dem Spring Framework”, erklärt Benedikt. Das .fm haben sie in guter Radiomanier noch drangehängt. Wer eigentlich auf die Idee kam, wissen sie gar nicht mehr genau; sie entstand beim Flachsen mit einem Kollegen.Wer Benedikts und Holgers unterhaltsame Sicht auf die Software-Branche (und auf Bier) hören möchte, findet inzwischen 20 Folgen <a href="http://Autoweird.fm" target="_blank">auf der @Autoweird.fm-Website</a> . Die beiden freuen sich über Feedback.

@Autoweird.fm Podcast – Software, Bier und alles andere

<a href="https://www.codecentric.de/team/daniel-mies/">Daniel Mies</a> will’s wissen: Egal, ob UX, Scrum oder JavaScript – der IT Consultant stöberte schon immer gerne durch alle möglichen Facetten der Software-Entwicklung. Neue Themen kennenzulernen und sein Wissen dann auch zu teilen, hat ihm schon immer Spaß gemacht. Neuerdings lässt er nun ein breites Publikum an seinen “Erkundungstrips” teilhaben. Vor wenigen Wochen hat er einen eigenen Podcast ins Leben gerufen, dessen Name Programm ist: “<a href="https://mies.me" target="_blank">Herr Mies will’s wissen!</a> ”Auf die Idee zum eigenen Podcast haben ihn <a href="https://blog.codecentric.de/2017/08/podcast-autoweird-fm-ueber-software-bier-und-alles-andere/">die Kollegen von @Autoweird.fm</a> , Holger Grosse-Plankermann und Benedikt Ritter, gebracht, als sie bei der internen <a href="https://www.codecentric.de/2017/07/06/die-erste-codecentric-unconf-war-ein-voller-erfolg/">codecentric Unconf</a> eine Session dazu hielten. Als die beiden erzählten, wie sie angefangen haben und vorgehen, war für Daniel klar: “Sowas will ich auch gerne machen.” Nicht etwa der “Berühmtheit” wegen, sondern vielmehr, um über den eigenen Tellerrand zu schauen: einerseits was die technische Umsetzung der Podcastproduktion betrifft und andererseits natürlich in Form der Themen, die er behandelt. “Aufnehmen, schneiden und alles, was bei der Produktion noch mit dran hängt – da hatte ich sofort Lust drauf.” Er machte sich an die Recherche, wie und womit er sein eigenes Format starten kann. “Learning by Doing”, beschreibt Daniel. “Ich wollte ein kompaktes Setup, statt einem riesigen Technikkoffer, so dass ich quasi überall Sendungen machen kann.” So zum Beispiel im Restaurant, wo er seine erste Interviewfolge zusammen mit Holger aufgenommen hat. – Eine kleine Anerkennung dafür, dass er ihm viel Starthilfe gegeben hat. “Ich habe ihn zu Beginn richtig gelöchert. Der finale Name des Podcasts war sogar Holgers Idee”, erzählt Daniel.<h2>Eine Folge, ein Experte</h2>Daniels Konzept sind Experteninterviews. Seine Gesprächspartner beantworten ihm dabei alles, was die Hörer zum Einstieg in Themen von JavaScript bis Scrum benötigen: “Das kann zum Beispiel das Thema UX sein, das für Leute erklärt wird, die darüber bisher gar nichts wissen. Man erhält in 30 bis 45 Minuten kompakt alle Infos, die man für den Anfang braucht.” Als Moderator stellt er die brennenden Fragen. Im Gespräch selbst nimmt er sich aber bewusst zurück: “Ich entwickle schnell eine eigene klare Meinung zu technischen Dingen, aber das soll nicht Fokus im Podcast sein – dafür hole ich mir die Experten, die sozusagen aus dem Nähkästchen plaudern, wie man in das Thema einsteigen kann.” Als Moderator trete er auch ganz bewusst nicht im Namen der codecentric auf: “Meine Experten sind natürlich ganz häufig Kollegen, aber an sich sind die Themen unabhängig.” Die Trennung war ihm wichtig, und die Firma lasse einem da ja auch die nötigen Freiheiten. Auch was den Tenor seines Podcasts betrifft, hat Daniel bewusst einen anderen Weg eingeschlagen als Holger und Benedikt: “Zum einen habe ich eben die Interviews, zum anderen wollte ich auch den Gesprächscharakter der beiden nicht ‘kopieren’, sondern meinen eigenen Stil entwickeln.”<a href="https://media.graphassets.com/zkcVPWB9TkyarLkHYdBK"><img width="540" height="497" src="https://media.graphassets.com/zkcVPWB9TkyarLkHYdBK" alt="Daniel Mies bei der Aufnahme seines Podcast" /></a> Daniel Mies (rechts) im Interview mit Kollege Christian BärInzwischen hat Daniel bereits fünf Folgen veröffentlicht. Diese erscheinen alle zwei Wochen jeweils mittwochs. Mehrere weitere habe er bereits in der Pipeline. Die Themen werden ihm so schnell nicht ausgehen, ist sich Daniel sicher, und die codecentric trage dazu auch ihren Teil bei: “Es ist bei uns eigentlich Gang und Gäbe, dass wir Kollegen uns über unsere Projekte austauschen und so auch immer wieder technische Dinge kennenlernen, mit denen wir erst mal selbst gar keine Berührungspunkte haben.”<h2>In den Expertenschuhen</h2>In einem weiteren nebenberuflichen Projekt wechselt Daniel dann übrigens wieder in die eigene Expertenrolle zurück: Seit zwei Jahren engagiert er sich bei “<a href="https://jugendhackt.org/" target="_blank">Jugend hackt</a> ”. “Es ist eine unglaublich tolle Erfahrung mit jungen Leuten zu arbeiten, die genauso ticken, wie man selbst.” Nicht ohne Grund sei das Motto “Mit Code die Welt verbessern”: “Hier werden junge Menschen zum Programmieren motiviert, egal welchen Hintergrund sie haben. Und dann entstehen ganz tolle Projekte, die wiederum darauf ausgerichtet sind, einen gesellschaftlichen Zweck zu erfüllen, wie zum Beispiel eine Orientierungs-App für Flüchtlinge.” In der Software-Branche sollte es eigentlich selbstverständlich sein, dass man auch irgendeinen Beitrag leistet, findet Daniel: “Es gibt ja ganz viele Möglichkeiten, sich zu beteiligen, zum Beispiel in Open-Source-Projekten.” Fast täglich arbeite man selbst mit diesen Angeboten ohne etwas dafür bezahlen zu müssen: “Da ist es nur fair, dass man an anderer Stelle etwas zurückgibt – ich habe mich für “Jugend hackt” entschieden, weil es mir einfach schon immer viel Spaß gemacht hat, Erfahrung direkt weiterzugeben.”Wer also Lust hat, sich in den kurzweiligen Folgen von „Herr Mies will’s wissen“ über neue Themen schlau zu machen, der findet <a href="https://mies.me" target="_blank">alle Folgen bei Github</a> . Alle Neuigkeiten erfahrt ihr auch auf Daniels Twitter Account <a href="https://twitter.com/HerrMies" target="_blank">@herrmies</a> – hier könnt ihr die Interviews auch gleich mitgestalten und Fragen für neue Themen vorschlagen.

Neuer Podcast: Herr Mies will’s wissen – und mitteilen!

EventStorming Creator, author of <a href="https://www.eventstorming.com/" target="_blank">Introducing EventStorming – An act of deliberate collective learning </a> and founder of <a href="https://www.avanscoperta.it/it/" target="_blank">Avanscoperta</a> , Alberto Brandolini is a 360° consultant in the Information Technology field. Asserting that problems cannot be solved with the same mindset that originated them, Alberto switches perspective frequently assuming the architect, mentor, coach, manager or developer point of view. In November, he is visiting Germany to give his <a href="https://info.codecentric.de/eventstorming-workshop-with-alberto-brandolini?">workshop “EventStorming” in Munich</a> . We had the opportunity to interview him.codecentric: In his book „Domain-Driven Design“ (2004), Eric Evans proposed an approach to designing complex software systems from the business first, starting with a domain model, which requires domain experts and software developers to work together. To achieve this, he provided a framework for making design decisions and a vocabulary for discussing domain design. Can you give us a short introduction why a common understanding of the business domain matters in our industry?Alberto Brandolini: I think Domain-Driven Design (DDD) exposes a fundamental flaw of software development for the enterprise: the notion that we can build – horrible word, the software is not a house! – software upon trusted requirements.This is an illusion, and a dangerous one. Some requirements can be certain, like “It should be possible to import files from version 2.1”. But many of them are going to be uncertain even if they seem to be carved in stone. They’re going to be contradictory, because of the nature of organizations: silos and departments with different views and needs, not to mention the hidden conflicting goals. Eric Evans also shifts the focus to the language. The language itself cannot be trusted: terms are ambiguous in their nature, different people will have a different interpretation for the same word.So DDD promotes a way to develop software that assumes a high level of architecture fluency and proficiency – to have more options available – and allows the development of multiple very efficient models perfectly tailored to the local contexts.The enemy hiding in shadows is the notion of “the large data-centric model” that was so pervasive in the past years. The fundamental ambiguity of the language was ruled out by data-centric implementation that forced entire organizations to agree on what a “Customer” or an “Order” meant, forcing them also to agree on ways to share data, only to find themselves locked in a stalemate a few years later: everybody is depending on the same data, so changing it is now too risky. Confidence is gone, evolution slows down and workplaces stop being interesting.I think the whole problem has been there for a very long time, but it’s exploding now for two factors. The first one is Microservices: they’re fashionable right now, but their promise can only be fulfilled with a DDD way of thinking especially when it comes to Bounded Contexts. The second one has to do with the job market: there’s a growing trend of developers leaving unhealthy workplaces, and in my opinion, there’s a strong correlation between given architectures where the dominant feeling is fear of breaking things and the inability to retain talent.<blockquote>It turns out that a deep understanding of the business – as advocated by Domain-Driven Design – can be a great driver for a more purposeful approach to software development: we understand what’s the right thing to, and we turn it into a software solution with the lowest number of trade-offs.</blockquote>Feels good, and makes me want to stay to see the end.codecentric: In 2013 you introduced your workshop concept “EventStorming”, which translates the DDD philosophy into a group collaboration format and light-weight modeling technique. How did you discover it?Alberto: EventStorming didn’t happen as a planned discovery. The first time I started modeling with colored sticky notes on a paper roll, it was in a little meetup between friends and colleagues of the Italian DDD Community. It’s interesting to look at the details: the meetup was happening on Saturday and I drove 200 km to get there. I took my tools with me: sticky notes and a paper roll. At that time I always had a paper roll in my backpack, because I couldn’t stand the constraints on meeting rooms shape and availability. My friend Emanuele Delbono was hosting the workshop and described the process he wanted to explore, and then we split into groups. I needed to baseline something quickly so I took the paper roll – there were whiteboards, but there were other teams too – and started to lay down my understanding with the DDD and CQRS building blocks, and got to something in a few minutes, while the other teams hadn’t even started. Ok, I had a good hand this round. But I think the surrounding matters: it wasn’t a business environment, it was among friends and it was a Saturday. This combination gave me all the possible freedom for experimentation: I was amidst smart people so I could skip the introduction and get straight to the point, and I also knew that we were there to discuss. Shortcomings in an experiment would have been addressed. Later, I started using this approach – initially called Event-Based Modeling – to teach DDD building blocks to newbies, without passing through the traditional definitions. And it worked and got some practitioners hooked. The real explosion happened when Vaughn Vernon invited me as a ‘special guest’ on his IDDD tour, in Leuwen and Cracow. That was not ‘just a class’. There were 50-70 amazing people in the room and they loved EventStorming and started experimenting in their workplaces, in their local communities and providing incredibly valuable feedback, ideas, and variations.codecentric: In the past, you have compared EventStorming to creating pizza – which seems alarmingly trivial, considering the complexity of the problems that want to be solved …Alberto: I still do! But I don’t think it is trivial. I am Italian and aware of the real complexity of making a good pizza. A good friend of mine is into the business of gourmet pizza, and there’s definitely a lot to know to make a memorable product out of apparently simple ingredients. So, pizza is definitely serious stuff for me.The point I am trying to make with the pizza metaphor is that collaboratively validated business storytelling is a platform for more sophisticated reasoning. I have variations for the big picture recipe that could go for an ‘Enterprise Retrospective’, an ‘Organization Reboot’, a ‘Startup Design’, or a ‘Launch new Product’ type of workshop. They share the foundation, but the steps can be different.Also, Process Design and Software Design are very different from the big picture recipe: here we’re building something, collaboratively enforcing a colored grammar that serves as an interdisciplinary lingua franca. The dynamics here are really different, but still, the basic ingredient is validated event-based storytelling.Some colleagues developed their own variations from that recipe: Konstantin Kudryashov visualizes delays to get a Value Stream Mapping out of it, Paul Rayner, Wojtek Ptak and Mariusz Gil had interesting value-oriented variations too; Jacopo Romei uses Big Picture to visualize inconsistencies in organization culture and behavior. Not to mention more radical offsprings like Adam Dymitruk’s Event-Modeling.What amazes me is the possibility of combining some elements from everybody’s background into a very flexible and powerful tool. Locking the recipe into orthodoxy would prevent a lot of this magic from happening. Of course, some people will make bad recipes, but some others will come up with an amazing one.codecentric: 8-16 participants in one room, often meeting for the very first time in person, and all of them with their own subjective views of and biases about the business domain – how do you manage to distill a coherent “big picture” from this initial “chaos”?Alberto: I’d say it is pure facilitation magic. Nobody wants to be the one that just put sticky notes on the wall, leaving it in a chaotic space, so we can rely on the assumptions that everybody in the room wants to sort out this mess badly.The more structured answer is “step by step”.<blockquote>We start from chaos – well, locally consistent clusters of events in an inconsistent whole – then we try to impose some structure. We then realize our initial structure was naive, then we apply something more sophisticated, till we get to an organization which is satisfactory for everybody in the room.</blockquote>Sorting out the mess together is an act which is between learning and team building. But it also serves the purpose of challenging the status quo: the initial chaos encourages dissonant voices that would not easily surface when starting from a superimposed structure.The last trick is what I call “Incremental Notation”: I am ready to visualize boundaries, actors, systems, departments and many other constraints. But I start from the simplest possible building blocks, the Events, and then I ask the audience what they would need to see next. This way the workshop tends to stay in the sweet spot of engagement and goes where it can deliver more value.But you mentioned coherence, and here’s a thing: coherence is not necessarily my goal. Especially in Big Picture, I need to visualize our current state of understanding of the business. If our business is incoherent, I need to visualize reality, not a photoshopped version of it. Hot Spots are my best friends here: all the disagreements are visualized, a few can be resolved, but not all of them.codecentric: There are other approaches, such as “Domain Storytelling”, which focus primarily on creating empathy between the parties involved. How do you handle the emotional aspect of participants discussing and disagreeing, urgencies and process flows?Alberto: There are a few ideas that help dissent to be visualized: from providing markers and stickies to everyone so that they can write before agreeing on what to write, to encouraging the use of Hot Spots (especially when trying to converge on a solution).However, emotions are really context-dependent, and human beings can always surprise you. So a prescriptive recipe on how to handle emotions sounds like a bad idea to me. But as facilitators, we can handle the system: a chaotic round of problems and opportunities will leave everybody the opportunity, and sometimes the anonymity, to visualize dissent without openly challenging the boss.I do a few things, though. I observe participants, I quietly ask disengaged ones for feedback, I look at body language signals to check if something is wrong. I do a few things consciously, like setting an informal tone with little space for hierarchy and distances, and I suspect there are a few things that I do unconsciously, that make participants feel safe. <blockquote>But I have to say that many times showing the whole story did a little miracle: it’s hard to get angry with your coworkers who are clearly doing their best given their constraints. I do open Pandora’s box. But what I get is more reconciliation than fights.</blockquote>codecentric: Larger businesses often have a unique set of rules and regulations, which can work against the free flow of information between developers and domain experts, and make collaborative workshops difficult. What do you do about company politics? Alberto: Personally? Nothing. I just make their impact visible. Usually, I am not called into an organization to start a revolution, and having a solution before understanding the problem isn’t a great strategy for a consultant. I have a radical transparency policy inside my company because I find this approach to be more effective, given our size mission and skills, but it doesn’t mean every organization should adopt the same principles.So constraints and regulations are in place? Let’s make them visible! Let’s see the impact. Let’s see if our competitors have the same problem, or if they’re exactly under the same constraints. Once the constraints are visible, and they’re diagnosed to be part of the problem, we can play what-if.In my personal experience, I’ve found a lot of discrepancies between the constraint and its actual implementation. There were simple solutions available that were perfectly compliant to the rule – if the constraint came from a legal background – or to the idea – if the constraint was originated from some corporate rule.There’s a variety of solutions that can be applied: fuzzy processes can preserve the spirit of a rule without being trapped into rigid mechanics; I’ve found a lot of inspiration in Dave Gray’s ‘The Connected Company’ that provides a good review of different enterprises, policies, and organizations, for example shifting from rules to principles. And I always have Cynefin in the back of my head: complicated processes to handle complexity is not a good fit.codecentric: To sum it up, what problem does EventStorming solve, and how is that accomplished? When is it useful, and for whom?Alberto: As I hinted earlier, EventStorming isn’t aimed at one specific problem. It’s a platform, providing recipes that are useful in a wider spectrum of problems.The most obvious ones are related to cross-silo collaboration, because of lack of visibility, transparency, common language and blame game. Whenever collaboration is needed across boundaries, the combination of event-driven storytelling and visualization can be incredibly useful.However, more practically, here are a few ways I’ve used EventStorming, from large scale to small scale.To build a model of an entire business line. In a single workshop, we validated the business narrative and highlighted inconsistencies so that the software teams weren’t bound anymore to contradictory or conflicting requirements. Moreover, we could highlight the natural boundaries for partitioning the system into Bounded Contexts.To lay down the design of startup. It doesn’t happen often – most startuppers are unaware of the problems in the software architecture space – but we’ve done it with Soisy.it and it turned into a cool success story: we blueprinted the whole event-driven architecture in 18 meters of space and less than 3 days of work.To retrospective (and re-align) an entire organization. Retrospectives across team boundaries lack the common ground and easily turn into a blame game. EventStorming provides the common ground and supports more informed and educated conversations, not to mention the prioritization of key issues, that becomes embarrassingly obvious.To design processes which are business-friendly and customer-friendly and tech-friendly too. When many stakeholders are involved, it’s too easy to say “We can’t make everybody happy!” … but that’s not true: we just need a more structured conversation in order to make every stakeholder reasonably happy.To design Event-Driven and/or Event-Sourced software with very high efficiency. The impedance mismatch between business storytelling and software implementation is minimized (that was the DDD goal from the very beginning). Technical stakeholders including UX and business stakeholders can improve their model together and get quickly to testing and implementing the software: roundtrips between ideas and implementations can get very short with the right infrastructure in place.codecentric: Thanks a lot for the interview, Alberto!A shorter, translated (German) version of the interview was published on <a href="https://www.heise.de/developer/artikel/Ich-oeffne-die-Buechse-der-Pandora-Interview-mit-Alberto-Brandolini-4510288.html" target="_blank">heise developer</a> . <a href="https://media.graphassets.com/BbcTUkTRSO5SLIyOMBY7"><img width="250" height="167" src="https://media.graphassets.com/BbcTUkTRSO5SLIyOMBY7" alt="EventStorming" /></a> EventStorming Creator, author of <a href="http://eventstorming.com/" target="_blank">Introducing EventStorming – An act of deliberate collective learning</a>  and Founder of Avanscoperta, Alberto Brandolini is a 360° consultant in the Information Technology field. He’s a frequent speaker in software development related conferences in Italy and across Europe, since rumors spread about his funny attitude. Besides consulting and running Avanscoperta, he’s also a trainer for UK based company Skills Matters where he teaches Domain-Driven Design.

“I open Pandora’s box” – An interview with Alberto Brandolini on Domain-Driven Design and EventStorming

Internal Communications Lead

Über Thomas Darimont

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Absenden

Thomas Darimont ist erster Keycloak-Maintainer außerhalb von RedHat

Über Thomas Darimont

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten