Category

Artikel

Machine Learning im Unternehmen – Nutzen und Potentiale

By | Artikel, Publikationen | No Comments
Machine Learning im Unternehmen – Nutzen und Potentiale

Informatik Aktuell Tests

Machine Learning im Unternehmen – Nutzen und Potentiale
Autor: Oliver Zeigermann
Informatik Aktuell, erschienen am 19. Dezember 2017
Artikel online lesen

Viele der großen Player im IT-Umfeld wie Apple, Google, Amazon setzen auf Machine Learning. Die meisten Unternehmen haben jedoch ein ganz anderes Geschäftsmodell als die IT-zentrierten Großunternehmen. Gibt es für Ihr Unternehmen ebenfalls Potentiale? Und wenn ja, wie könnten diese aussehen? Was genau Machine Learning ist und ob es einen Unterschied zu Künstlicher Intelligenz gibt, ist erstaunlich strittig. Auch wird immer wieder von unterschiedlichen Arten von Machine Learning gesprochen, häufig von „Supervised Learning“, „Unsupervised Learning“ und „Reinforcement Learning“.

Für seinem Artikel nimmt Oliver an, dass wir uns in dem Umfeld einer Versicherung bewegen. Mit seinen Beispielen erläutert er drei der wichtigsten Anwendungen des sogenannten „Supervised Learnings“. Eben jener Art des Machine Learnings, die Andrew Ng als vorherrschend bezeichnet. Ziel ist es, dass Sie hieraus eine Inspiration für Ihre eigenes Unternehmen oder ihr eigenes Projekt ziehen können.

zum Artikel

Artikel im Objektspektrum 01/2018: Wie Architektur agile Zusammenarbeit fördert oder behindert

By | Artikel, Publikationen | No Comments
Wie Architektur agile Zusammenarbeit fördert oder behindert – Die neue Schule der Softwarearchitektur

OBJEKTspektrum 01/2018

„Wie Architektur agile Zusammenarbeit fördert oder behindert“
Autor: Stefan Toth
Artikel im OBJEKTspektrum 01/2018, 4 Seiten, ab Seite 80
erschienen am 15. Dezember 2017

In der heutigen Architekturpraxis sind unterschiedliche Denkschulen und Hintergründe anzutreffen. Vertreter der klassischen Architektursicht gehen dabei drastisch anders mit Architekturproblemen um, als es Vertreter der neuen Schule machen, die in Start-ups und „IT First“-Unternehmen anzutreffen sind. Dieser Artikel stellt die Sichtweisen, Konzepte, technischen und organisatorischen Prinzipien der beiden Schulen gegeneinander, diskutiert die Auswirkungen des Umdenkens sowie die wichtigsten Vorteile.

Digitale Ausgabe Objektspektrum

 
follow us on Twitter – @embarced

Experten-Check auf JAXenter: Was ist schöner Code?

By | Artikel, Publikationen | No Comments
„Was ist guter Code für Software-Architekten?“ (Teil 1 der Themenserie)

JAXenter Logo

Teil 1: Was ist guter Code für Software-Architekten?
Autoren: Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen
Architektur (Teil 1) auf JAXenter
erschienen am 12. September 2016

In dem JAXenter Themen-Schwerpunkt “Schöner Coden” werden die Fragen aufgeworfen: Was ist eigentlich schöner Code? Welche Eigenschaften hat schöner Code aus Sicht eines Software-Architekten? Und umgekehrt: Was macht schlechten Code aus? Hilft ein bestimmtes Tool oder Framework dabei, schöneren Code zu schreiben? Im ersten Teil des Experten-Check beantworten Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen diese Fragen und lassen ihre Erfahrungen einfliessen. (…mehr)

„Was macht die Schönheit von gutem Code für Web-Experten aus?“ (Teil 4 der Themenserie)

JAXenter Logo

Teil 4: Was macht die Schönheit von gutem Code für Web-Experten aus?
Autoren: Niko Köbler, Karsten Sitterberg und Oliver Zeigermann
Web (Teil 4) auf JAXenter
erschienen am 19. September 2016

Was ist schöner Code für Web-Experten? Was hilft technisch um schöneren Code zu schreiben? Im vierten Teil des Experten-Check stehen Niko Köbler, Karsten Sitterberg und Oliver Zeigermann Frage und Antwort und erläutern wie wichtig Lesbarkeit und Code-Reviews für sie sind und bei welchen Fehlern sich den Experten im wahrsten Sinne „die Fußnägel hochrollen“. (…mehr)

In der Reihe „Experten-Check: Was ist schöner Code?“ sind die folgenden fünf Artikel auf JAXenter erschienen:

Teil 1: Schöner Code aus Sicht von Software-Architekten (mehr)
Teil 2: Was macht schönen Code für Tester aus? (mehr)
Teil 3: Was ist schöner Code für Mobile und UI-Experten? (mehr)
Teil 4: Was ist schöner Code für Web-Experten? (mehr)
Lesetipps von den JAXenter-Experten: Nach dieser Lektüre schreibst Du schönen Code (mehr)

Artikel im Java Magazin 09/2016: Bring your own Architecture. Softwarearchitektur wird Entwickler-Skill

By | Artikel, Publikationen | No Comments
Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill

Java Magazin 09/2016

Bring your own Architecture — Softwarearchitektur wird Entwickler-Skill
Autor: Stefan Zörner
Artikel im Java Magazin 09/2016, 5 Seiten, Seite 32-36
erschienen am 1. August 2016

Softwarearchitektur beschäftigt sich mit weitreichenden Entscheidungen, die später schwer zurückzunehmen sind. Aktuell liegen hingegen Microservices im Trend, die Applikationen in kleinere Einheiten mit eigenem Entwicklungsteam und individuellem Technologie-Stack aufbrechen. So klein, dass es billiger ist, sie bei Bedarf neu zu bauen. Wenn wir uns falsch entscheiden werfen wir sie einfach weg. Verliert Softwarearchitektur in einem solchen Szenario an Relevanz?

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Artikel im Java Magazin 09/2016: Evolution statt Diktatur. Langlebige Softwarearchitektur und Qualitätsansprüche

By | Artikel, Publikationen | No Comments
Evolution statt Diktatur — Langlebige Softwarearchitektur und Qualitätsansprüche

Java Magazin 09/2016

Evolution statt Diktatur — Langlebige Softwarearchitektur und Qualitätsansprüche
Autor: Stefan Toth
Artikel im Java Magazin 09/2016, 4 Seiten, Seite 38-41
erschienen am 1. August 2016

Wie entstehen gute Software-Systeme? Moderne, State-of-the-Art Lösungen die nicht in 3-5 Jahren einem Ablösungsprojekt zum Opfer fallen. Lösungen die ihre Nutzer begeistern. Antwortmöglichkeit 1: Durch die Arbeit eines einzelnen, genialen Meisters, der alle Einflüsse austariert und einen detaillierten Entwurf der Wahrheit erstellt an den sich alle halten. Antwortmöglichkeit 2: Durch die Nutzung individueller Kompetenzen, um einen lediglich groben Rahmen auszugestalten und kontinuierlich weiterzuentwickeln. Ich bin ein Freund der zweiten Antwort. In diesem Artikel beschreibe ich warum das so ist, wie Freiheit in der Softwareentwicklung weder zu Anarchie noch Chaos führt und wie evolutionäre Architekturen die (Software-)Welt verändern.

weitere Infos zum Heft

 
follow us on Twitter – @embarced

Tests erst in Produktion? Lernen von Microservices

By | Artikel, Publikationen | No Comments
Tests erst in Produktion? – Was wir von Tests bei Microservices lernen können (Artikel auf Informatik Aktuell)

Informatik Aktuell Tests

Tests erst in Produktion? – Was wir von Tests bei Microservices lernen können
Autor: Harm Gnoyke
erschienen am 26. April 2016: online lesen

Microservices sind der meistdiskutierte Architekturstil der letzten Jahre. Für die erhöhte Reaktionsgeschwindigkeit auf Veränderungen zahlen Sie jedoch den Preis einer komplexer zu entwickelnden und zu betreibenden Applikation. Schnell stellt sich die Frage, wie diese Komplexität beim Testen der Anwendung beherrscht wird. Nach ehrlichen Antworten gefragt, räumen viele Projekte ein Defizit bei diesem Thema ein – unabhängig vom gewählten Architekturstil. Wieso werden diese Stimmen rund um Microservices nicht lauter? Was machen die Teams anders, die diese komplexen verteilten Anwendungen entwickeln und betreiben?

zum Artikel

Abheften mit arc42 für Fortgeschrittene. Konzept oder Entscheidung?

By | Artikel, Inhaltliches, Publikationen | No Comments

arc42 ist als Gliederung für Architekturbeschreibungen von Softwaresystemen weit verbreitet, zumindest in D-A-CH. Entsprechend treffe ich häufig auf Projekte, die arc42 benutzen oder beabsichtigen dies zu tun. Im Praxiseinsatz erlebe ich typische Fragestellungen und die immer gleichen Stolperfallen. In diesem Beitrag beschreibe ich kurz, wie ich in Projekten mit einer besonders häufigen Unsicherheit umgehe.

arc42_TOC

8. oder 9. ?

arc42 ist zuallererst eine Strukturierungshilfe. Es weist Inhalten Ihrer Dokumentation einen Ort zu, wo Sie diese „abheften“. Viele Projekte tun sich schwer, bei einem Lösungsansatz zu entscheiden, ob er besser in Abschnitt 8 („Konzepte“) oder 9 („Entwurfsentscheidungen“) passt. Oder in beide? Die Abbildung rechts zeigt die Struktur von arc42 als Inhaltsverzeichnis.

Schnipsel statt Kapitel

Generell rate ich davon ab, arc42 als Dokument (z.B. in Word) auszufüllen. Sie fahren besser damit, Zutaten Ihrer Dokumentation einzeln anzufertigen und sie später zielgruppengerecht in unterschiedlichen Formen zu rekombinieren. Entsprechend spreche ich im Folgenden nicht davon, wo Sie etwas „eintragen“ oder „reinschreiben“ in arc42, sondern wo so eine Zutat oder auch ein Schnipsel (z.B. eine Architekturentscheidung oder ein Konzept) ihren Platz findet.

Für die Einordnung von Entscheidungen, Konzepten sowie für die meiner Meinung nach eng verknüpfte Lösungsstrategie hilft die folgende Tabelle weiter. Ich führe die Inhalte im Folgenden weiter aus.

path-selection-3 document-with-paper-clip-2 american-football-strategy-4
arc42-Abschnitt 9. Entscheidungen 8. Konzepte 4. Lösungsstrategie
Anzahl pro System mehrere, eine pro wichtiger Fragestellung mehrere, eins pro wichtigem Thema eine verdichtete Übersicht, z.B. als Tabelle
Zielsetzung Nachvollziehbarkeit einer Entscheidung breite Kommunikation eines Lösungsansatzes Brückenschlag von Architekturtreibern zu Lösungsansätzen
Leitfrage Warum haben wir uns so entschieden? Wie gehen wir mit dem Thema um? Wie sieht die Lösung grundsätzlich aus?
Typische Form Prosa, stets gleich strukturiert, knapp, häufig mit Kreuztabelle, Prosa, ergänzt mit Abbildungen und (Quelltext-)Beispielen Tabelle (Spalten: Ziel, Ansätze), ggf. ergänzt mit einem Überblicksbild

Entscheidungen

Eoin Woods versteht Softwarearchitektur recht dramatisch als Summe der Entscheidungen, die — wenn falsch getroffen — Ihr Projekt scheitern lassen können. Diese Architekturentscheidungen ändern Sie im weiteren Verlauf nur schwer (oder es wird zumindest teuer); sie wirken breit.

EntscheidungBei Architekturdokumentation geht es vor allem darum solche  Entscheidungen nachvollziehbar festzuhalten. Im Nachhinein ist das schwieriger als beim Entscheiden. Deshalb nutze ich die gleichen Werkzeuge zum Treffen und zum Festhalten der Entscheidung — die Dokumentation fällt dann quasi ab.

Zum Festhalten einer Entscheidung gehören für mich zumindest eine konkrete Fragestellung (z.B. eine Technologie-Auswahl,  Make-Or-Buy …), betrachtete Alternativen und Bewertungskriterien. Kreuztabellen helfen dabei, Argumente verdichtet darzustellen.

Pro Entscheidung fertigen Sie ein einzelnes schlankes Dokument an oder eine einzelne Wiki-Seite oder ein … (das ist jetzt eine Toolfrage). Jede Entscheidung strukturieren Sie dabei gleich. Meine Empfehlung dazu in Kurzform: Fragestellung, Einflussfaktoren, Annahmen, Alternativen, Entscheidung. Am Ende dieses Beitrags finden Sie weiterführende Links dazu, Beispiele inklusive.

Konzepte

Entscheidungen treffen Sie und Ihr Team, um unter gegebenen Rahmenbedingungen Ziele zu
erreichen. Auch Konzepte verfolgen Ziele und sind Teil Ihrer (Architektur-)Lösung. Dieser Umstand macht die Verwirrung aus, wo man was abheftet in arc42.

Konzept
Meine Auslegung: Während Entscheidungen eine Frage beantworten, diskutiert jedes Konzept ein Thema. arc42 schlägt im betreffenden Abschnitt 8 als Unterkapitel viele solcher Themen vor: Persistenz, Sicherheit, … Der zentrale Unterschied aus meiner Sicht: Während es bei den Entscheidungen vor allem um die Nachvollziehbarkeit geht („Warum haben wir uns so entschieden?“), kommunizieren Konzepte vor allem Dinge, die innerhalb Ihres Softwaresystems übergreifend gelöst sind („Wie gehen wir mit einem bestimmten Thema um?“).

Die Zielgruppe eines Konzeptes sind Team-Mitglieder, die das Konzept in ihren Systemteilen anwenden und/oder umsetzen. Entsprechend haben Konzepte idealerweise Tutorial-Charakter und sind mit Beispielen gespickt. Auch für Konzepte schlage ich gern eine an das 4-Quadranten-Modell angelehnte gleichförmige Struktur vor. Sie ist freier als bei Entscheidungen, und gliedert ein Konzept nur grob vier Teile (Warum? Was? Wie? Wohin noch?), nicht feste Kapitel.

Übrigens löst eine Architekturentscheidung gerne das Anfertigen eines Konzeptes aus. In der Entscheidung beschreiben Sie, warum Sie sich für einen Architekturstil oder eine Technologie entschieden haben (Beispiel: Einsatz von Microservices, Verwendung von AngularJS). In Konzepten beschreiben Sie dann Dinge, die übergreifend für alle Services sind, bzw. wie Sie das UI bauen (die Entscheidung für AngularJS lässt einigen Spielraum …)

Die Lösungsstrategie als Klammer

Ein oft vernachlässigtes Kapitel in arc42 ist Abschnitt 4 („Lösungsstrategie“). Ich nutze es gerne um die Brücke zu schlagen zwischen den architekturrelevanten Anforderungen auf der einen Seite (Abschnitte 1-3 in der arc42-Gliederung) und der Lösung auf der anderen.

Lösungsstrategie
Besonders explizit geht dies in einer Tabelle, in der Sie in einer Spalte die Architekturtreiber (z.B. Ihre Qualitätsziele) auflisten, und diesen in der rechten Spalte Lösungsansätze zuordnen. Diese Lösungsansätze können Architekturprinzipien sein, der zugrunde liegende Stil, verwendete Muster, Technologieentscheidungen, Konzepte … In der Tabelle nennen Sie diese nur, und verweisen auf die betreffenden Schnipsel. Die Lösungsstrategie zeigt auf, mit welchen Ansätzen Sie den Qualitätszielen begegnen, und motiviert die Architektur so bereits auf oberster Ebene.

Übrigens …

Das Problem mit dem Einordnen ist besonders gravierend wenn ein Projekt die Architektur nachdokumentiert, Zutaten also nachträglich anfertigt. Bei einem methodischen Vorgehen fallen die Schnipsel auf dem Weg ab und fügen sich nach und nach zu einer Architekturvision und später zu einem konsistenten Lösungsbild.

Zum Abschluss noch die versprochenen Links für Strukturierunsvorschläge, Beispiele inklusive. In meiner Blog-Serie arc42-Starschnitt finden Sie Beiträge zu allen drei genannten Abschnitten:

Die Leseprobe meines Buches zu Architekturdokumentation behandelt Architekturentscheidungen und die Lösungsstrategie ebenfalls, auch mit Beispielen („Kapitel 3: Entscheidungen treffen und festhalten“ als PDF hier herunter zu laden).

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern – Artikel im Business Technology Magazin

By | Artikel, Publikationen | No Comments

 

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern

Business Technology

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern oder behindern
Autor: Stefan Toth
Artikel im Business Technology Magazin 04/2015 erschienen am 20. November 2015

Online lesen auf JAXenter

Conways Überlegungen werden meist mit der Definition von Schnittstellen und der Systemstruktur in Verbindung gebracht. So versuchen z. B. manche Organisationen, lose Kopplung durch organisatorische Ferne zu fördern. In der momentanen Diskussion zu Systemarchitekturen nimmt Conway, fast fünfzig Jahre nach seiner Feststellung, wieder eine prominente Rolle ein. Wie schaffen es Firmen wie Spotify, Netflix oder Amazon, im Großen sehr effektiv zu arbeiten? Wie können dort hunderte Entwickler an einem Produkt arbeiten, ohne an Dynamik und Reaktionsvermögen einzubüßen? Für schnelle Reaktion auf Marktänderungen werden längst nicht nur Zusammenarbeitsmodelle und Kommunikationsstrategien entwickelt ‑ auch Architekturansätze werden als Teil der Gleichung erkannt. Dieser Artikel zeigt, was agile Softwareentwicklung uns über Teams und Zusammenarbeit lehrt und wie die technische Architektur hier helfen kann.

Online lesen

 
follow us on Twitter – @embarced

Artikel auf JAXenter – Softwarearchitektur in nicht perfekten Umfeldern

By | Artikel, Publikationen | No Comments

 

Softwarearchitektur in nicht perfekten Umfeldern: Agil, Lean oder einfach nur komplex?

JAXenter Logo

Softwarearchitektur in nicht perfekten Umfeldern: Agil, Lean oder einfach nur komplex?
Autor: Stefan Toth
Artikel im Java Magazin 12/2015 erschienen am 04. November 2015

Online lesen auf JAXenter

Viele methodische Entwicklungen der letzten fünfzehn Jahre kann man als Reaktion auf die komplexen Herausforderungen der heutigen Softwareentwicklung verstehen. Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und stetige Verbesserung in den Vordergrund, versucht Verschwendung zu elimieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwareentwicklung hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert und die Disziplin der Softwarearchitektur muss darauf regieren.

Online lesen

 
follow us on Twitter – @embarced

Artikel im Java Magazin 12/2015: Agil, Lean oder einfach nur komplex?

By | Artikel, Publikationen | No Comments

 

Agil, Lean oder einfach nur komplex?

Java Magazin 12/2015

Agil, Lean oder einfach nur komplex?
Autor: Stefan Toth
Artikel im Java Magazin 12/2015, 5 Seiten, ab S. 64
erschienen am 04. November 2015

Online lesen auf JAXenter

Projekte und Produktentwicklungen sind unterschiedlich. Fest steht jedoch: Nirgendwo findet man ein perfektes Umfeld mit ausreichend Geld, Zeit und fähigen Leuten, ohne störende Legacy-Lasten, fehlende Libraries oder böse Überraschungen. Selbst wenn viele dieser Parameter passen, ist Ihr Kunde oder Fachbereich vielleicht wankelmütig oder das Management wechselt während des Vorhabens die eigene Linie (falls es eine gibt). Moderne Softwareentwicklung ist komplex und wenig schablonenhaft. Zeitgemäße Arbeit an der Softwarearchitektur muss deshalb Reaktionsfähigkeit stärken, fokussieren und sich davon verabschieden, dass alles vorab plan- und analysierbar ist.

Agile Vorgehensmodelle versuchen mit Unsicherheit zu leben, Flexibilität im Vorgehen zu ermöglichen und Zusammenarbeit zu stärken. Die richtige Reaktion ist wichtiger als der richtige Plan. Lean stellt das Lernen und die stetige Verbesserung in den Vordergrund, versucht Verschwendung zu eliminieren und unser Vorgehen auf wichtige Aspekte zu fokussieren. Der Trend geht weit über die Softwarearchitektur hinaus, und selbst wenn Sie den Begriff „Agil“ oder den (abflachenden) Hype darum nicht mögen – es hat sich etwas im Projektalltag verändert und die Disziplin der Softwarearchitektur muss darauf reagieren…

weitere Infos zum Heft

 
follow us on Twitter – @embarced