Der Workshop stellt den gesamten Prozess der Architekturdefinition einer Software auf Basis der LAMP-Plattform vor: von der Ermittlung der Architekturanforderungen bis zur Evaluation bestehender Lösungen. Zunächst wird gezeigt, wie Architekturziele und -qualitäten für eine Software definiert werden. Daraufhin werden die möglichen Architekturstile wie u. a. N-Tier-Architekturen, SOA, Komponentenmodelle, Event- und Messaging-Architekturen vorgestellt. Es wird gezeigt, wie man Architekturen anhand dieser Anforderungen bewertet. Auf dieser Basis werden drei Anforderungsszenarien skizziert, für die in Gruppenarbeit Lösungsarchitekturen erstellt werden. Diese werden in der großen Gruppe vorgestellt und diskutiert.
1. SOFTWARE ARCHITEKTUR
VS
PHP
Workshop IPC Frühjahr 2010
in Berlin (in Berlin!)
Sonntag, 30. Mai 2010
2. Sonntag, 30. Mai 2010
Foto von Bill Gates einfügen -
Hier haben wir einen Entrepreneur.
3. Sonntag, 30. Mai 2010
Foto von Steve Jobs einfügen -
Der vor zwei Wochen in der Aktienkapitalisierung von diesem Entrepreneur überholt wurde.
Entrepreneure gab es aber auch schon vorher.
4. Sonntag, 30. Mai 2010
Hier haben wir einen.
Das ist Gustav. Er ist der klassische jugendliche Entrepreneur - ähnlich Bill Gates, der schon
mit 17 das Unternehmen seiner Eltern übernahm.
5. Sonntag, 30. Mai 2010
Das ist das elterliche Unternehmen - Schweden.
6. Sonntag, 30. Mai 2010
Schweden war damals im Schwerpunkt noch nicht auf Möbel spezialisiert, sondern auf
7. Agrar Seefahrt
20%
80%
Sonntag, 30. Mai 2010
... den Agrarbereich und die Seewirtschaft. Da Schweden nun mal zu den meisten Seiten
durch mehr oder zuviel Schnee begrenzt war dachte er sich als Wachstumsstrategie, nehmen
wir doch einfach mal mehr Produktionsmittel mit dazu.
8. http://www.flickr.com/photos/pdxdj/
Sonntag, 30. Mai 2010
Glücklicherweise war ein Konkurrenzunternehmen im Rahmen des dreissigjährigen Krieges
gerade etwas geschwächt worden, und daher wollte unser Entrepreneur deren Marktanteile
übernehmen.
9. Sonntag, 30. Mai 2010
Ausserdem, wenn schon sonst jeder Krieg führt, warum sollte man nicht mitmachen. Aber:
Krieg ist ziemlich Resourcenhungrig, konkret für die Human Resources Abteilung.
12. Wikimedia
Sonntag, 30. Mai 2010
Das war seiner Superwaffe: Ein Schiffe, dass sehr viel Dekoration hatte, drei Masten, 69 Meter
lang, 12 Meter breit und 52 Meter hoch - und - das war neu - zwei Kanonendecks.
20. Sonntag, 30. Mai 2010
Fazit: Das Schiff war zwar sehr beeindruckend, und hätte den Gegner mit Sicherheit
eingeschüchtert, wenn es jemals aus dem Hafen herausgekommen wäre - das ist es aber
nicht, sondern bereits nach wenigen Minuten auf der Jungfernfahrt noch im Hafen gesunken.
21. ?
Sonntag, 30. Mai 2010
Warum erzähl ich das ganze?
Weil hier jemand zwei Konkurrierende Architekturmerkmale hatte - solide Bauart mit einem
Deck vs. eindrucksvolle Erscheinung. Da sich das Management - sprich vorhin genannter
Entrepreneur - aber für eindrucksvolle Erscheinung entschieden hat, musste es kommen wie
es gekommen ist.
22. JOHANN-PETER
HARTMANN
Sonntag, 30. Mai 2010
Das bin ich, willkommen zum Workshop!
23. PHP-
DEVELOPER
Aber auch ein paar andere
Sprachen im Koffer.
Sonntag, 30. Mai 2010
24. Seit 3.0.4 :-)
PHP-
DEVELOPER
Aber auch ein paar andere
Sprachen im Koffer.
Sonntag, 30. Mai 2010
27. Sonntag, 30. Mai 2010
Ausserdem bin ich der CEO von SektionEins.
Ich nehm das mal als Anlass, einfach zu Duzen - ist das in Ordnung?
oder ist hier eher „DU sagst immer noch SIE zu mir...“ angesagt?
28. Gründer und CEO
Sonntag, 30. Mai 2010
Ausserdem bin ich der CEO von SektionEins.
Ich nehm das mal als Anlass, einfach zu Duzen - ist das in Ordnung?
oder ist hier eher „DU sagst immer noch SIE zu mir...“ angesagt?
29. Sonntag, 30. Mai 2010
Bei Mayflower machen wir Software für Firmen wie EON
30. Sonntag, 30. Mai 2010
... das von Telefonica eingesetzt wird ...
37. Wer muss trotzdem irgendwie
die Architektur machen? :-)
Sonntag, 30. Mai 2010
Auch wenn es keinen echten Architekten gibt, ist Architektur häufig Bestandteil des Jobs.
38. Wer hat den European
Song Contest gesehen?
Sonntag, 30. Mai 2010
Wer hat den European Song Contest gesehen?
39. Wer hat mit abgestimmt?
Sonntag, 30. Mai 2010
Wissen Deine Eltern das? Sind sie besorgt?
40. ?
Sonntag, 30. Mai 2010
Ok, aber eigentlich wollen wir hier Softwarearchitektur machen.
Was ist Eure Definition von Softwarearchitektur?
41. Was erwartet Ihr vom Vortrag?
Sonntag, 30. Mai 2010
Ich erzählte tatsächlich was über:
Was ist Architektur, wie bewertet man die, wie sorgt man dafür, das man beim
architekturaudit nicht auseinandergenommen wird?
42. ARCHITEKTUR
Sonntag, 30. Mai 2010
Motivation: Ein Mayflower-Talk: Fix your architecture, bei dem alle gesagt haben: der ist ja
gar nicht über architektur.
43. The software architecture of a program or
computing system is the structure or structures
of the system, which comprise software
elements, the externally visible properties
of those elements, and the relationships among
them.
Sonntag, 30. Mai 2010
Schauen wir mal, was die Profis sagen.
*vorlesen* - Wie man sieht, komplizierte Satzstruktur, also haben wir es offensichtlich mit
einem ungeschickten Autor oder einer komplexen Materie zu tun.
44. Architecture is high-level design.
Sonntag, 30. Mai 2010
This is true enough, in the sense that a horse is a mammal, but the two are not
interchangeable.
45. Architecture is high-level design.
Sonntag, 30. Mai 2010
This is true enough, in the sense that a horse is a mammal, but the two are not
interchangeable.
46. Architecture is the overall structure of the
system.
Sonntag, 30. Mai 2010
Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.
47. Architecture is the overall structure of the
system.
Sonntag, 30. Mai 2010
Schön wärs - eine Architektur sind in der Regel aber nicht nur eine, sondern viele Strukturen.
48. Architecture is the structure of the components of
a program or system, their interrelationships, and
the principles and guidelines governing their
design and evolution over time.
Sonntag, 30. Mai 2010
Wer hat hier im Raum alles eine Architekturdokumentation?
49. Architecture is the structure of the components of
a program or system, their interrelationships, and
the principles and guidelines governing their
design and evolution over time.
Sonntag, 30. Mai 2010
Wer hat hier im Raum alles eine Architekturdokumentation?
50. The software architecture of a program or
computing system is the structure or structures
of the system, which comprise software
elements, the externally visible properties
of those elements, and the relationships among
them.
Sonntag, 30. Mai 2010
Also bleiben wir mal bei dieser Definition.
Sie ist aus „Software Architecture in Praxis Second Edition“, von Len Bass, Paul Clements oder
Rick Kazman. Bei den Jungs habe ich ziemlich viel gekupfert.
Wichtig ist: Architektur definiert die Elemente eines Systems, nicht Ihre Implementierung.
51. ARCHITEKTUR
!=
DESIGN
Sonntag, 30. Mai 2010
Was im inneren der Elemente ist, ist Design. MVC ist im Regelfall nicht nach aussen sichtbar -
und dementsprechend ein Design, keine Architektur.
52. http://www.flickr.com/photos/ryanhayes/
Sonntag, 30. Mai 2010
Schauen wir uns doch einfach ein paar Beispiele für Architekturstile, englisch Architecture
Patterns, an. Patterns sind keine globalen Architekturen, sondern Architekturmuster, von
denen meist mehrere in der gesamten Architektur vorkommen.
53. client - server
Sonntag, 30. Mai 2010
Durch Browser und Webserver nutzt praktisch jede Webanwendung unter anderem eine
Client-Server Struktur. Bei Mashups oder embedded Applications wie Facebook wird diese
Struktur durchbrochen.
54. Frontend and Backend
Sonntag, 30. Mai 2010
Bei Frontend/ Backend handelt es sich um eine Trennung zwischen dem, was interagiert, und
der Businesslogik. Durch SOA/REST-Architekturen erlebt diese Trennung gerade wieder einen
Hype.
Achtung: Frontend / Backend ist nicht mit Designs wie MVC zu verwechseln - weiss jemand
warum?
55. Three-tier model
Sonntag, 30. Mai 2010
Klassischerweise presentation layer, business logic,database - und damit auch eine
Grundstruktur von Webanwendungen mit Datenbankpersistenz. Key-Value-Datenbanken etc
führen hier zu 4-Tier-Architekturen.
56. Event Driven Architecture
Sonntag, 30. Mai 2010
Hat jemand eine Ahnung, wo Eventgetriebene Architekturen vor allem vorkommen?
Korrekt - in der GUI. Langsam schwappt dieses Architekturmuster aber auch in das Web -
weil es sehr gut skaliert und hohe Responsivität erlaubt.
57. Redundante Hardware
Sonntag, 30. Mai 2010
Eine einfach zu verstehende Architektur - meist mit automatischem Failover durch
Betriebssystem (Heartbeat), Netzwerk (Load Balancer) oder Applikation
58. Publish-Subscribe
Sonntag, 30. Mai 2010
Ich schicke eine Information irgendwo hin, und sie kann 0-n Empfänger haben. Viele
Message-Queues implementieren diese Architektur.
59. Sonntag, 30. Mai 2010
Ein konkretes Beispiel dafür ist node.js. Wer von den anwesenden hat schon damit zu tun
gehabt? Ein sehr Klasse spielzeug, wenn man dinge in Javascript machen möchte.
60. Implicit invocation
Sonntag, 30. Mai 2010
Die Technik hinter dem Observer-Designpattern: man registriert sich für ein Ereignis, und
wird aufgerufen, wenn dieses eintritt.
61. Sonntag, 30. Mai 2010
Das ganze wird auch Hollywood-Principle genannt- don‘t call us, we call you.
62. Monolithic application
Sonntag, 30. Mai 2010
Der Klassiker ist die monolithische Applikation. Damit fängt jeder einmal an, und es gab eine
dunkle Zeit, in der alle Applikationen so aussahen. Hier kümmert sich die Applikation um
Nutzerinterface, Speichern von Daten und hat keine externen Abhängigkeiten - kennt jemand
ein Beispiel?
Korrekt - Microsoft Office ;-)
64. Peer 2 Peer
Sonntag, 30. Mai 2010
Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify
65. Peer 2 Peer
Sonntag, 30. Mai 2010
Warez, Muzak, filesharing - aber auch NNTP (also Usenet), Skype oder Spotify
66. C.O.A.
Sonntag, 30. Mai 2010
Hier handelt es sich um Architekturen wie CORBA, Microsofts DCOM, OLE, XPCOM in Firefox
oder Java EE - einzelne Komponenten arbeiten für sich losgelöst und können von anderen
eingebunden werden.
67. Pipes and Filters
Sonntag, 30. Mai 2010
Eine Sonderform von Component Based Architectures sind Pipes und Filters - hier können
komponenten durch Ein/Ausgabe-Streams miteinander verbunden werden und das Ergebnis
der Vorgänger weiterverarbeiten können - wie etwa im Unix-System.
68. S.O.A.
Sonntag, 30. Mai 2010
Eine Spezialisierung von COA ist SOA - service oriented architecture, auch REST. Ursprünglich
um eine bessere Architektur von sehr grossen systemen zu erlauben, heute wird es auch
gerne gemacht, um Teile von Webapplikationen auch für andere Applikationen nutzbar zu
machen - etwa durch eine Webbasierte Schnittstelle.
69. Shared nothing
Sonntag, 30. Mai 2010
Einer der Gründe, warum PHP so populär ist - wenn ich nichts gemeinsam benutze, kann ich
einfach linear über Blech skalieren. Viel Infrastruktur hinter Google basiert auf dieser Idee.
70. Space based
Sonntag, 30. Mai 2010
Space based ist btw. sehr cool. da wirft man POJOs gegen einen Stapel worker und guckt
nach, was rauskommt.
71. Messaging/Queues
Sonntag, 30. Mai 2010
Asynchronous Workqueues: Synchronous work asynchronous. If you have time, why do it
now? ActiveMQ, RabbitMQ, Gearman for the cool internet startup.
Wie sieht das ganze in der Praxis aus?
72. Framework
Sonntag, 30. Mai 2010
Die Wahl des Frameworks ist eine Architekturentscheidung, die viele andere Architektur- und
Designentscheidungen vorweg nimmt.
74. Applikation
Datenbank
Sonntag, 30. Mai 2010
Eine klassische Two-Tier-Architektur, nimmt man den Browser mit dazu Tree-Tier.
75. Frontend
Backend
Datenbank
Sonntag, 30. Mai 2010
Weil es gerade modern ist, trennen wir Frontend und Backend -und lassen die über eine
definierte Schnittstelle miteinander reden - gute Gründe sind zB, wenn auch andere Dienste
auf unser Backend zugreifen sollen.
76. Frontend IPhone-App
Backend External Service
Datenbank
Sonntag, 30. Mai 2010
Wie zum Beispiel, zeitgemäß, eine Iphone App. (Frage: Wer ist Android? Wer ist Iphone?)
Aber nicht nur ich kann für andere Applikationen Services anbieten, ich kann auch fremde
Services einbinden. Das können Payment-Gateways sein, eine Maps-Variante als auch andere
interne services.
77. Frontend IPhone-App
Backend External Service
Indizierer
Datenbank
SuchIndex
Sonntag, 30. Mai 2010
Und weil mit der IPhone-App automatisch der massive Erfolg da ist, muss die Suche in einen
Solr ausgelagert werden. Weil ich PDF und Word-Files automatisch wandle, wird das ganze
asynchron über einen Indizierer gemacht, der den Solr-Topf füllt, der dann synchron
abgefragt wird.
78. ?
Frontend IPhone-App
Backend External Service
Indizierer
Datenbank
SuchIndex
Sonntag, 30. Mai 2010
Aber was sagt uns dieses Diagramm genau?
79. Frontend IPhone-App
Backend External Service
Indizierer
Datenbank
SuchIndex
Sonntag, 30. Mai 2010
Hardware? Prozesse? Request-Basiert oder Asynchron? Verteilt?
Welche Funktion haben die Elemente genau in der Architektur?
80. Frontend IPhone-App
Backend External Service
Indizierer
Datenbank
SuchIndex
Sonntag, 30. Mai 2010
Was sind die Verbindungen? Direkte Kommunikation? Kontrolliert ein Element das andere?
Rufen sie sich gegenseitig auf, synchronisieren sie sich?
Um eine Architektur zu beschreiben benötigt man also eine ganze Reihe von Diagrammen
und Beschreibungen. Ausser, man baut nur Monolithen.
81. Was macht eine gute
Architektur aus?
Sonntag, 30. Mai 2010
Frage an die Zuhörer: Was macht eine gute Architektur aus?
Welche Kriterien muss eine Architektur erfüllen?
82. Funktionalität
Sonntag, 30. Mai 2010
Zunächst einmal müssen die vom Kunden angeforderten Requirements erfüllt werden - das
ist klar. Wenn der Zweck der Anwendung nicht erfüllt wird, gibt es keine Anwendung. Aber
Architektur geht darüber hinaus.
83. ?
Sonntag, 30. Mai 2010
Hat jemand eine Idee, was weiterhin noch von der Architektur geliefert werden soll?
Gibt es bestimmte Anforderungen, die eine Architektur neben der offensichtlichen
Funktionalität erfüllen soll?
85. F
U
R
P ?
S
Sonntag, 30. Mai 2010
Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
86. F
U
R
P ?
S
Sonntag, 30. Mai 2010
Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
87. F
U
R
P ?
S
Sonntag, 30. Mai 2010
Quizfrage: Was bedeutet FURBS?
Englisches Umgangswort für Aufstossen,
eine Knuddelalienrasse aus Star Trek 1?
88. Functionality
Usability
Reliability
Performance
Security
Sonntag, 30. Mai 2010
Funktionalität - das, was der Kunde eigentlich wollte (typischerweise am Tag der Abgabe)
Usability - Wenn der Kunde das gewollt hätte hätte er keinen Programmierer fragen sollen
Reliability - die Verlässlichkeit der Applikation, Fehlerfreiheit und Verfügbarkeit
Performance - Antwortzeit, Durchsatz, Bandbreite und vieles andere
Security- Sicherheit in Netzwerk, Daten, Angriffsarten
89. Sonntag, 30. Mai 2010
Aber es geht natürlich noch komplizierter ...
91. ISO 9126
Wer ein fotografisches
Gedächtnis hat ist klar im Vorteil.
Sonntag, 30. Mai 2010
92. Funktionalität
Sonntag, 30. Mai 2010
Analog zu Furbs spielt Funktionalität den erste und wichtigsten Punkt
Inwieweit besitzt die Software die geforderten Funktionen? - Vorhandensein von Funktionen
mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen.
93. Funktionalität:
Angemessenheit
Sonntag, 30. Mai 2010
Eine Randfunktionalität sollte nicht 80% der Programmierung verursachen.
94. Funktionalität:
Richtigkeit
Sonntag, 30. Mai 2010
Der Durchschnittsentwickler: Ich glaube gesehen zu haben, dass es bei mir einmal bei einer
bestimmten Konstellation ein richtiges Ergebnis geliefert hätte.
95. Funktionalität:
Interoperabilität
Sonntag, 30. Mai 2010
Das verschweigen wir Developer gerne, dass wir das auch könnten, wenn wir wollten - statt
dessen verkaufen wir lieber eine enterprisig klingende Middle-Ware-Architektur.
96. Funktionalität:
Sicherheit
Sonntag, 30. Mai 2010
Das können wir PHPler inzwischen ganz gut.
Fähigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme
und Daten zu verhindern.
97. Funktionalität:
Ordnungsmässigkeit
Sonntag, 30. Mai 2010
Hej, es ist eine ISO-Norm. Also wird bei Funktionalität Konformität zu Standards gefordert.
Das können aber auch interne, eigene Standards sein. Im Regelfall reicht es, auf dem Papier
zu dokumentieren, dass man sie einhält, und in der echten Architektur einfach das zu
machen, wozu man Bock hat.
98. Zuverlässigkeit
Sonntag, 30. Mai 2010
Bei Zuverlässigkeit haben wir Entwickler einen doofen Fehler gemacht. Damals, auf DOS, war
es ok, wenn eine Software nach dem Start einfach mal eine Weile lief, wenn sie zwischendurch
mal Gabberish redet oder einfach abstürzt, dann hat der Nutzer neu gestartet und in Zukunft
um die Ursache herum gearbeitet. Heute ist es leider weniger Komfortabel, der Nutzer
erwartet allen Ernstes, dass die Software einfach funktioniert.
99. Zuverlässigkeit:
Reife
Sonntag, 30. Mai 2010
Wenige Fehler und wenige Bugs. Das können wir alle ziemlich gut, meist hört es nur an dem
Tag auf, an dem der Kunde beginnt, die Software tatsächlich zu benutzen.
100. Zuverlässigkeit:
Fehlertoleranz
Sonntag, 30. Mai 2010
Kann sich noch jemand an den Commodore Amiga erinnern? Sein Bluescreen hiess „Guru
Meditation“ und versprach, dass der Rechner wieder zu potte kommen würde. Kam er aber
nicht. Für diejenigen unter Euch, die Fehler machen: wenn einer passiert, sollte der Nutzer
nicht mit einem weissen Screen „Please contact your local system administrator“ konfrontiert
werden - ausser, euer Administrator hat es einfach verdient, so wie unserer.
101. Zuverlässigkeit:
Robustheit
Sonntag, 30. Mai 2010
Fähigkeit, ein stabiles System bei Eingaben zu gewährleisten, die gar nicht vorgesehen sind.
Die Software hält DAUs stand. Tipp für Leute ohne gut skalierbaren Idioten im Unternehmen:
einfach mal im familiären Kreis schauen, da gibt es eigentlich immer irgendwen, der
hartnäckig komische Dinge von Software verlangt und einen anruft, wenn es nicht klappt.
102. Zuverlässigkeit:
Wiederherstellbarkeit
Sonntag, 30. Mai 2010
Wenn eine Fehler auftrat, kann man den irgendwie wieder gut machen? Oder muss man bei
den Robotern, die die Simulation steuern in der wir leben nachfragen, ob sie die Matrix noch
mal auf dem Snapshot von 9:35 restarten können?
103. Zuverlässigkeit:
Konformität
Sonntag, 30. Mai 2010
Und hier auch wieder die Duftmarke der ISO-Norm: Werden Standards, auch gerne die
eigenen, erfüllt?
104. Benutzbarkeit
Sonntag, 30. Mai 2010
Entgegen anderslautenden Gerüchten unter Developern reicht hier nicht der theoretische
Nachweis, dass mit einer hochgetunten Intuition ohnehin alles offensichtlich ist, schliesslich
verstehe ich als Developer ja auch alles. Die Benutzbarkeit ist der Aufwand, den ich _nicht_
zum Einlernen und Verstehen brauche.
105. Benutzbarkeit:
Verständlichkeit
Sonntag, 30. Mai 2010
Ist Konzept und Anwendung auch für sterbliche verständlich? Oder sind die tieferen Logiken
nur dem Developer mit Schwerpunkt auf Prolog zugänglich?
106. Benutzbarkeit:
Erlernbarkeit
Sonntag, 30. Mai 2010
Aufwand für den Benutzer, die Anwendung zu erlernen (z. B. Bedienung, Ein-, Ausgabe).
Tipp für Entwickler: Einfach mal wichtige Funktionen hinter einem verwirrend benannten
Button verstecken. Das freut die Vertriebsabteilung, da wird gleich die Schulung
hinterherverkauft. Kennt jemand Unternehmen, die immer gleich Schulungen mitverkaufen?
107. Benutzbarkeit:
Bedienbarkeit
Sonntag, 30. Mai 2010
Aufwand für den Benutzer, die Anwendung zu bedienen. Wieviele Clicks sind zu machen,
wieviele Screens sind zu verstehen um einen einfachen Workflow durchzuführen?
108. Benutzbarkeit:
Attraktivität
Sonntag, 30. Mai 2010
Daaaa kann Apple mitreden. Ist die Oberfläche sexy? Will ich mit der Applikation gesehen
werden? Nehme ich sie heimlich mit unter die Bettdecke?
109. Benutzbarkeit:
Konformität
Sonntag, 30. Mai 2010
Und, die ISO-Duftmarke wieder.
110. Effizienz
Sonntag, 30. Mai 2010
Nicht nur die Frage, wie schnell die Seite antwortet - sondern vor allem, was leistet die
software für die eingesetzten Betriebsmittel? Braucht es einen Strato-Account oder eine Sun
Enterprise mit Oracle-Lizenzen für 32 CPUs?
111. Effizienz:
Zeitverhalten
Sonntag, 30. Mai 2010
Wieviele Requests pro Sekunde?
Und, „Responsivität ist das neue Schwarz“, wie schnell kommt die Antwort?
„Wir können 40 Requests pro Sekunde, sie dauern nur jeweils 10 Minuten“
112. Effizienz:
Verbrauchsverhalten
Sonntag, 30. Mai 2010
Wieviel CPU / Festplatte wird für eine bestimmte Leistung gebraucht? Wenn ich nen
Hardwarehersteller wäre, der sowas verkauft, würde ich versuchen eine Plattform zu bauen,
die möglichst viel davon braucht .... am besten mit einer eigenen Programmiersprache ...
andere Hardwarehersteller wie IBM würden das bestimmt stützen ...
Moment mal ...
113. Effizienz:
Verbrauchsverhalten
Sonntag, 30. Mai 2010
Wieviel CPU / Festplatte wird für eine bestimmte Leistung gebraucht? Wenn ich nen
Hardwarehersteller wäre, der sowas verkauft, würde ich versuchen eine Plattform zu bauen,
die möglichst viel davon braucht .... am besten mit einer eigenen Programmiersprache ...
andere Hardwarehersteller wie IBM würden das bestimmt stützen ...
Moment mal ...
114. Effizienz:
Konformität
Sonntag, 30. Mai 2010
Tjahaha, und die ISO-Jungs wieder ...
115. Änderbarkeit
Sonntag, 30. Mai 2010
Da beginnen unsere Kunden zu grinsen - Änderbarkeit ist die Fähigkeit, neue Features
abzubilden und Fehler zu korrigieren.
Deshalb wollen unsere Kunden so PHP-Jungs wie uns - weil angeblich können wir das super.
116. Änderbarkeit:
Analysierbarkeit
Sonntag, 30. Mai 2010
Das ist ein spannender Punkt. So Systeme wie Symfony oder Ruby on Rails erlauben es,
deutlich schneller als mit zB dem Zend Framework zu arbeiten. Auf der anderen Seite passiert
viel impliziert über lustige Hooks usw, und man weiss gar nicht immer, was man gerade alles
anfässt - zum Nachteil der Analysierbarkeit.
Auf der anderen Seite schadet Dokumentation und ein Gehirn auch nicht zwangsläufig.
117. Änderbarkeit:
Modifizierbarkeit
Sonntag, 30. Mai 2010
Das ist mal die konkrete Änderung. Wie lange brauch ich dafür. Habe ich eine saubere
Trennung der Concerns, oder muss ich in 7 Layern jeweils etwas ändern, um ein geändertes
Requirement abzubilden. Das ganze wird boykottiert von schlechten Boundaries und
natürlich von hoher Cohesion.
119. Änderbarkeit:
Stabilität
Sonntag, 30. Mai 2010
„Hey Boss, kein Problem, hab ich in 5 Minuten Live“ „Ja, die Produktionsseite läuft gerade
nicht, aber das hab ich gleich.“ „Uh, da war noch eine andere Sache, ich muss nur kurz die
Library umschreiben.“ „Chef, ich rufe aus dem Flugzeug nach Brasilien aus an, und wollte nur
sagen, es tut mir leid!“
120. Änderbarkeit:
Testbarkeit
Sonntag, 30. Mai 2010
Der Durchschnittsprogrammierer denkt: Verdammt, testen auch noch?
Wer arbeitet hier test-driven?
Wir haben die erfahrung gemacht, dass bei hohen änderungsfrequenzen von grossen
requirements testdriven keine freude ist.
Aber halt weniger scheisse als die alternative.
121. Übertragbarkeit
Sonntag, 30. Mai 2010
Für Commodity-software trivial: läuft das überall.
Aber auch Inhouse von bedeutung - Änderungen von Plattformen, datenbanken, der
Serverstruktur etc.
122. Übertragbarkeit:
Anpassbarkeit
Sonntag, 30. Mai 2010
Kann ich die Software schnell anpassen.
Anders formuliert: habe ich zB eine Datenbankabstraktion?
123. Übertragbarkeit:
Installierbarkeit
Sonntag, 30. Mai 2010
Wer benutzt hier Capistrano oder irgendein automatisches Deployment?
Wer installiert per Hand?
Wie lange dauert das?
124. Übertragbarkeit:
Koexistenz
Sonntag, 30. Mai 2010
Verlange ich spezialitäten von meiner umgebung, die dem rest der welt weh tun?
register_globals, anyone?
125. Übertragbarkeit:
Austauschbarkeit
Sonntag, 30. Mai 2010
Wie gut lässt sich meine Software wegwerfen?
126. Übertragbarkeit:
Konformität
Sonntag, 30. Mai 2010
Und die ISO-Jungs wieder, war ja klar.
127. O - Kay ...
Sonntag, 30. Mai 2010
Müssen wir wirklich alles beachten, wenn wir eine Architektur auswählen?
128. ?
Sonntag, 30. Mai 2010
Wer von den hier Anwesenden berücksichtigt jedesmal alle Aspekte?
129. Zu einer anderen Zeit,
an einem anderen Ort ...
Sonntag, 30. Mai 2010
130. Zu einer anderen Zeit,
an einem anderen Ort ...
Heute, in der Realität
Sonntag, 30. Mai 2010
132. Alte Bekannte 1:
Dinge, die sich in der Vergangenheit
bewährt haben ...
Sonntag, 30. Mai 2010
133. Alte Bekannte II:
... und Dinge, die sich in der
Vergangenheit nicht bewährt haben.
Sonntag, 30. Mai 2010
134. Technik mit
Coolness-Faktor
Sonntag, 30. Mai 2010
Das „echte“ Architekturvorgehen:
Ich habe eine coole Lösung, die ich spannend finde, die jemand verblogt hat.
135. Ich habe eine Lösung, und suche
nach einem Passenden Problem
Sonntag, 30. Mai 2010
Map-Reduce anyone?
NoSQL?
Message-Queues?
137. ARCHITEKTURNEUROSEN
• Innere Plattform
• Wheel Factory
• Gas Factory
• Golden Hammer
• ... und vieles mehr ...
Sonntag, 30. Mai 2010
Innere Plattform: Das System ist so universell Konfigurierbar, dass es letztlich nur eine
schwache Kopie der Plattform ist, auf der es gebaut ist. Beispiel: Ein Beispiel sind „flexible“
Datenmodelle, die auf konkrete (anwendungsbezogene) Datenbanktabellen verzichten und
stattdessen mittels allgemeiner Tabellen eine eigene Verwaltungsschicht für die Datenstruktur
implementieren.
Wheel Factory: Es wird jeweils etwas eigenes erfunden, anstelle etablierte Tools zu nutzen.
Gas Factory: ein einfaches Problem wird Enterprise gelöst
Golden Hammer: Ein bevorzugter Lösungsweg wird als universell beste Lösung angesehen.
138. Sonntag, 30. Mai 2010
Alle diese Dinge _können_ klappen, müssen aber nicht.
- nicht durch andere Nachvollziehbar
- nicht optimal für das Problem
- die Entscheidungsfindung und Motivation wurde nicht dokumentiert
Daher: Machen und Beten? Klingt nicht wirklich optimal ...
140. Architecture
Tradeoff
Analysis
Method
Sonntag, 30. Mai 2010
Die Tradeoff Analyse geht davon aus, dass es keine perfekte Architektur für alles gibt.
sondern nur Architekturen, die für jede Aufgabe ein paar Vorteile und ein paar Nachteile
mitbringen.
141. Sonntag, 30. Mai 2010
Das ganze kommt vom Software Engineering Institute, und ist eigentlich für die Bewertung
von Architekturen im Vergleich gedacht.
142. Es gibt kein Silver Bullet?
Sonntag, 30. Mai 2010
143. ATAM
Ermöglicht die Ermittlung präziser Qualitätskriterien
Sonntag, 30. Mai 2010
144. ATAM
Erzeugt eine frühe Architekturdokumentation.
Sonntag, 30. Mai 2010
145. ATAM
Erzeugt eine dokumentierte Basis für
Architekturentscheidungen
Sonntag, 30. Mai 2010
146. ATAM
Erkennt Risiken früh im Software LifeCycle
Sonntag, 30. Mai 2010
147. ATAM
Erzeugt bessere Kommunikation zwischen den Stakeholdern
Sonntag, 30. Mai 2010
148. Sonntag, 30. Mai 2010
Wie sieht ATAM genau aus?
„Was issene Dampfmaschin? Da stellen wir uns mal ganz dumm ...
149. Business Drivers
Sonntag, 30. Mai 2010
Welche Ziele verfolgen wir mit dem Projekt? Was sind unsere Prioriäten dort?
151. TECHNISCHE
EINSCHRÄNKUNGEN
„Muss auf Windows laufen“
„Datenbank ist Oracle.“
„Unsere Entwickler
können nur PHP!“
„Alles auf unserem eigenen Framework!“
Sonntag, 30. Mai 2010
152. ?
Sonntag, 30. Mai 2010
Welche technischen Einschränkungen gibt es bei Euch?
153. BUSINESS GOALS
1.OpenSource, Standards and of-the-shelf
2.Systemkomplexität reduzieren,
Komponentenwiederverwendung
3.Einfache Reparatur / Maintenance
4.Kostengünstige Änderungen / neue Features
5.Flexibilität und Konfigurierbarkeit
Sonntag, 30. Mai 2010
Die Werte kommen aus unserer Studie, einfach bei uns im Blog runterladen.
154. Sonntag, 30. Mai 2010
Stakeholder gibts viele, der erste ist aber klar:
Das sind natürlich erst mal die Jungs, die unsere Rechnung bezahlen. Aber nicht nur die.
155. Sonntag, 30. Mai 2010
Daneben gibt es noch die Leute, die unsere Software benutzen müssen,
- Leute, die die Software später weiterentwickeln müssen,
- Leute, die die Software in Produktion warten müssen
- Leute, die die Software testen müssen
etc ...
157. Sonntag, 30. Mai 2010
Auf Basis der Qualitätskriterien wird der Utility Tree gebaut, mit den Qualitätskriterien, die -
ganz konkret - für die Stakeholder eine grosse, wichtige Rolle spielen. Alle anderen, nicht
relevanten Qualitätskriterien werden ausgeblendet.
158. Sonntag, 30. Mai 2010
Für jedes Blatt des Utility Trees wird eine Szenario entworfen.
159. SZENARIEN
• Repräsentieren die Interessen der Stakeholder
• um die Wirkung der Qualitätskriterien zu ermitteln
Sonntag, 30. Mai 2010
160. SZENARIEN
• stellen wichtige Usecases dar
• stellen erwartete Änderungen dar
• stellen nicht erwartete Ereignisse da
Sonntag, 30. Mai 2010
Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie
vorher
Nicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.
161. GUTE SZENARIEN
• Use Case: Die Startseite benötigt im Tagespeak nicht mehr
als 1500 ms zur Darstellung
• erwartete Änderungen: Bei Verdopplung der Nutzer
kann durch Verdopplung der Applikationsserver die gleiche
Responsivität erzielt werden
• Nicht erwartete Änderungen: Nach einem
Datenbankserver-Plattencrash ist innerhalb von 30 Minuten
wieder für alle Nutzer normaler Betrieb möglich.
Sonntag, 30. Mai 2010
Erwartete Änderungen sind Dinge wie Erfolg - die Plattform hat doppelt so viele Nutzer wie
vorher
Nicht erwarte Ereignisse sind Dinge wie ein Ausfall von 50% aller Rechner.
162. Sonntag, 30. Mai 2010
Diese Szenarien werden mit der Priorität bewertet - H(igh), M(edium), L(ow)
163. Gearman-Message-Queue
(Zend, Cake, Symfony)-
Framework-basiert
REST-Architektur
ORM
Generiertes JavaScript
Magento erweitern
JavaScript Toolkit
NoSQL
Sonntag, 30. Mai 2010
Danach werden mögliche Architekturansätze gesammelt. Die können jeglicher Art sein, und
sich natürlich in Teilaspekten des Systems jeweils ergänzen.
164. Does it Blend?
Sonntag, 30. Mai 2010
Die Architekturen, die Anfangs vom Team ermittelt wurden, werden jetzt jeweils gegen den
Utility Tree geworfen, und geschaut, ob es zusammen aufgeht.
165. Sonntag, 30. Mai 2010
Fehlertoleranz und Performance konkurrieren zB häufig. Oder eine Architektur erlaubt gar
kein schnelles Ändern des Layouts. Oder die Queue wird - wie bei gearman - im Speicher
gehalten, und bei einem Hardwarefehler gehen zwangsläufig Daten verloren.
166. ANALYSE
• Welche Architekturen erfüllen die wichtigsten
Qualitätsattribute?
• Welche Risiken entstehen, weil bestimmte Attribute in einer
Architektur nicht erfüllt werden können?
• Welche Tradeoffs existieren?
Sonntag, 30. Mai 2010
167. Sonntag, 30. Mai 2010
Zusammen mit den Stakeholdern werden die Konsequenzen der Architekturwahl besprochen
und eine Architekturentscheidung getroffen.
168. Das ganze noch mal im Schnelldurchlauf
Sonntag, 30. Mai 2010
169. • Business Treiber definieren
• Utility Tree auf Basis von Qualitätskriterien
definieren
• Szenarien erzeugen und Priorisieren
• Architekture gegen Utility Tree Analysieren
• Ergebnis präsentieren & Entscheiden
Sonntag, 30. Mai 2010
170. Gruppenarbeit!
Vorstellen der Ergebnisse: 17:30
Sonntag, 30. Mai 2010