Eine Schichtenarchitektur ist ein Architekturstil, der häufig bei Software-Systemen Anwendung findet. Vielen Herstellern sind die Nachteile eine mehrschichtigen Architektur und eines Denkens in Layern nicht bewusst.
Schichtenarchitektur: Beispiele
Je nach Anwendungsfall zerlegen die Software-Architekten eine Software in verschiedene Schichten (Layer) z.B. in
- Interaktionsschicht
- Präsentationsschicht
- Service-Schicht
- Funktionsschicht
- Datenzugriffsschicht
- Datenhaltungsschicht
Diese Schichten kann man noch weiter unterteilen oder zusammenfassen, wie in der obigen Abbildung gezeigt.
Im Fall einer Hardware-nahen Entwicklung finden sich häufig Schichten wie
- Hardware-Abstraction-Layer
- Kommunikationsschicht
- UI-Schicht
These: Vorteile von Schichtenarchitekturen
Die Aufteilung einer Software-Architektur in Schichten bringt Vorteile mit sich:
- Die Schichten lassen sich unabhängig von einander entwickeln und testen (insbesondere „bottom-up“)
- Die Schichten lassen sich auf verschiedene Rechner verteilen und ermöglichen dadurch eine bessere Skalierung und damit Performance
- Die Schichten lassen sich bei Bedarf austauschen. Beispielsweise ist es möglich die UI (Darstellungsschicht) auszutauschen, ohne den Rest der Software ändern zu müssen.
- Die Schichten lassen sich als Komponenten im Sinne einer IEC 62304 interpretieren, so dass Hersteller damit die entsprechenden Forderungen der Norm erfüllen können.
Zudem können die Entwickler Regeln an die Schichtenarchitektur formulieren, beispielsweise dass immer nur ein Aufruf von oben nach unten erfolgen darf. Gegenfalls darf eine Schicht sogar nur die direkt folgende Schicht aufrufen. Das führt zu einer konzeptionellen Integrität der Software-Architektur.
Antithese: Probleme mit Schichtenarchitekturen
Eine Schichtenarchitektur (wie gefällt Ihnen der Begriff Lasagne-Architektur?) ist aber noch lange keine Best Practice und sicher kein Garant für eine wartbare und testbare Architektur.
Ich möchte sogar von dem ausschließlichen Denken in Schichten warnen.
- Zu ungenau und zu unspezifisch
Eine Architektur, die nur Schichten kennt, ist viel zu grobgranular. Manchmal sehe ich in Architekturdokumenten nur Darstellungen von Referenz-Architekturen (oft aus dem Web kopiert), die unspezifisch für das zu entwickelnde Produkt sind. - Fehlende Systematik
Wer in Schichten denkt, denkt nicht in Funktionen. Aber nur eine Denken in gekapselten Funktionalitäten führt zu schwachgekoppelten Komponenten. Nur so können Sie ein PEMS systematisch in PESS und andere Komponenten, die wiederum in Hardware und Software und die wiederum in Software-Komponenten und Software-Einheiten zerlegen. - Schlechte Architektur
Dies hat zur direkten Folge, dass Sie eine suboptimale System- bzw. Software-Architektur erstellen. Nur schwach gekoppelte Komponenten sind- wiederverwendbar (Problem für Produktfamilien),
- testbar (Problem für Qualität des Produkt),
- änderbar (ohne dass alles kollabiert. Problem für Wartungsgeschwindigkeit und Güte des Produkts)
- austauschbar (Problem für Wartbarkeit des Produkts),
- geeignet um die Ausbreitung von Risiken zu begrenzen (Problem für Sicherheit der Patienten und Anwender).
- Falsche Motivation: Organisation
Die Aufteilung von Systemen in die Schichten Mechanik, Elektronik und Software — auch eine Schichtenarchitektur — ist in vielen Firmen organisationsbedingt: Es gibt für jede Schicht eine entsprechende Abteilung. Sie sehen die Schichten z.B. in Form von Platinen förmlich. Wer aber alles auf einer Platine verbaut — um diese Metapher weiter zu nutzen — hat keine funktionalen Komponenten entworfen. Die Konsequenzen und Nachteile haben wir eben benannt.
Synthese
Die genannten Probleme sollen aber kein Argument gegen Schichtenarchitekturen sein. Lösen Sie den Widerspruch der genannten These und Antithese wie folgt auf:
- Alternative 1: Sie zerlegen innerhalb Ihrer Schichtenarchitektur die Schichten in funktionale Komponenten. Voraussetzung dafür ist, dass die einzelnen Schichten bereits konzeptionell einheitlich Aufgaben haben.
- Alternative 2: Sie zerlegen Ihr System erst funktional, und dann zerlegen Sie die identifizieren Komponenten in Schichten. Das entspricht übrigens dem gerade populären Architekturstil der Micro-Services.
Die IEC 62304 erlaubt beides. Sie ist schon glücklich, wenn überhaupt irgendwelche Komponenten und deren Schnittstellen beschrieben sind. Sic(!): Es genügt nicht, die Schichten bzw. Komponenten zu identifzieren. Es gilt die Schnittstellen derer zu beschreiben. Das gelingt bei Alternative 2 übrigens meist deutlich einfacher.
Sehr geehrter Herr Professor Johner,
Zu Ihrer Frage:
„…Lasagne-Architektur (wie gefällt Ihnen mein neuer Begriff?)“
Der Begriff gefällt mir sehr gut, u.a. weil sich nach dem aktuellen Pferdefleisch-Skandal „Lasagne“ immer auch mit „Etikettenschwindel“ in Verbindung bringen läßt…
Daher auch volle Zustimmung zur Betunung der Komponenten.
Grüße aus dem Osten Süddeutschlands
Werner Mo
Ich stimme dem Punkt zu, dass Schichtenarchitektur nicht zwingend zu einer guten Software Architektur führen muss. Allerdings finde ich den Ansatz als solchen nach wie vor gut, wenn er auch alt ist (das Rad ist auch alt, wird aber aus guten Gründen immer noch verwendet).
Man muss zwischen Makro- und Mikroarchitektur unterscheiden:
Wenn ich ein Softwaredesign mache, muss ich erstmal den groben Rahmen beschreiben: das wäre z.B. eine Schichtenarchitektur!
Damit ist man zwar lange noch nicht fertig aber wir haben eine Richtschnur und können innerhalb der Schichten Komponenten ausdeuten und Interfaces definieren. Innerhalb dieser Komponenten gilt es dann wieder eine Architektur zu finden auf internen Klassen und Interfaces. Je detaillierter man wird desto weniger kann man des Design zu Beginn eines Projektes beschreiben, da dann oft viele Punkte noch unklar sind. Mir sind übrigens keine Gesetzte bekannt, die Interaktion von Komponenten der unteren und oberen Schichten strikt verbieten.
Ein weiterer Aspekt ist der Mensch: Ich kenne kaum (oder besser keine) Entwickler, die Experten für WPF und SQL-Server sind. In der Schicktenarchitektur sind Aufgaben klar verteilt und Entwickler können relativ unabhänging in ihrer Domäne arbeiten.
Fazit:
Schichtenarchitektur ist nach wie vor gut (als eine von mehreren Möglichkeiten)!
Wenn man ohne Makroarchitektur ein Design macht fehlt die Richtschnur und es besteht die Gefahr, dass man am Ende keine funktionalen Gruppen hat sondern einen Haufen von Komponenten ohne Struktur.
Hallo,
ein sehr interessanter Beitrag und einhergehende Diskussion
Ich sehe in der Schichtenarchitektur sehr viel Potential.
Firmen sind in der Lage, Logik in Services (egal in welcher Granularität) zu definieren, und diese Services zu entwickeln. Sie brauchen sich nicht um die Programmierung der Ablaufumgebung zu kümmern. Hier kann man sich kommerzieller sowie Open Source Plattformen bedienen (RedHat,IBM Websphere, Apache), die sich von Haus aus um Themen wie Skalierung, Verfügbarkeit und Performance kümmern.
Durch eine saubere Definition von Webservice Schnittsellen kann ein Teil der (medical) Service Entwicklung outgesourced werden. Prozesse können auf Basis verschiedener ‚composite services‘ grafisch modelliert (orchestriert) werden.
Was mich interessieren würde ist folgendes: Kann man (medical) Services, die ‚IEC 62304 compliant‘ sind mit solchen, die es nicht sind, auf einer Plattform zusammen betreiben? Gibt es dazu Erfahrungen?
Viele Grüße
Thomas Weber
Fresenius Medical Care
Lieber Herr Weber,
danke für Ihre Analyse! Ich hoffe, dass ich nicht den Eindruck erweckt habe, gegen Schichtenarchitekturen zu sein. Ich wollte nur auf Fallen hinweisen.
Ein Arbeiten mit Webserivces ist auch ein schönes Beispiele, in dem man sich bewusst nicht für eine durchgängige Schichtenarchitektur entscheidet.
Sie können Services betreiben wie Sie wollen. Sie müssen nur darauf achten, wer sie sind: Sind Sie ein Betreiber? Dann liegt eine Eigenherstellung vor. Sind Sie ein Inverkehrbringer (Anbieter)? Dann beachten Sie, dass Sie keine halben Produkte in den Markt bringen können. Wenn Ihr Gesamt-Produkt einen „Medizinprodukte-Webservice“ nutzt, dann ist das Gesamtprodukt mit hoher Wahrscheinlichkeit auch ein Medizinprodukt.
Genau das sind die Erfahrungen, die es dazu gibt und nach denen Sie fragen.
Beste Grüße
Christian Johner