arc42 - Version 7

(for DE see below)

English Version

Finally, after extensive discussions with users and our committers we released a new version of arc42. Fully compatible with prior versions, preserving the established template structure, v7 has become even more pragmatic and compact. That makes using the new version simpler and more efficient than ever before. For v7 we vastly improved documentation and explanation of arc42 - creating two extensive sites (docs.arc42.org and faq.arc42.org). For a more detailed intro, see this post on the innoQ blog.

Deutsche Version:

Endlich, nach langer Diskussion mit Nutzern und Comittern haben wir eine neue Version von arc42 veröffentlicht. V7 ist vollständig kompatibel mit früheren Versionen. Wir haben die bewährte Struktur komplett erhalten, sämtliche Erklärungen und Hilfetexte jedoch gründlich überarbeitet und noch pragmatischer und einfacher gestaltet. Die Nutzung dieser neuen Version wird damit noch einfacher, als das bisher war. Insbesondere gibt es nun zwei umfangreiche Websites mit praktischer Hilfestellung ((docs.arc42.org and faq.arc42.org). Mehr Infos in diesem Post (im innoQ Blog).

Bauen versus Basteln

Vorsicht: Nestbeschmutzung

Tut mir ja wirklich leid, aber ich möchte an dieser Stelle mal ein wenig IT-Bashing betreiben - und mich über die teilweise grotesken Zustände der Softwareentwicklung beklagen.

TL;DR (aka Zusammenfassung)

Wir basteln oft, statt (systematisch) zu bauen. Das liegt manchmal weniger an uns Techies (Entwicklern, Architekten etc), sondern an negativen Wechselwirkungen vieler Parameter, die häufig miserabel gemanaged werden - und auf Dauer dann zu unwartbaren, unflexiblen und unverhältnismäßig teuren IT-Landschaften führen. Ziemlich drastisch hat das renommierte "Handelsblatt" es zuletzt unter dem Titel "Ramponierte IT" auf den Punkt gebracht:

"Die schlechten Computersysteme werden für viele Effizienzprobleme verantwortlich gemacht" (Handelsblatt)

Software "entwickeln" klingt systematisch...

Wir sagen fast alle "Softwareentwicklung" zu unseren Jobs - das klingt systematisch, fast so wie "Engineering". Wir erfreuen uns an Entwurfsprinzipien, verwenden etablierte Architekturmuster und arbeiten iterativ-agil. Stets streben wir nach Innovation und Verbesserung, und dauernd kommunizieren uns Blogs, Zeitschriften und Konferenzredner coole "Success Stories": Systeme in denen (scheinbar) alles richtig entschieden und ordentlich implementiert wurde.

"basteln" trifft es oft besser

In Wirklichkeit hat das so genannte "Entwickeln" von Software meiner Erfahrung nach in vielen Fällen deutlich mehr mit "Basteln" als mit systematischem Vorgehen zu tun. Die oben genannten "Erfolgsgeschichten" passieren oftmals "woanders", in ganz speziellen Situationen oder halten einer näheren Überprüfung nicht stand. Viele unserer mittleren bis großen Systeme sind "hysterisch gewachsen", man könnte auch "gewuchert" dazu sagen. Viele meiner aktuellen und ehemaligen KollegInnen können in ihren eigenen Systemen mehr Antipatterns aufzeigen, als Stellen, auf die Teams auch nach längerer Zeit noch stolz sind. Diese Probleme treten völlig unabhängig von (oder sogar trotz der...) so genannten Vorgehens- oder Reifegradmodellen auf.

Same Stupid Mistakes

Dabei wissen wir (SoftwerkerInnen) doch ziemlich genau, welche typischen Fehler auf lange Sicht zu übermässig komplexen Systemen führen - die wir im Team nicht mehr effizient weiter bearbeiten können... Aus meiner Sicht sind dabei folgende Themen besonders schlimm:

• Mangelhafte Anforderungen: Garbage in, garbage out. Wenn uns Product-Owner oder Fachbereiche unscharfe oder schwammige Anforderungen geben, werden wir möglicherweise stark konfigurierbare Systeme liefern, damit alle möglichen Interpretationen dieser Anforderungen noch erfüllbar sind. Uns allen ist aber klar, dass Konfigurierbarkeit mit hoher Komplexität einhergeht - und zu mehr Code führt, als wenn wir stärker abgrenzen und uns in Systemen stärker fokussieren.
• Unklare Qualitätsanforderungen:Teams haben immer "implizite" Vorstellungen, welche Qualitätsanforderungen ein System denn erfüllen müsste. Leider unterscheiden sich diese impliziten Annahmen manchmal gravierend von denen der Fachabteilungen, Auftraggeber oder sonstigen Systemverantwortlichen.
• Arbeit unter Zeitdruck: Es gibt im Durchschnitt immer mehr Arbeit als Zeit dafür. Daher gehen wir während der Arbeit an Systemen lauter kleine Kompromisse ein, die einzeln kaum auffallen, in ihrer Summe dann aber zu fatalen Mängeln der inneren Qualität führen - ein anderer Begriff dafür sind "technische Schulden".
• Kein Abbau technischer Schulden: Zu viele Abhängigkeiten, schlechte Modularisierung, geringe Konsistenz, übertriebene Inhomogenität, Nutzung veralteter Frameworks oder Technologie, unzureichende automatische Tests (um nur einige aufzuzählen) - das könnten wir ja alles bereinigen oder zumindest drastisch verbessern - sofern wir dafür etwas Zeit zugestanden bekämen. Aber: Der Abbau dieser technischen Schulden hat für unser Management kaum Priorität, ist mancherorts sogar als "nutzlose Zeitverschwendung" verschrien, die, so wörtlich, "ja keine neuen Features liefere".
• Mangelhafte Entwicklungsprozesse: Auch heute, im Jahre 2016, weigern sich Organisationen noch beharrlich, auf flexiblere und schnellere Entwicklungsprozesse zu setzen. DevOps und Continous-Integration werden als "funktioniert hier sowieso nicht" abgetan. Klar, das funktioniert ja wirklich nur, wenn Organisationen bereit sind, an ihren Prozessen als Ganzes zu arbeiten - also auch Anforderungen, Test, Deployment/Release und Betrieb zu optimieren. Einer meiner Kunden aus der Finanzbranche hat das letztens mal prägnant formuliert: "Da müsste mal von ganz oben jemand durchregieren - um den Silo-Fürsten die Macht über ihre Teilprozesse zu beschneiden."
• Lokale statt globale Optimierung: Entwickler besitzen einen fast unbändigen Drang zur Verbesserung, den sie gerne in Form von Refactorings oder kleinen lokalen Veränderungen ausleben. Solange umfassende und komplett automatisierte Tests diese Veränderungen auf mögliche Nebenwirkungen überprüfen, ist das gut. Manchmal verlieren Entwicklern jedoch den Überblick über die negativen Konsequenzen ihrer lokalen Änderungen auf andere Teile des Systems... Wir sollten Verbesserungen stets in etwas größerem Kontext betrachten - also über den Tellerrand einzelner Personen hinweg schauen. Das ist meiner Ansicht nach eine klassische Aufgabe für die Rolle "Softwarearchitektur".
• Wenig Verständnis für Zusammenhänge im Großen: Ich bekomme in realen Projekten oftmals zu hören: "Wir können ja die Wechselwirkungen auf andere Systemteile gar nicht mehr genau beurteilen".... Solange Projekte das Thema "Übersichtsdokumentation" weiter vernachlässigen, wird mangelnde Übersicht auch ein Problem bleiben.

Bin ich zu pessimistisch?

Klar, wir können auch "gut": Homogene Teams, ohne Fluktuation, über viele Sprints hinweg mit ausreichend Zeit und Budget ausgestattet, denen verständige und kundige Managerinnen den Rücken freihalten, und denen exzellente Product-Owner ordentliche und konsistente Anforderungen geben. Ich arbeite seit fast 30 Jahren in der Softwareentwicklung, habe praktisch alle Branchen von innen erlebt. Meine Teams reichten von 3 bis zu mehr als 200 Personen, Informationssysteme, Embedded-Systeme, Business-Intelligence, moderne und ziemlich alte Technologie, große und kleine, arme und reiche Auftraggeber... und die stets wiederkehrende Konstante all dieser Situationen ist die massive Unordnung. Nein - ich selbst glaube nicht, dass ich hier zu pessimistisch schreibe.

Abhilfe: Systematische Verbesserung

Unsere Grundthese bei der Verbesserung lautet:

"Reduktion technischer Schulden führt zu Kostensenkung in der Entwicklung neuer Features."

Sie müssen mit Ihrem Management über systematische Verbesserung sprechen, über zielgerichtete und gesteuerte Modernisierung und Evolution. Dabei müssen Sie zwischen "Features-liefern" und "Schulden abbauen" abwägen, denn Sie können einerseits niemals für längere Zeit auf neue Fachlichkeit verzichten, und müssen andererseits garantiert mit beschränktem Budget zurecht kommen. Als zentral erweisen sich dabei zwei Parameter:

• Innere Qualität der Systeme, die sich in Themen wir niedriger Kopplung, hoher fachlicher Kohäsion, hoher Codequalität, Konsistenz (Homogenität) der Implementierung und Verständlichkeit äussern.
• Äußere Qualität der Systeme. Anders ausgedrückt: Business-Wert, die Menge fachlicher Features, fachliche Leistung, Performance, Benutzerfreundlichkeit, Skalierbarkeit, Menge der erfüllten Kundenwünsche.

Argumentieren Sie gegenüber Ihrem Management, dass bei systematischer Verbesserung (d.h. Steigerung der inneren Qualität) die fachlichen Features wirtschaftlich günstiger ("preiswerter") werden - und wir zukünftig damit bessere time-to-market erreichen! Ihr Management kennt sicherlich den traurigen Normalfall: Über die Zeit werden bei (vielen) Systemen Features immer teurer, bzw. die Entwicklung immer langsamer (in der folgenden Abbildung die rote Linie). Ihr Management benötigt einen Überblick, welche Probleme es bei Systemen gibt- und wie "schlimm" diese wirklich sind, am besten in Geldeinheiten ausgedrückt. Damit werden verschiedene Probleme miteinander vergleichbar. Wenn Sie unsicher sind, geben Sie diese Problemkosten in Intervallen an, oder beschränken Sie sich auf die Angabe von Größenordnungen. Dazu stellen Sie Ihrem Management vor, welche Abhilfen es für welche Probleme gibt - am besten jeweils mehrere Alternativen. Hüten Sie sich davor, von der "einzigen Möglichkeit" zu sprechen, die angeblich ein Problem löst: Normalerweise gibt es zu jedem (!!) Problem nämlich eine Vielzahl möglicher Abhilfen. Erklären Sie, dass systematische Verbesserung längerfristig angelegt ist, und durchschnittlich sowohl den "business value" der Systeme verbessert (also für die Anforderungs-/Fachseite den Wert der Systeme steigert), gleichzeitig (!) aber auch die technischen Schulden reduziert. Das (Open-Source) Projekt aim42 (architecture improvememt method) stellt für die systematische Verbesserung fast 100 "good practices" zusammen, etablierte und bewährte Vorgehensmuster.

Fazit: Das klappt wirklich!

Vorsicht - Eigenwerbung: Sie können systematische Verbesserung lernen - wir bieten dazu den dreitägigen Workshop "IMPROVE" an.

An dieser Stelle möchte ich Ihnen Mut zusprechen: Hartnäckigkeit und Systematik lohnt sich: Ich habe in unterschiedlichen Branchen IT-Systeme verschiedener Größe und Komplexität "systematisch verbessert". Mit Teams zusammen habe ich time-to-market deutlich verkürzt, Test- und Entwicklungsaufwände gesenkt, Performance verbessert und in praktisch allen Fällen die Zufriedenheit der Teams signifikant erhöht. Ich habe (skeptische) Manager überzeugen können, dass Verbesserung sich wirtschaftlich lohnt. In diesem Sinne - bleiben Sie "am Ball". Erklären Sie, wie schlimm ihre Probleme sind, und welche direkten und indirekten Kosten sie verursachen. Update 9. Oktober 2016: Fixed typos.

FAQ for Software Architecture Documentation (with arc42)

I'm currently working hard on translating our German book (see this post) - which will be named "Communicating Software Architectures - lean, effective and painless documentation"). It's already on Leanpub, my favorite eBook publishing platform.

FREE in various formats

As arc42 is deeply rooted in open-source, I decided to extract the FAQ-section (frequently asked questions) from that book and make it available for free. As mentioned above - translation is not yet finished, and many of the questions in the FAQ collection have a "t.b.d" tag attached... but I'm quite positive I'll have the whole stuff translated until December 31st 2016.

Many categories of questions

I organized the (currently more than 100) questions in the following categories:

• A General questions
• B Questions on methodology
• C Questions on arc42 sections
• D Questions on modeling
• E Questions on arc42 and agile methods
• F Questions on tools for arc42
• G Questions on arc42 and versions / variants
• H Questions on arc42 and Traceability
• J Questions on managing documentation
• K Questions on customizing arc42

Your input is welcome

If you encounter questions around architecture documentation in general or arc42 in particular, let my know: DM me on our new @arc42Tipps Twitter account or email me on info-at arc42.de. By the way: I'm very grateful to innoQ for supporting arc42.

arc42 in Software-Engineering Radio Podcast

My innoQ-fellow-colleague, Eberhard Wolff, interviewed me about arc42 for the well-known podcast "Software Engineering Radio"... We discuss how documenting architecture fits into agile processes and how to find the right amount of documentation for a system. I briefly explain the different parts of the arc42 template covering requirements and the context of the system and the solution structure, including building blocks, runtime, and deployment. Finally, we cover tooling, versioning, testing documentation, and how to keep documentation up to date.

Praktische Tipps für arc42

arc42 hat sich als de-facto Standard für die Dokumentation von Softwarearchitekturen etabliert, zumindest in der D-A-CH Region. Schon länger gab es online diverse Beispiele, seit März diesen Jahres habe ich gemeinsam mit Michael Simons und Stefan Zörner dazu ein eBook veröffentlicht (als LeserIn dieses Blogs erhalten Sie bis Ende 2016 ganze 42% Rabatt!).

...in Aktion

Aber DAS wollte ich hier gar nicht in den Fokus rücken - vielmehr sollen konkrete Tipps zur Anwendung von arc42 zur Sprache kommen: Schon seit Jahren unterstütze ich Unternehmen unterschiedlicher Branchen und Größen beim Einsatz von arc42 in Entwicklungs- und Wartungsprojekten. Dabei konnte ich eine Vielzahl von Tipps und Ratschlägen sammeln - die nun endlich mal in gesammelter Form (als Buch) verfügbar sind. Peter Hruschka hat aus seiner vielfältigen Erfahrung, häufig aus Embedded und RealTime Umfeldern, kräftig beigesteuert, so dass wir auf insgesamt 200 Tipps rund um den Einsatz von arc42 gekommen sind. Ob es um arc42 in agilen Umfeldern geht, oder um die Anwendung in besonders großen (oder besonders kleinen) Systemen - stets liegt der Fokus auf praktischer Anwendbarkeit und Angemessenheit.

... Advent kommt bestimmt

Auf arc42 veranstalten wir ja regelmässig Aktionen, bei denen wir unseren LeserInnen kleine Geschenke versprechen. So viel sei hier verraten: Die Advents-Aktion 2016 hat etwas mit diesen Tipps und dem obigen Literaturhinweis zu tun... Es lohnt sich daher, gegen Jahresende ab-und-zu mal auf der Website vorbei zu schauen (oder dem noch jungen arc42-Twitter Account zu folgen).

one last thing

Übrigens schreibt gerade auch Ralf Müller (einer der Committer bei arc42 und langjähriger Nutzer!) ebenfalls gerade ganz aktiv einen Blog zum praktischen Einsatz von arc42.

Langlebigkeit und Wartbarkeit

 

In diesem Post möchte ich das alte Dilemma der steigenden Wartungskosten von Software ansprechen - und auf ein dazu passendes Buch (von Carola Lilienthal) hinweisen. Ich habe ihn für dieses Buch als Geleitwort geschrieben (bin damit sozusagen parteiisch).

Eigentlich...

... wissen Softwareentwickler(innen) und –architekt(innen) ganz genau, worauf sie bei Entwicklung und Änderung von Software achten sollten: Einsatz etablierter Architektur- und Entwurfsmuster, saubere Modularisierung, lose Kopplung, hohe Kohäsion und Durchgängigkeit (Konsistenz und innere Ordnung), dazu eine große Portion sinnvoller weiterer Entwurfsprinzipien. Haben wir alle gelernt, geübt und erfolgreich genutzt.

 

Dennoch...

... geht in den Tücken der Praxis so einiges schief: Viele Softwaresysteme erkranken über kurz oder lang an der IT-Seuche Nr. 1 – der „generellen Verrottung“: Folgen dieser Malaise: 

• Wartungs- und Änderungskosten steigen unaufhaltsam auf ein schier unerträgliches Maß an. 
• Intransparenz wohin man nur schaut. Kaum jemand überblickt noch die Konsequenzen von Änderungen. Selbst kleine Erweiterungen werden zum technischen Vabanquespiel.
• Arbeit an solchen Systemen wird zur Qual – obwohl Softwareentwicklung an sich zu den interessantesten Tätigkeiten überhaupt gehört. ☹

Der folgenden Abbildung liegt kein reales System zugrunde, spiegelt aber meine Erfahrung in Dutzenden mittlerer und großer Systeme aus unterschiedlichen Branchen und Technologien wider:

 

 

Endlich...

... bricht Carola Lilienthal mal explizit die Lanze für die beiden (in der Praxis allzu oft vergessenen) Qualitätsmerkmale Langlebigkeit und Wartbarkeit. Diese beiden bilden eine wesentliche Grundlage der inneren Qualität von Software. Niemand kann sie einer Software von außen ansehen – aber alle Stakeholder von Systemen möchten sie haben:

• Auftraggeber von Systemen freuen sich, weil sich die hohen Investitionen in Erstellung und Wartung lohnen und weitere Änderungen kostengünstig sind.
• Anwender und Fachabteilungen freuen sich, weil Änderungen am System schnell und mit hoher Zuverlässigkeit erfolgen können. 
• Entwickler und Softwarearchitekten freuen sich, weil Arbeit an sauberen Systemen viel produktiver ist. Niemand braucht mehr Angst vor bösen Nebenwirkungen einer kleinen Änderung zu haben.

 

Prima

... dass Carola dieses Buch geschrieben hat: Ihre langjährigen Erfahrungen auf dem Gebiet der Architekturanalyse von Systemen unterschiedlicher Technologien sind einzigartig. Dadurch stellt sie in jedem Winkel dieses Buches den nötigen Praxisbezug her.Ich durfte als einer der Ersten das Manuskript lesen – und habe sehr davon profitiert!

 

Mehr dazu im Buch selbst (die Website zum Buch ist noch in Arbeit…)

 

History:

Nov.07: fixed typos (thx, @stilkov)

Open-Close-Principle considered (practically) useless

Underlying Goal Considered Valuable

In a recent blogpost, the honorable Uncle Bob once again discussed the merits of the famous Open-Close-Principle. Quote:

You should be able to extend the behavior of a system without having to modify that system.

I like and strongly support that idea. It's realization by plugin-architectures is useful in some cases, it's foundation in object-orientation is one of the few useful applications of inheritance. I teach the OCP in classes and advice people inhale it like oxygen in their daily life. It's a beautiful theoretical concept. In practice, it's mostly useless - sigh.

The Nature of Changes in Practice

Since more than 20 years I work with teams changing, enhancing or optimizing software systems. I've seen code in financial industry, insurance and banking systems, logistics, telecommunications, embedded systems and, of course, the web. Changes were often corrections to previous requirements: (I quote real customers and product-managers in the following lines)

• "aargh - we didn't mean it THAT way, please correct it to THIS way".
• "Make it faster, whatever it takes."
)
• "We need some new attributes in the view"
• "You have to integrate the XYZ system urgently into our processing" (replace XYZ by SAP(c), Oracle(c) or any huge commercial software suite that you cannot integrate by just calling a simple API)

