Archiv der Kategorie: German

Freigrenze vs. Freibetrag

Heute bin ich von meinem Steuerberater auf die wichtige Unterscheidung zw. Freigrenze und Freibetrag aufmerksam gemacht worden, was ich bis dato synonym verwendet habe.

Dazu ein Beispiel:

  • 40€ sind die jeweilige Grenze
  • Der Kauf übersteigt die Grenze um 1€, sprich die Gesamtkosten belaufen sich auf 41€

Freigrenze

Im Fall der Freigrenze muss bei Übersteigung des Grenzbetrags die volle Summe versteuert werden, d.h. die vollen 41€ sind steuerpflichtig.

Freibetrag

Im Fall des Freibetrags muss lediglich der die Grenze übersteigende Betrag versteuert werden, d.h. 1€.

Bei Streuartikeln (bis 10€ netto) und Sachzuwendungen an Geschäftsfreunde (35€ pro Jahr und Person) bzw. Sachzuwendungen an Arbeitnehmer (44€ pro Mitarbeiter und Monat | nicht auf Folgemonat übertragbar) handelt es sich um Freigrenzen. Leider sind im betrieblichen Umfeld die meisten Grenzen Freigrenzen.

Ein Freibetrag wäre z.B. der sogenannte Rabattfreibetrag, bei dem der Arbeitgeber seinen Angestellten Rabatte auf die eigenen Waren oder Dienstleistungen gewährt.

Microservices mögen kein Denken in klassischen Entitäten

Einen ganz besonderen AHA Moment hatte ich kürzlich in einem Workshop bei Udi Dahan, CEO von Particular. In seinem Beispiel ging es um die klassische Entität eines Kunden.

Microservices zu realisieren bedeutet Fachlichkeiten sauber schneiden und in eigenständige Silos (oder Säulen) packen zu müssen. Jedes Silo muss dabei die Hohheit über die eigenen Daten besitzen, auf denen es die zugehörigen Geschäftsprozesse abbildet. Soweit so gut. Doch wie lässt sich dies im Falle eines Kunden bewerkstelligen, der klassischerweise wie im Screenshot zu sehen modelliert ist? Unterschiedliche Eigenschaften werden von unterschiedlichen Microservices benötigt bzw. verändert.

Wird die gleiche Entität in allen Silos verwendet, muss es eine entsprechende Synchronisierung zw. den Microservices geben. Das hat erhelbiche Auswirkungen auf Skalierbarkeit und Performance. In einer Applikation mit häufig parallelen Änderungen an einer Entität wird das Fehlschlagen von Geschäftsprozessen zunehmen – oder im schlimmsten Fall zu Inkonsistenzen führen.

Klassische Kundeentität

Klassische Kundeentität

 

Udi schlägt die folgende Modellierung vor:

Neue Modellierung eines Kunden

Der Kunde wird durch unabhängige Entitäten modelliert

Zur Identifikation, welche Daten zusammengehören, schlägt Udi einen Interessanten Ansatz vor:

Fragt die Fachabteilung, ob das Ändern einer Eigenschaft Auswirkung auf eine andere Eigenschaft hat. 

Würde das Ändern des Nachnamens einen Einfluss auf die Preiskalkulation haben? Oder auf die Art der Marketings?

Nun gilt es noch das Problem der Aggregation zu lösen, sprich wenn ich in meiner Anzeige unterschiedliche Daten unterschiedlicher Microserivces anzeigen möchte. Klassischerweise würde es jetzt eine Tabelle geben, die die Spalten

 

ID_Kunde ID_Kundenstamm ID_Bestandskundenmarketing ID_Preiskalkulation

 

besitzt. Das führt aber zu 2 Problemen:

  1. Die Tabelle muss immer erweitert werden, wenn ein neuer Microservices hinzugefügt wird.
  2. Sofern ein Microservices die gleiche Funktionalität in Form unterschiedlicher Daten abdeckt, müssten pro Microservices mehrere Spalten hinzugefügt und NULL Werte zugelassen werden.

