Schneller zur besseren Webseite mit einer Business Analyse

Für unseren größten Kunden die heco gmbh haben wir eine Business Analyse durchgeführt, um vor der anstehenden Neuentwicklung die richtigen Entscheidungen treffen zu können. Wie wichtig die Informationen über Markt, Mitbewerber, Anwender und Kunden sind und welche Schlussfolgerungen sich daraus ziehen lassen, zeige ich in diesem Video:

Während dies bei „normalen“ (im Sinne von offline bzw. intern) Software-Projekten schon eher Usus ist, kann man davon bei Web-Projekten  noch lange nicht sprechen. Meiner Erfahrung nach spielen hier Aussehen und „etwas auf die Leinwand bringen“ die erste Geige. Eine schier riesige Zahl an Feature-Wünschen, die man auf anderen Seiten gesehen hat, lässt die Stakeholder träumen.
 

Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht noch immer geschwinder, als jener, der ohne Ziel umherirrt. – Lessing

 

Aus unserer Sicht ist es elementar sich die Zeit zu nehmen, um sich als Dienstleister in die Domäne des Kunden einzuarbeiten. Denn viele hoch priorisierte Wünsche sind eher nice-to-have Anforderungen. Oder schlimmer: Das „Warum“ ist gar nicht geklärt und das Produkt bzw. die Webseite wird am eigentlichen Zweck vorbei entwickelt. Da wird dann auch mal der Wunsch nach einem News-System laut, obwohl im Jahr nur 1-2 Neuigkeiten auf der Webseite eingepflegt werden sollen. Dabei wäre es unter Umständen geradezu eine Revolution in der Branche, würde man im Gegensatz zu den Mitbewerbern Echtzeitbestände und -preise auf der Webseite anbieten.

Um richtig priorisieren und die Technologie auswählen zu können, ist deshalb ein solides Know How der Domäne des Kunden notwendig, denn sonst verbaut man sich schnell Möglichkeiten, die dann teuer und langwierig umgebaut werden müssen. Setze ich beispielsweise auf SignalR, so kann ich jedem Besucher, der ein bestimmtes Produkt geöffnet hat, Änderungen am Bestand aktiv mitteilen. Auf der anderen Seite muss ich mir nicht unnötig Komplexität ins Projekt holen, wenn der Bestand von vor 2 Stunden völlig ausreichend ist. Oder wenn der Besucher gar nicht in der Lage ist bestimmt Funktionen zu bedienen (ja, das gibt es durchaus => kenne deine Anwender).

Viel Spaß mit dem Video, auch wenn es etwas lang wurde. Daran merkt man aber schon wie weitreichend das Thema ist. Schreibt mir in die Kommentare, ob ihr auch schon zu solchen Projekten gestoßen seid, bei denen das fehlende Domänenwissen zu Entwicklungsproblemen führte.

Werbung

Wie fachlich klare Konzepte technische Probleme lösen

Nachdem ich im vorherigen Beitrag Beispiele zur Abgrenzung des fachlichen Konzepts Kunde gegeben habe, möchte ich in dem folgenden Video erklären, wie die Fachabteilung zu guter Software beitragen kann. Denn wenn fachliche Konzept klar abgegrenzt werden, fallen viele technische Probleme automatisch weg.

Der Klick aufs Bild führt zu dem Video in meinem YouTube Channel. Unten auf dem Zahnrad könnt ihr die Auflösung hochsetzen.

Video mit der Erklärung für die Fachabteilung woher die technischen Probleme bei der Vermengungen von fachlichen Konzepten kommen.

Das Konzept Kunde gibt es nicht

Die Entwickler müssen genau hinhören, was mit manchen Begriffen gemeint ist. (Quelle: Fotolia)

Im vorherigen Artikel habe ich erläutert, wie der Domänenbegriff Kunde in unterschiedlichen Bedeutungen verwendet wird. In diesem Post mache ich einige Vorschläge, welche zeigen, wie es sich besser machen lässt.

Der Kunde im Verkauf ist die Person, die meine Produkte kauft. Er ist also der Käufer.

Im Support ist der Kunde derjenige, der meine Produkte bedient und sich bei Fragen zur Bedienung an den Support wendet. Da könnten vielleicht Anwender oder Nutzer als Begriffe in Frage kommen.