Too bad those requirements cannot be met by simply creating a new plugin to a nice-and-beautiful plugin architecture. Too bad those requirements often invalidate yesterdays' assumptions and code. The open-close-principle does not help me in those cases. Those cases are the rule, the standard, normal. Even if I (or other software engineers) had implemented plugin architectures - those wouldn't help with new attributes in some strange old-school UI or some backend insurance database.

Is Open-Close Applied in Real Systems?

Most productive systems I met (and I met many many dozens of them) don't have the notion of clear extension points. Many have been implemented by teams under severe cost or time restrictions without freedom to apply design principles - sigh again. That's one reason we founded aim42 - to systematically improve (and hopefully help spread OCP application..). @Uncle Bob: Thanx for your design principles - they make this (software) world a better place...

Software Quality is More Than Just Code Quality

I'm astonished how many people in our software business try to improve systems by JUST looking at source code - and ignoring loads of other aspects. Especially vendors of code analysis tools tend to equate "software quality" with "code quality" - which ignores major parts of quality issues. Let me illustrate my point with some examples.

Sample 1: Gold-Plated System

The team has created features above features, all highly configurable with a good-looking user interface. There's a button here, a menu there, some choices and a lot of functions... all stuff adding no business value, not useful for the end-user. By the way - all written in clean-code. In my opinion, this team produced *waste* - and the resulting system will more expensive to maintain than it needs to be - more lines of code, more configuration, more difficult to understand.

Sample 2: Overly Complex Solution

Data from a relational database is selected, then transformed into Java objects, then into an XML representation. This XML is processed into a pdf document, which is send via smtp-mail to the user. User prints the pdf, fills out some fields, scans the pdf. The system performs OCR (optical character recognition) and transforms back to xml. The xml is converted to Java objects, which are used to update the relational database. Sounds crazy? Is crazy - but describes an existing system. All written in nice and clean code. In my opinion this sample describes a conceptual disaster, where refactoring code alone wouldn't help - re-architecting the overall process would be the right approach.

Sample 3: Horrible User Experience

A company opened their impressive and useful backend services to customers by adding a web-frontend. Both back- and frontend code was written by expert programmers, adhering to many clean-code principles. Unit and integration tests supported the system. But the user interface has a nightmare. Layout, colors and screen flow had been created by programmers, not by usability-experts. Sidenote: I'm quite sure you have experienced similar situations... programmers-as-designers seems to be a common anti-pattern in development.

Software Quality is MORE than Code Quality

The examples above hopefully illustrate the point that even with well-written code a system can *fail* for its users or developers. Quality attributes like performance, understandability, maintainability, understandability, security or compliance might be neglected despite good source code...

Analyze Problems From Bird's Eye Perspective

In exiting business systems you should approach *improvement* or system evolution from different perspectives, not only by counting code-violations or code-metrics. For example the following perspectives provided valuable input for some of my own practice experiences:

• Qualitative Analysis (e.g. ATAM)
• Runtime Analysis, e.g. performance and resource monitoring
• Analysis of Development Process
• Data Analysis - find improper structures and content
• Issue-Tracker Analysis
• Static Code Analysis

Clean Code is Important...

I'm convinced of the importance of understandable code. I will actively promote refactoring towards cleaner code whenever appropriate. The principles of clean code need to be taught and practiced throughout our industry. But hopefully you see my argument - there's some more to do: we need to create understandability on a higher level, need to design appropriate technical and business concepts, need to design appropriate data structures and interfaces and so on...

Methodical Improvement to the Rescue

What's needed to systematically improve software is an iterative approach to find *many* problems, not only within code. aim42 collects practices and patterns to achieve exactly that - the foundation for systematic improvement. Think about it when some manager demands compliance to some code metric or coding-convention... you might be better off by optimizing or improving something completely different.

aim42 - Systematic Approach to Software Maintenance

During the OOP-Conference 2014, Stefan Tilkov and myself released aim42 - the systematic approach to software maintenance and improvement.

We named it "aim", short for "Architecture Improvement Method". aim42 is a free and open-source project, a community approach to collect practices and patterns.

Why Do We Need Software Architecture Improvement

Software maintenance is a major issue, because over time many systems degrade massively: Understandability (and with it, maintainability) goes down, and cost-of-change grow. See the diagram below:

aim4 Phases

It consists of three distinct phases:

1. Analyze: search and collect problems, issues, deficiencies and technical debt within your system and your development process.
2. Evaluate:understand root-causes of problems, determine their „value“ and cost/effort of their remedies.
3. Improve: systematically improve code and structures, reduce technical debt, remove waste and optimize.

Community Approach

Currently we host the (AsciiDoc) source of the aim42 guidebook on Github, one of the best-known open-source communities.
https://github.com/aim42/aim42
Find some further information (oops - currently in German only) within our initial presentation (on Speakerdeck) or the upcoming YouTube channel.

Changes

* Feb. 16th: Changed URL from Bitbucket to Github

innoQ und arc42 machen (wieder) Unmögliches möglich

mit unserer coolen Sommer-Aktion, gegen Langeweile und schlechte Laune:
Wir lösen den Widerspruch zwischen "gedruckt" und "eBook" (zur CPSA-F Zertifizierung) auf!
Unser kleines eBook über die iSAQB Prüfung zum Certified Professional for Software Architecture (Foundation Level) gibt es ausschliesslich in digitaler Form - zumindest können Sie es nur so kaufen.
In Absprache mit dem Verlag und mit tatkräftiger Unterstützung von innoQ haben wir (Peter Hruschka und ich) eine limitierte Auflage gedruckt - die wir für kurze Zeit auf fcfs-Basis (first come first serve) gerne an Interessenten verschenken!

Update, Januar 2013: Die Aktion ist ausgelaufen - wir haben jetzt KEINE Exemplare mehr übrig, sorry!

Es erwartet Sie ein Überblick über den iSAQB Lehrplan, eine kurze Auffrischung der relevanten Themen, eine Vorstellung der Prüfungsmodalitäten sowie Hinweise zu den Arten von Prüfungsfragen.
Garantiert zu kurz, um non-geeks das Bestehen der Prüfung zu ermöglichen, aber als kompakte Wissensauffrischung für Softwareentwickler und -architekten hoffentlich hilfreich.

Einfach eine Email an gernot.starke@innoq.com senden, als Promotion-Code "GS-Sommer-13" und die Postadresse nicht vergessen, an die wir Ihr persönliches Exemplar senden dürfen...

Patterns-kompakt, die Vierte...

Gerade frisch aus der Druckerpresse kommt die vierte Auflage von Patterns-kompakt, der kurzen und hoffentlich kurzweiligen Einführung in Entwurfsmuster.

Das Buch fasst die wichtigsten Entwurfsmuster zusammen, die Sie für Software-Entwicklung benötigen. Software-Entwickler, -Architekten und -Designer finden darin effektiv anwendbare Lösungen für tägliche Entwurfsprobleme. 

Neu zur vierten Auflage sind jede Menge Codebeispiele, die zum Experimentieren mit den Mustern einladen… siehe hier.

Mehr zum Inhalt, viele Extrakte und jede Menge zugehörigen Sourcecode finden Sie auf der Website zum Buch… (danke an Karl Eilebrecht, dem PK-Helden!)

 

Rein aus historischen Gründen hier mal die Evolution der Cover (links mit der ersten Auflage beginnend) - wobei wir uns für das Aussehen der ersten Auflage ja fast bei unseren Lesern entschuldigen müssen :-)

  

 

Übrigens hat auch der Verlag eine Evolution hinter sich - von Spektrum über Spektrum-Elsevier zu Springer zu Springer-Vieweg…. 

(unabhängiger) Artikel über arc42-Einsatz

In der dotnetPRO erschien vor einiger Zeit "Nie wieder planlos" - ein ausführlicher Überblick zum arc42-Template und dessen Einsatz in der Praxis - aus der Feder von André Krämer.

 

Seit heute ist dieser kostenfrei als download erhältlich - dank einer Sondergenehmigung der dotnetPRO-Crew :-)

 

 

arc42 now has open source repositories

At Bitbucket you now find our arc42.org open source code repositories. They are independent of the arc42 architecture template (will someday maybe serve as examples for the latter).
I just comitted two small utilities for Pdf manipulation (PdfStamper and PdfUtil) - both are not "finished" but working...

Issue trackers are live and actively monitored.

The third project, DupeDetect, handles duplicate entries in your geocaching logs… In case you don't know what that is, don't mind. Geocachers *will* know. Hopefully we make this available as a cloud-based service soon, parallel to the source code.
(did I ever mention that I absolutely *love* the Atlassian guys…)

Software Architecture "Summer" in Berlin

Summer-Summit in Berlin - or is it Summit-Summer?

I'm proud to be part of a new conference in Berlin, June 5.-7th 2013. A number of top-notch software architects (aahm - plus myself…)  present current topics in interactive sessions.

Simon Brown, Neal Ford, Phillip Ghadir,  Dr. Venkat Subramaniam, Stefan Tilkov and Vaughn Vernon should be reason enough to join...

 Topics include evaluation and estimation, concurrency, delivery, domain-driven-design and others - check the website for details. 

My topic will be software interfaces - you'll get examples of horrible, good and excellent interfaces, plus numerous practices and tips to improve your own interfaces…  Would be great to meet you in Berlin!

 

pragmatic Enterprise-Architect(™) template for arc42

I just released a slender version of the arc42 template in Enterprise-Architect(™) format.

Deliberately the template contains only four packages, although the full arc42 template contains several others:

Use it to model (construct, design or document) all structural aspects of your system, and use any other (text-oriented) tool for non-graphical information.

As with all arc42 artifacts, the template is absolutely free to use, no hidden fees or restrictions. It'd be nice though if you mentioned arc42...

Download

Download the template (with a very brief documentation) here.

Documentation

Even newcomers to Enterprise-Architect will be able to use the template within EA - nevertheless we provide a brief documentation for it within the arc42-confluence.

Restrictions

The template does contain a report generator, therefore it is currently not suited for complete software or system architecture documentation - just for the graphical information.

Disclaimer:

You are allowed to use this template in all situations you like – but we do not provide any (ANY!) kind of guarantee for it. It might crash your EA, or inflict your mind – we cannot possibly exclude such incidents. So please give us feedback, but please don’t blame us for any issues with EA, the template or your project.

Thanx

Thanx to my colleagues from innoQ Deutschland for supporting this work, thanx to Axel-N for productive discussion about modeling in general and especially applying EA.

Camp mit zwei Trainern

Vorsicht: Der nachfolgende Post enthält einen (kleinen) Anteil Eigenwerbung:

Für 2013 bieten mein geschätzter innoQ-Kollege Phillip Ghadir und ich einige interaktive Schulungen (a.k.a. Camps) zu Softwarearchitektur an, bei denen wir gleichzeitig unterrichten: Über die gesamten vier Tage werden wir beide immer dabeisein - um dem jeweils Anderen scham- und schonungslos ins Wort zu fallen und dessen Ausführungen durch unsere eigene Erfahrung zu ergänzen, abzurunden oder zu kontrastieren.

Wir sind der Meinung, dass die "War Stories", also die (anonymisierten) Berichte aus realen Projekten die wahre Würze der Schulungssuppe ausmachen - und dass wir wesentlichen Lerneffekt besser durch Beispiele denn durch theoretische Konzepte erreichen. Solche realen Erfahrungen können wir zu zweit intensiver und vielseitiger vermitteln, als das ein einzelner Trainer alleine vermag!