Ein Beispiel für Punkt 2 wäre ein Microservices, der das Thema Bezahlmethoden abdeckt. Anfangs gab es beispielsweise nur Kreditkarte und Kontoeinzug. Dann folgte Paypal. Und kurze Zeit später dann Bitcoin. Der Microservices hätte hierzu mehrere Tabellen, wo er die individuelle Daten für die jeweilige Bezahlmethode halten würde. In oben gezeigter Aggregationstabelle müsste aber für jede Bezahlmethode, die der Kunde nutzt, eine Spalte gefüllt werden. Wenn er sie nicht benutzt, würde NULL geschrieben werden. Man merkt schon: Das stinkt.

Ein anderer Ansatz ist da deutlich besser geeignet. Welcher das ist und wie man diesen technischen realisieren kann, könnt ihr im GitHub Repository von Particular nachschauen.

 

Quellen zu Defensives Design und Separation of Concerns sind jetzt online

Den Quellcode zu meinen Vorträgen auf den Karlsruher Entwicklertagen und der DWX sind jetzt online:

  • Zu Super Mario Kata mit Fokus auf Defensivem Design geht es hier.
  • Zur Prüfsummen Kata mit fokus auf Separation of Concerns gelangt ihr hier.

Auf beiden Seiten findet ihr auch die Links zu den PowerPoint Folien. Im Juli 2018 werde ich den Code der Prüfsummen Kata noch in Form von Iterationen veröffentlichen und beide Talks als YouTube Video freigeben.

IMG_20180627_145405

Defensives Design Talk auf der DWX

Ihr wollt Teile davon in euren Vorträgen verwenden, ihr wollt ein Training zu dem Thema oder ich soll dazu in euerer Community einen Vortrag halten, dann kontaktiert mich über die auf GitHub genannten Kanäle.

Kausale Ketten: Gründe für das Scheitern von Softwareprojekten

Auf dieser Github Page habe ich begonnen die Problemen in Softwareprojekten, die uns täglich begegnen, genauer zu analysieren, um diese vermeiden bzw. beheben zu können.

In Gesprächen mit Teilnehmern meiner Workshops werden mir regelmäßig Symptome geschildert, von denen ich der Meinung bin, dass die Ursache wie so oft tiefer liegt.

Tituliert habe ich das als kausale Ketten und orientiere mich dabei an folgendem Schema:

  • Was ist das wahrgenommene Problem, also das Symptom
  • Wie kam es dazu, also die Verlaufsbetrachtung
  • Warum kam es dazu, was ist die Ursache

Zudem suche ich nach nachvollziehbaren Beispielen, um die Theorie zu untermauern.

Ich verstehe die Seite als Anreiz zum Nachdenken. Alle „Thesen“ sollen als Einstieg in eine lebendige Diskussion dienen.

Gebt mir gerne Feedback in Form von Pull Requests.

Termin nossued 2019

In diesem Jahr fand der #nossued noch vor Beginn der Sommerferien in den meisten Bundesländern statt. Das Feedback der letzten Jahren ging dahin, dass der ein oder andere aufgrund der Schulferien nicht kommen konnte.

Neben der Berücksichtung von zeitlich verschobener Ferien in den einzelnen Bundesländern gilt es natürlich noch auf etablierte Events wie die dotnet Cologne Rücksicht zu nehmen.

Der ein oder andere hadert mit Juni/Juli auch wegen den alle 2 Jahre stattfindenden Fußballturnieren oder weil die warme Sommerzeit lieber für Freizeitaktivitäten genutzt wird. Andere wiederum schätzen genau die strahlende Sonne und die Möglichkeit die Dachterrasse nutzen zu können.

Daher würden wir von der Organisation gerne wissen, wie ihr zu den möglichen Terminen 2019 steht. Denkbar wären auch frühere Termine wie die Zeiträume vom 08. März bis 04. April und 27. April bis 31. Mai. Wie steht die Community dazu?

Eure Rückmeldungen würden uns freuen, z.B. in Form von Nennung von guten Zeiträumen oder weniger geeigneten Monaten.

Beispiele für Zielvereinbarungen

Allgemeines

Dieser Beitrag soll als kleine Hilfestellung für all diejenigen dienen, die sich mit der Findung von guten Zielen schwertun. Wer wie wir darauf hinarbeitet, dass die Mitarbeiter sich aus der Unternehmensstrategie die individuellen Ziele selbst ableiten und der Vorgesetzte nur noch unterstützende Funktion (z.B. Bereitstellen von Resourcen) ausüben muss, der wird zuerst viel kommunizieren und beraten müssen.