Im Rechnungswesen ist der Kunde derjenige, der mir Geld für meine Produkte schuldet und die Schuld dann hoffentlich begleicht. Schuld => Debit => Debitor. Oder alternativ Kontoinhaber. Das wiederum könnte aber zur Verwechslung mit den Lieferanten führen, die natürlich auch Kontoinhaber sind. Also nehmen wir besser Debitor.

Im Versand oder im Lager geht es darum die Produkte an einen Empfänger auszuliefern. Wir benötigen die Adresse, um das Paket, das die Ware erhält, zu adressieren. Also Empfänger, Adressat, Warenempfänger – man hat die freie Auswahl.

Das Marketing hat unter anderem die Ziele, die Neukundenakquise mit Werbemaßnahmen anzukurbeln, gleichzeitig aber die Kundenbindung zu festigen. Also wie wäre es mit Neukunde und Bestandskunde. Alternativ potentieller Kunde oder – für manche Branchen denkbar – Kandidat.

Fazit

Es muss nicht immer schwer sein gute Domänenbegriffe zu finden, die klar ausdrücken, worum es sich bei dem Konzept handelt. Oftmals genügt es sich die Domäne, in der der Begriff verwendet wird, anzuschauen und zu umschreiben, was der Begriff ausdrücken soll. Mit der Erfahrung wird das für den Fachexperten ganz selbstverständlich und ihm springen förmlich schlechte Benennungen ins Gesicht (schon mal über das Konzept der ‚Benutzer‘ nachgedacht?).

In meinem nächsten Artikel kommen wir zu der spannenden Frage, woher die technischen Probleme bei Vermengungen von Bedeutungen kommen.

Was meint die Fachabteilung eigentlich, wenn Sie von Kunden spricht?

Jede Fachabteilung spricht von dem sogenannten Kunden (Quelle: Fotolia)

Heute war ein Meeting mit dem Rechnungswesen. Sie wollen eine Änderung, um einfacher die Kontodaten unserer Kunden ändern zu können. Letzte Woche sollte unser Kampagnen-Tool fürs Marketing dahingehend erweitert werden, dass sich detaillierter Informationen zu den Kunden sammeln lassen. Und nächste Woche, so wurde mir gesagt, soll ich mit dem Verkauf sprechen, um in den Gutschriften für Kunden einen Passus zu ergänzen.

Ups, was ist da los? Alle Welt spricht von dem ‚Kunde‘. Aber ist dabei immer der gleiche Kunde gemeint? Also natürlich ist es dieselbe Firma bzw. Person, aber ist auch das gleiche Konzept gemeint? Oder anders gefragt: Würde das Rechnungswesen Informationen über die Kundenbeziehungen ändern oder würde der Versand Änderungen an Gutschriften durchführen? Wohl eher nicht. Benötigt denn der Kundenservice in seiner Oberfläche Informationen wie die Bankverbindung oder muss das Rechnungswesen die abonnierten Mailinglisten des Kunden sehen können? Ups, da war es wieder: Der Kunde.

Mit diesem Artikel soll der Einstieg in eine kleine Serie gemacht werden, in der ich erkläre, warum sich viele Probleme mit der Anwendung bereits dadurch vermeiden lassen, dass die Fachabteilung bei Domänenbegriffen respektive -konzepten genauer abgrenzt und explizit macht, was sie meint.

Beispielsweise wirkt sich das, auch wenn es der Anwender nicht glauben mag, stark auf die Geschwindigkeit und die Skalierbarkeit des Programms aus. Gleichfalls ist die Erweiterbarkeit und die Entwicklungsgeschwindigkeit davon betroffen. Oder die Usability. Genauso die Sicherheit und die Fehleranfälligkeit. Ganz schön viel, was die nicht differenzierte Betrachtung eines Kunden ausmachen kann oder?

Im nächsten Teil erläutere ich Beispiele, die zeigen: Hey, das ist gar nicht so schwer eine klare Unterscheidung zu machen.

Bessere Enumerations in NET

Ist euch der Smell von typischen Enumerations auch schon in die Nase gestiegen? In diesem Webcast zeige ich eine Alternative zu den typischen Enums in NET. Damit können das Open Closed Principle und Separation of Concerns besser umgesetzt werden, was meiner Meinung nach zu einer höheren Kohäsion führt.

 

Weiterführende Links:

• Blogbeitrag von Jimmy Bogard (Hier gibt es den Code der EnumerationBase)
• Video von Jimmy Bogard (Das Enum Beispiel kommt bei 44.45min)
• Strategy Pattern mit IoC

 

Wie haltet ihr es mit Enums? Arbeitet ihr schon auf diese Weise? Wollt ihr mehr Webcasts zu Clean Code?

Clean Code Series – Episode 1

Hier der Blogeintrag zu dem entsprechenden Video. Es geht um ein Frage eines Bekannten, der SAP Lösungen entwickelt und der von mir Vorschläge für einen Ansatz einer Problemdomäne aus seiner Praxis haben wollte.

Hier die Modalitäten:

Ausgangssituation:

· Wir haben eine Entität, beispielsweise eine Liste von Aktivitäten

· Diese Entität filtert abhängig vom angemeldeten User einige Aktivitäten und liefert den Rest an den Aufrufer zurück

· Der Filtermechanismus und die eigentliche Liste sind auf zwei Klassen aufgeteilt, die beide dasselbe Interface implementieren

· Beide Klassen hängen nur in Form einer Aufrufhierarchie voneinander ab und sind in Reihe geschaltet (Decorator)

· Der Filtermechanismus hat Abhängigkeiten zu einer Datenbankzugriffsklasse

Das schreit ja förmlich nach IoC: Zusammenbauen einer Aufrufhierarchie über Decorator, dazu ggf. weitere Abhängigkeiten auflösen.

Schön. Aber leider ist es eine schlechte Idee, konkrete Entitäten über einen IoC Container zu erzeugen.

Was also tun? Factories bauen?

Ich denke nicht, wäre es nicht geschickter, auf die Klassen das Prototype-Pattern anzuwenden?

Der IoC erzeugt dann lediglich einen Prototypen, der von den Erzeugern konkreter Arbeitslisten als Vorlage genutzt würde. Instanziierung dann folglich über prototype->clone( ).

Was denkst du?

Meine Antwort:

Für mich ist der Ansatz nicht gut modelliert. Könnt ihr das nicht in einer Klasse abbilden? Aus Sicht des Domain Driven Designs könnte man das vielleicht so implementieren:

Ihr habt eine Klasse Activities, welcher ihr beim Erzeugen die Liste alle möglichen Activities übergeben müsst. Im Konstruktor könnt ihr nach Belieben noch eine Validierung vornehmen, z.B. ob die Liste überhaupt Elemente enthält bzw. nicht null ist.

Die Gesamtmenge speichert ihr in einer privaten Variablen. Zusätzlich legt ihr ein readonly Feld für den Zugriff von außen an. Danach benötigt die Klasse nur noch Filtermöglichkeiten. In .NET würde man nur eine Methode schreiben, nämlich ApplyFilter und übergibt an diese einen Lambda Ausdruck. […] Übrigens: Wie du intern die Datenhaltung betreibst, ist dir überlassen. Ich habe es beispielsweise mit einer Liste gemacht, die wesentlich spezieller ist als Enumerable. Da könntest du sogar den Spaß in eine Textdatei wegspeichern und bei Aufruf immer wieder auslesen. Hier ist die klare Datenkapselung eingehalten. Nach außen hin sieht man eine Veröffentlichung auf Basis der sehr generischen IEnumerable Implementierung, intern verwende ich etwas sehr Spezielles.

Nach kurzer Diskussion, was ABAP hier an Möglichkeiten bietet, habe ich folgenden Vorschlag gemacht:

Clean Code Series–Episode 1

Was meint ihr?

Session Berichte–Teil 2

Kurzer Zwischenbericht zu drei hammergeilen Sessions!

 

Domain Driven Design + CQRS => Eventual Consistency:

Hier wurden mir quasi die Augen geöffnet. Das kann ich am besten so beschreiben: Wenn jemand nur das Reisen mit dem Auto kennt, dann staunt er nicht schlecht, wenn ihm das Fliegen gezeigt wird. Natürlich wird von da an jetzt nicht jede Strecke geflogen, das wäre für kurze Strecken weder sinnvoll, noch rentabel. Aber für weite Distanzen ist das eine ganz neue Welt. Nachdem Dennis gestern in seinem Workshop bereits darauf hindeutete, dass DDD konsequent zu Ende gedacht  zu CQRS führt, konnte heute der Hintergrund und Rahmen durch diverse Praxisexperten geklärt werden. Als ERP-Developer würde ich Stand heute auf einem Greenfield definitiv einen großen Bereich mit diesen Ansätzen zu lösen versuchen.

Direkt im Anschluss fand Eventual Consistency statt, getrieben von den gleichen Hostern wie aus eben genannter Session. Demzufolge schließt sich folgende Aussage direkt an: Für DDD + CQRS wird ein Umdenken notwendig. Beispielsweise muss man sich von der Denke verabschieden, dass immer irgendwo in der Datenbank ein aktueller Objektzustand in Form eines Datensatzes liegt. Beispielsweise der aktuelle Kontostand von Person xy. Das ist einfach nicht mehr der Fall. Gleiches gilt für eine “aktuelle” Anzeige, was de facto, wie es auch schon der CIO von Amazon erläutert hat, nichts existiert. Bei korrekter Domänenbetrachtung ist das auch in de wenigsten Fällen nötig. Die Vorteile überwiegen imho immens einige wenige, bei näherer Betrachtung vernachlässigbar Unschönheiten. Da fällt beispielsweise der OR-Mapper in vielen Fällen einfach weg, da das Lesen von Daten sich auf eine einzig Form von Abfrage beschränkt. Das Testen ist wesentlich spezifischer und einfacher; immer verhaltensgetrieben!

 

WIX:

Bei uns ist es bereits seit Jahren ein Krampf zu einem vernünftigen, automatisierten Setup zu kommen. Unsere Anforderungen sind klar: Ein durch den Buildserver TeamCity dynamisch erzeugtes Installpaket, welches auf die Clients ohne Admin-Rechte verteilt werden kann. Hinzu kommt die Einschränkung, dass wir VB6-COM-Komponenten dabei registrieren müssen. Leider gibt es auf dem Gebiet nur wenige Experten und noch weniger aktuelle Literatur. Dank Sebastian Seidel konnte ich nun einen Einblick gewinnen. Da er auch Consultant auf dem Gebiet ist, steht hier noch die Make-it or Buy-it Evaluierung noch aus, die vermutlich zu Gunsten von Sebastian ausfallen wird.

Workshop Domain Driven Design

Heute Vormittag hatte ich das ausgesprochene Vergnügen dem Workshop von Dennis Traub beizuwohnen.  Für mich persönlich immer wieder ein Klassiker und das aus gutem Grund: Egal mit welcher Sprache und auf welcher Plattform man entwickelt, die Domänensprache ist omnipotent. Wer hier nicht mitreden kann, disqualifiziert sich schon fast als ernstzunehmender Entwickler.

Nichtsdestotrotz handelt es sich um einen sehr umfassenden, teils komplexen Ansatz, dessen vorgeschlagenen Praktiken immer wieder an konkreten Fallbeispielen geübt und ggf. im Kontext von diversen Prinzipien (SRP, DRY, etc.) evaluiert werden müssen. So verwundert es auch nicht, dass Dennis mehrfach darauf hinwies, dass es mehrere Lösungen geben kann, je nachdem wie die Context Boundaries definiert sind.

Besonders gefallen hat mir der Austausch mit den anwesenden Entwicklern. Selbst vermeintlich eingefleischte Theoretiker konnten hier sicher etwas mitnehmen. Und sei es nur, dass bei einer deutschen Fachdomänensprache der entsprechende Code ebenfalls in Deutsch sein sollte! Gefüttert wurden die Diskussionen mit einfachen User Stories, die betont unspezifisch respektive fachlich fragwürdig gehalten wurden. Ganz so, wie es in der täglichen Arbeit mit dem vermeintlichen Domänen-Experte auch der Fall ist. In kleinen Gruppen wurden diese zunächst gelöst, um dann in der Runde die Ergebnisse zu konsolidieren.

Zusammenfassend ein sehr lohnenswerter Workshop, in dem ich einige Punkte mitnehmen konnte. So zum Beispiel die interessante Aussage: DDD konsequent weitergedacht führt zu CQRS. Vor allem bin ich auf die anhängende Diskussionen bzgl. dreier Artikel gespannt, welche ich dem Präsentator zur Verfügung gestellt habe. Wem ich diese später zukommen lassen soll, der kann mich gerne kontaktieren.

		Workshop Domain Driven Design DIASHOW ANZEIGEN ALLE HERUNTERLADEN