Für uns (und die Entwickler-Akademie als Veranstalter) bedeuten zwei Trainer erheblichen Mehraufwand - Koordination, Abstimmung, Vereinheitlichung der Unterlagen und so weiter... All das nehmen wir aber gerne in Kauf, weil wir (Phillip und ich) fundamental von dem Konzept "Ein Camp, zwei Trainer" überzeugt sind!

Vom 19.-22. Februar finden Sie uns in München, im Mai dann in Berlin. Sie können im Anschluss die iSAQB e.V. Zertifizierungsprüfung zum "Certified Professional for Software Architecture - Foundation Level" ablegen. Dafür (und noch wichtiger, für Ihr weiteres Leben als Softwarearchitekt) machen wir Sie fit - versprochen!



Apropos - das Konzept verfolgen Peter Hruschka und ich mit den arc42-Workshops "Mastering Software Architectures" schon seit einigen Jahren mit großem Erfolg.
















Update (nach dem Workshop) - einige Stimmen von Teilnehmern, aus Kommentaren
in Phillip Ghadir's Blog.

Beispiele für Qualitätsanforderungen

Ich habe begonnen, beispielhafte Qualitätsanforderungen an Software zu sammeln - und eine erste Version davon (als docx-Dokument) online gestellt.

Eingeteilt habe ich nach den Qualitätsmerkmalen:

• Änderbarkeit


• Benutzbarkeit


• Effizienz (Performance)


• Sicherheit


• Skalierbarkeit


• Zuverlässigkeit


• Betreibbarkeit


• Sonstige

Die Liste ist momentan ein Draft - enthält aber immerhin mal > 30 typische Szenarien. Mehr sind unterwegs...

Sie wird in naher Zukunft Bestandteil von arc42.

arc42 Template available as confluence-space

Yesterday, motivated by a friendly client, I finally managed to export the English (EN) and German (DE) versions of the arc42 software architecture template directly from their confluence spaces (at confluence.arc42.org).

In case you're using the Atlassian Confluence Wiki in version 4.2.x, you may grap the zipped xml files from the arc42.org download section.

Experience reports are highly welcome :-)

Update Nov 25th 2012: The current arc42.org template has been exported with our production version (4.2.x). In 2013 we accidently have no capacity to upgrade our confluence instance to 4.3.x. We apologize - but we therefore cannot provide a template export for the confluence 4.3.x branch. Hopefully this issue will be solved in early 2013.

Neue Bücher zur iSAQB Foundation-Level Zertifizierung

Mehrere gute Nachrichten für Interessenten am iSAQB Foundation-Level Zertifikat:

Im November 2012 erscheinen gleich zwei neue Bücher zum Thema:
(disclaimer: an beiden habe ich mitgeschrieben!)

Gemeinsam mit Peter Hruschka habe ich einen kleinen Wegweiser zur erfolgreichen Zertifizierungsprüfung geschrieben - der aktuell bei Entwickler.Press als E-Book erscheint. Der genaue Titel lautet: Zertifizierung für Softwarearchitekten - Ihr Weg zur iSAQB CPSA-F Prüfung. Inhaltlich stellen wir dort genau die Themen des Foundation-Level Lehrplans vor. Dieser shortcut ist eine Auffrischung für alle, die einen kompakten Überblick über die behandelten Themen und einen leicht lesbaren Einstieg suchen. (update, 19.Nov 2012: Hier gibt's die Kindle-Version.

In der Viererbande mit Mahbouba Gharbi, Arne Koschel und Andreas Rausch haben wir nach zwei Jahren Arbeit endlich das "Basiswissen für Softwarearchitekten fertiggestellt. Dieses Buch eignet sich prima als Prüfungsvorbereitung - aufgrund seiner Kürze mussten allerdings viele für die praktische Architekturarbeit relevante Themen aussen vorbleiben (aber dafür gibt's ja den praktischen Leitfaden für effektive Software-Architekturen)

Architektur auf Tour

Ich bin sehr froh, bei der kleinen, aber feinen Jax-on-Tour 2012 mitwirken zu dürfen.
Die Veranstalter hat einen guten Themenmix und klasse Sprecher zusammengestellt, unter anderem Ted Neward, Stefan Tilkov, Wolfgang Keller, Phillip Ghadir und Matthias Bohlen… Erwarten Sie geballte Erfahrung und spannende Vorträge.

Disclaimer: Ich spreche auch…