Während die eine Seite erfolgreicher Zielvereinbarungen die Verlagerung der Zieldefinition auf den Mitarbeiter selbst ist, ist die andere das Sichtbarmachen der operativen und strategischen Unternehmensziele. Damit einher geht natürlich das kontinuierliche Gespräch über die gemeinsame Unternehmenskultur. Beispielsweise wird es schwierig über monetäre Ergebnisziele zu sprechen, wenn die Kennzahlen nicht transparent zur Verfügung gestellt und erklärt werden. Nicht jeder Chef ist davon begeistert, wenn die Angestellten die genauen Margen von Aufträgen kennen.

  • Der Kern guter Ziele sind die S.M.A.R.T. Kriterien, auf die an dieser Stelle nicht weiter eingegangen werden soll.
  • Die Ziele drüfen sich nicht gegenseitig beeinträchtigen. Stattdessen sollen sie sich vielmehr gegenseitig beflügeln.
  • Die Erreichung des Ziels soll immer einen direkten oder indirekten Benefit für das Unternehmen haben (Stichwort Return on Invest).

 

Auf den Punkt gebracht: Die Mitarbeiter müssen um die Unternehmsziele wissen und diese mittragen. Ein gemeinsames Verständnis der Modalitäten und eine dazu passende Informationstransparenz sind ebenso elementar wie das Mitwirkenwollen des Einzelnen.

 

Beispiele für individuelle Ziele

  • Community Auftritte
    • Bis 31.12.18 hält der Mitarbeiter in den User Groups Berlin, Dresden, Leipzig, Chemnitz, Karlsruhe und Luzern Vorträge
  • Fachartikel
    • Bis 31.12.18 publiziert der Mitarbeiter 3 Fachartikel in Fachzeitschriften (z.B. in der dotnetpro)
  • Öffentliche Auftritte auf Konferenzen
    • Bis 31.12.18 hält der Mitarbeiter auf mind. 3 unterschiedlichen, kommerziellen Konferenzen Talks oder Trainings (z.B. DWX, Karlsruher Entwicklertage etc.)
  • Kommerzielle Workshops
    • Bis 31.12.18 generiert der Mitarbeiter durch Workshops einen Gesamtumsatz von mind. 20.000€
  • Fakturierung
    • Bis 31.12.18 fakturiert der Mitarbeiter durch Consulting mind. 800 Stunden.
  • Zertifizierung

Ideen für das Format des NOSSUED 2018 gesucht

Vom 16-17. Juni 2018 findet wieder der NOSSUED in Karlsruhe statt. Der Termin wurde vorgezogen, um den unterschiedlichen Sommerferien der einzelnen Bundesländer Rechnung zu tragen.

Wie jedes Jahr soll die Konferenz als Open Space ausgerichtet werden. Darüber hinaus suchen wir als Orga nach Ideen, um das Format zu erweitern und neue Anreize einfließen zu lassen.

Beispielsweise wäre ein Mix aus Charity Development, Hackathon und Open Space möglich. Dabei würde im Vorhhinein, z.B. über einen Austausch auf Facebook oder am Vorabend des NOSSUED, ein Projekt ausgewählt werden, welches Schulen oder Vereine einsetzen können. Eine webbasierte Mitgliederverwaltung samt deren Mitgliedsbeiträge für Sportvereine wäre so etwas. Im Anschluss würden wir uns darüber austauschen welche Technologien dazu eingesetzt und wir die Architektur aufgebaut werden sollen. Die Sessions des Open Spaces würde dann auf diese Themen ausgerichtet werden. Parallel findet in Gruppen ein Hackathon statt, bei dem das Produkt entwivckelt wird. Ergeben sich dabei Fragen, Diskussionen oder Schwierigkeiten, dann kann daraus eine neue Open Space Session generiert und spontan abgehalten werden.

Was sagt ihr zu diesem Ansatz? Habt ihr andere Ideen? Oder wollt ihr vielleicht am bisherigen Format gar nichts ändern? Schreibt mir in die Kommentare.

%d Bloggern gefällt das: