Kategorie: Architektur Seite 1 von 3

Jan Bosch: Viele Firmen verbauen sich den Weg zu Innovation, indem sie von bestehender Organisation und Prozessen starten statt von ihrem zukünftigen Business und daraus abgeleiteten Architekturen.

Gemacht wird: OPAB
Richtig wäre: BAPO.

Architekten als Geschichtenerzähler, Soziotechnologen, Dokumentierer und mehr (O’Reilly Architecture Conference London 2017)

London - Tower Bridge at Night
Am 16./17. Oktober fand in London die O’Reilly Conference Software Architecture statt. Wir waren mit unserem Talk „How do software architects find the way to user experience? With Google Maps“ dabei. In diesem Artikel lassen wir die Konferenz Revue passieren.

Die Konferenz war sehr gut besucht (geschätzt ca. 500 Leute) und zog Architekten und Entwickler aus ganz Europa, aber sogar auch von anderen Kontinenten an.

Ein interessantes Konzept waren die recht kurzen Keynotes (ca. 20 Minuten). So wurden statt einer langen Keynote gleich 3 Keynotes am Stück präsentiert, was zu sehr pointierten und kurzweiligen Vorträgen führte.

Auch eine interessante Beobachtung (wie bei einigen vergangenen Veranstaltungen): Firmen sind aktuell stärker auf der Suche nach neuen Mitarbeitern als nach neuen Kunden! Architekten und Software Engineers im Allgemeinen sind aktuell also sehr gesucht!

Es gab Talks zu unterschiedlichsten Aspekten von Softwarearchitektur. Wir orientieren uns hier im Artikel an einer Charakterisierung von Architekturkompetenz und Architekturthemen, die wir im Blog auch demnächst noch beschreiben werden. Die Darstellung der Talks hier im Artikel soll nicht repräsentativ sein, sie spiegelt eher wieder, welche Talks wir uns angesehen haben und für besonders sehenswert halten. Meist sind auch die Folien der Talks verfügbar oder sogar Videoaufzeichnungen, die wir dann verlinkt haben.

  • Architekturgrundlagen
  • Architekturmethoden und –Tools
  • Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)
  • Architekturaspekte rund um Menschen und Organisationen

Zum Abschluss gab es als Übung und gemeinsames Event noch Architecture Katas, die wir am Ende des Artikels beschreiben.

Architekturgrundlagen

Mark Richards widmete sich in seiner Keynote „The move toward modularity“ dem Thema Modularität, das eine zentrale Rolle für Softwarearchitektur spielt und durch Microservices wieder mehr ins Bewusstsein gerufen wurde. Mark Richards beleuchtete verschiedene Facetten von Modularität, insbesondere auch die dahinterstehenden Ziele (bei ihm: Agility, Testability, Deployability, Scalability, Availability).

Architekturmethoden und –Tools

Der neue CTO Patrick Kua vom deutschen Fintech-Unternehmen N26 sprach über in unterhaltsamer und anschaulicher Weise über Architekturdokumentation. Dazu verwendete er als Analogie den Reiseführer: „The travel guide to a software system“.

Er beschäftigte sich mit zahlreichen Fragen rund um die Erstellung von guter und pragmatischer Architekturdokumentation:

  • Gründe, sich mit Architekturdokumentation zu beschäftigen
    • Menschen kommen und gehen
    • Organisationen wachsen
    • Man hinterlässt mit einem System ein Vermächtnis
    • Zukünftige Arbeiten sollte nicht mit Detektivarbeit starten müssen
  • Wichtigste Inhalte
    • Historie (Kontext, Entstehungsgeschichte, Erfahrungen, wichtigste Entscheidungen, …)
    • Sinnvolle Fakten (Domänenwissen, Akronyme, Personas, wichtigste Use Cases, …)
    • Kultur (Coding Guidelines, Konventionen im Code, Entwicklungsprozess, …)
    • Karten / Sichten (Gesamtsicht, verschiedene Aspekte und Sichten des Systems (z.B. C4 Model von Simon Brown), Sequenzdiagramme, Flussdiagramme, …)
    • Sehenswürdigkeiten (Wichtigste Punkte im System, Systeme häufigster Änderungen, …)
    • Fun (Fun Facts zum System, Stellen, an denen besonders innovative oder kreative Lösungen zu finden sind, …)
  • Die Reise zur Architekturdokumentation
    • Ausgangspunkt (Immer vom Leser her denken, was sind die Use Cases von Dokumentation)
    • Größe (hängt von Historie, Menschen, Änderungsgrad und –geschwindigkeit, Domänenkomplexität ab)
    • Aktuell halten

Architekturelle Systemexpertise (Herausforderungen, Lösungskonzepte, Technologien, Frameworks, …)

Eoin Woods, CTO von Endava, sprach über Security aus Sicht des Architekten: „Practical security principles for the working architect”. Der Talk war extrem kurzweilig und stellte zentrale Sicherheitsprinzipien dar, die bei jedem Design einer Systemarchitektur durchdacht werden sollten. Insbesondere die Betrachtung von Security jenseits der reinen Codeebene (wie z.B. Lücken wie Buffer Overflows) ist sehr wichtig und wird häufig in der Praxis vernachlässigt. Eoin Woods zeigte an guten Beispielen auf, wie Architekturentscheidungen und verschiedene Modularisierungen zu unterschiedlich sicheren Systemen führen können.

Auch unser Vortrag „How do software architects find the way to user experience? With Google Maps“ passt in diese Kategorie. Er illustriert den engen Bezug zwischen User Experience und Softwarearchitektur, der immer noch zu wenig Beachtung findet. Das liegt unter anderem auch an den unterschiedlichen Ausbildungshintergründen von Softwarearchitekten und UX Designern. Am Beispiel von Google Maps zeigen wir auf, welche Architekturentscheidungen getroffen wurden, um die bekannt gute User Experience von Google Maps zu erreichen.

Yan Cui sprach zum Thema serverless computing am Beispiel von Amazon Web Services Lambda: „Serverless in production: An experience report“. Er berichtete von Erfahrungen bei ersten Experimenten und realem Einsatz von AWS Lambda. Er konnte mit vielen Beispielen und Fallstricken punkten und konnte somit der aktuell sehr gehypeten Technologie eine gute Erdung und viele Tipps zur Umsetzung geben.

Architekturaspekte rund um Menschen und Organisationen

Nathaniel Schutta gab eine großartige Keynote zur Kommunikation von Softwarearchitekten: „Architect as storyteller”.

Zwei Aspekte hat er dabei insbesondere herausgearbeitet:

  • Zur Kommunikation braucht mal als Architekt (wie in anderen Rollen auch) klar herausgearbeitete Messages und eine konsistente Story. Ein Architekt muss ein „Keeper of Tales“ sein, er muss also viele gute Stories kennen. Dabei ist es nicht zwingend erforderlich, dass er die Story, die er erzählt selbst erlebt hat. Hauptsache es ist eine wahre Story, die sich gut zum Erklären eines bestimmten Sachverhalts eignet.
  • Je nach Zielgruppe muss man die Messages und die Story stark anpassen. Da der Architekt potentiell mit sehr vielen verschiedenen Zielgruppen / Stakeholdern (Manager, Kunden, Produktmanager, Projektleiter, Entwickler, Tester, …) arbeitet, muss entsprechend angepasst werden. Das verursacht zwar Aufwand, lohnt sich aber weil ansonsten die Message nicht verstanden wird und dadurch viele Probleme verursacht werden.

Nick Tune widmete sich dem Thema Organisationsgestaltung durch Architekten: „Great technical architects must be great organization architects”. Im Kontext von Microservices hat Conway’s Law wieder sehr viel Aufmerksamkeit bekommen. Nick Tune erläuterte anschaulich, wie die integrierte Gestaltung von Organisationsstrukturen und Softwarearchitekturen dafür sorgen kann, Reibung in der Entwicklung zu erkennen und zu vermeiden und damit schneller Software liefern zu können.

Dazu gab Nick konkrete Beispiele, welche organisatorischen Entscheiden mit Aspekten der Systemdekomposition zusammenspielen. Ankerpunkt war dabei natürlich Domain-Driven Design und Bounded Contexts.

Nick ging darüber hinaus auch auf das oft vorherrschende Bild von rein technischen Softwarearchitekten im Elfenbeinturm ein. Seinen Vortrag gestaltete er dann als Plädoyer für eine andere Art von Softwar

earchitekten (den Sociotechnical Architect), die sich ganzheitlichen Aufgaben widmen und trotzdem mit der gebotenen Demut an die Aufgabe herangehen.

Architecture Katas

Zum Abschluss der Konferenz gab es im großen Stil die Möglichkeit, an Architecture Katas teilzunehmen. Die Idee dabei ist, Architekten die Möglichkeit zu geben, Architekturarbeit zu üben …

Dazu die zwei folgenden Zitate:

  • „How do we get great designers? Great designers design, of course.“ –Fred Brooks
  • „So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career?“ –Ted Neward

Organisiert und moderiert waren die Katas durch Neil Ford. Die Aufgabenstellungen stehen auch online auf seiner Webseite.

Insgesamt konnten 30 Personen in 6 Gruppen aktiv teilnehmen und hatten 45 Minuten Zeit, um die Aufgabe so gut wie möglich zu bearbeiten. Die übrigen Teilnehmer waren Beobachter (oder unterhielten sich abseits bei Bier und Häppchen ;-)).

 

Matthias war beim Design in einer Gruppe dabei, Marcus war einer der Beobachter. Wir haben das in der Form zum ersten Mal gemacht und möchten gerne einige der Erfahrungen und Erkenntnisse von den Architecture Katas teilen.

Matthias als Teilnehmer am Design:

  • 5 Teilnehmer einer Architekturkonferenz haben mitunter sehr unterschiedliche Auffassungen davon, was Architektur ist und wie man zu einer Architektur kommt 😉
  • Man muss eigentlich alles diskutieren: Anforderungen, Scope der Aufgabe, Reihenfolge des Vorgehens, inhaltliche Architekturentscheidungen, Notationen, was soll überhaupt abgeliefert werden?, wer macht was?, …
  • Dadurch dass die Katas so kurz formuliert sind, bieten sie erheblichen Ausgestaltungsspielraum, den Informatiker / Architekten / Entwickler natürlich direkt erkennen und zu diskutieren wissen
  • Deshalb sind 45 Minuten wirklich kurz, um etwas auf die Beine zu stellen
  • Es hat nicht unbedingt der Recht, der am lautesten redet 😉
  • Die Aufgabe per Mikrofon weiter zu präzisieren, während 100 Leute schon arbeiten und reden, funktioniert nicht
  • Wenn man die Teilnehmer nach Ablauf der Zeit nicht zwingt, aufzuhören, dann machen sie noch 20 Minuten weiter während die ausgewählten Gruppen schon ihr Ergebnis präsentieren müssen
  • Es macht einen riesigen Unterschied, wer die Architektur letztlich vorstellt und wie gut er sie erklärt (insbesondere den Kontext, die Überlegungen, Einordnungen, Erklärungen, die alle nicht aufgeschrieben wurden in der kurzen Zeit)
  • 5 Leute sind für eine Gruppe zu viel, um gut voranzukommen. Eine Gruppengröße von 2-3 Leuten wäre besser geeignet

Architecture Kata Session as Observer - O'Reilly Software Architecture 2017

Marcus als Beobachter:

  • Alle 6 Gruppen sind sehr unterschiedlich vorgegangen.
  • Das fängt schon bei der Art und Weise an, wie sie Gruppen sich aufgeteilt haben. Allen 6 Gruppen stand ein großer Runder Konferenz-Dinner Tisch sowie 2 Flipcharts zur Verfügung. 2 Gruppen haben sich dazu entschieden, sich um die Flipcharts zu stellen (darunter auch die Gruppe von Matthias). Die anderen 4 Gruppen haben sich an die Konferenztische gesetzt.
  • Aus meiner Beobachtersicht heraus kamen die zwei Gruppen, die stehen geblieben sind, schneller voran.
  • Die Gruppen an den Flipchart haben auch mehr als ganze Gruppe diskutiert, wohingegen die Gruppen an den Tischen eher in Kleingruppen (2-3er) diskutiert haben.
  • Alle Gruppen haben direkt mit fachlichen Diskussionen angefangen. Keine der Gruppen hat sich mit „organisatorischen“ Dingen (direkt am Anfang) beschäftigt (z.B.: Welche Sichten benötigen wir? Sollen wir uns für Teilaufgaben aufteilen? Wer stellt am Ende das Ergebnis vor?)
  • Es ging wohl so richtig in allen Gruppen erst voran, als einer oder zwei Gruppenteilnehmer die Initiative übernommen haben.
  • Eine Gruppe hat sich sogar trotz der geringen Zeit von 45 Minuten dafür entschieden, einige Dokumente digital zu erstellen und nicht nur am Flipchart.
  • Die Repräsentation der Ergebnisse war auch völlig unterschiedlich. Dabei beziehe ich mich nicht nur darauf, was die Gruppen gezeigt haben, sondern auch wie sie es dargestellt haben.
  • Man sollte sich gerade in solchen „künstlichen“ Situationen auch direkt damit beschäftigen, wie das Ergebnis am Ende repräsentiert wird.
  • Auch die Wahl des Präsentators sollte gut ausgewählt werden, insbesondere, wenn es etwas zu gewinnen gibt.

Insgesamt waren die Architecture Katas eine sehr interessante Erfahrung. Wir können es Architekten und Entwicklungsteams nur empfehlen, solche Übungen auch zu machen. Dabei kann der Scope durchaus auch ausgeweitet werden, um auch das Zusammenspiel mit anderen Disziplinen wie Requirements Engineering oder User Experience Design zu üben. Der Vorbereitungs- und Zeitaufwand ist gering, dafür lernt man vieles und kommt zu zahlreichen Erkenntnissen über die Zusammenarbeit mit Kollegen.

Interview: „Fähnchen statt echter Digitalisierung“

Am 29. November sprechen wir bei der Cloud Expo Europe.

In der Vorbereitung gaben wir ein Interview zu den Themen Softwarearchitektur, User Experience und Digitale Transformation:

„Fähnchen statt echter Digitalisierung“

 

On Tour: Cloud Expo Europe, Frankfurt, 2017

Am 28. und 29. November 2017 findet in Frankfurt die Cloud Expo Europe statt. Wir sind mit einem Vortrag zu Softwarearchitektur und User Experience dabei.

Wie finden Softwarearchitekten den Weg zu User Experience? Mit Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von  Softwaresystemen. Der Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Unser Vortrag ist am 29. November um 13:10 .

Dazu gibt es auch ein Interview mit uns.

On Tour: Bitkom Arbeitskreis Softwarearchitektur, Köln, 2017

Am 29. Juni findet in Köln der Bitkom Arbeitskreis Softwarearchitektur in Köln statt. Thema ist: „Microservices: Das neue Instrument für große Orchester“. Ich bin mit einem Vortrag zum Thema Modularität und Microservices mit dabei und freue mich auf spannende und kontroverse Diskussionen zum aktuell hoch gehandelten Thema Microservices.

Modularität: Schon immer gewollt und selten erreicht – Sind Microservices und Self-Contained Systems der Durchbruch?

Modularität war schon das erklärte Ziel, als noch niemand von Softwarearchitektur sprach. Daran hat sich bis heute nichts geändert und aufgrund der stetig wachsenden Größe von Software wird Modularität immer noch wichtiger, um Herr der Lage zu bleiben. Trotzdem hat man in der Praxis selten das Gefühl, dass Modularität wirklich erreicht wurde oder gar dauerhaft erhalten bleibt. Microservices und Self-Contained Systems sind nun die aktuellsten Paradigmen, die Modularität versprechen. Dieser Vortrag blickt auf zahlreiche Entwicklungs- und Renovierungsprojekte zurück, in denen auf Modularität hingearbeitet wurde. Er nimmt Modularität, die Ziele dahinter und die Probleme bei der Erreichung unter die Lupe. Microservices und Self-Contained Systems verdienen dabei als jüngste Hoffnungsträger hinsichtlich Modularität besondere Beachtung.

High Quality @ Short Time-to-Market: How the need for speed changes your software’s quality requirements and where you have to invest!

Shorter times for delivering new software products and updated versions are more and more common. Higher speed can provide substantial business value, but only if adequate quality can be delivered. In this article, we explain how the need for speed impacts your software’s quality requirements and why development time and operation quality requirements need strong improvement. Guidelines outline the areas where investment is needed to make high quality happen at short time-to-market. Finally, we will discuss applicable factors for significantly reducing release times.

I authored this article together with my colleague Frank Elberzhager from Fraunhofer IESE. It was originally published on the blog of Fraunhofer IESE.

Some years ago, it was quite normal to deliver a new release once or twice a year, or in even longer intervals. Today, updates are often released many times a week, sometimes even every few seconds. Internet companies are clearly the leaders of fast releases (e.g., Amazon made changes to production on average every 11.6 seconds in 2011, and many Google services are released several times a week, but more traditional companies like car manufacturers delivering safety-relevant products are following suit (e.g., Volvo cars).

When we say short time-to-market, we actually mean two things, but the focus is on the second one (because it is more challenging):

  • Delivering the first release within a short time between project start and first release
  • Delivering frequent subsequent updated releases within short times between start of increment and release

The key reason for short time-to-market is getting value earlier:

  • Customers can use your new features earlier – you can earn money earlier
  • You are on the market faster than your competitors – you can earn more money
  • You get faster feedback – you can further improve the software product or implement new feature requests from customers
  • You provide small updates instead of large ones – you can reduce the risk of providing the wrong software and you can reduce friction in development

This motivation to achieve shorter time-to-market is clearly business-driven (as it aims at providing business value), it is no end in itself, and you have to clearly identify the objectives to be achieved. Jan Bosch states this in drastic terms:

“No efficiency improvement will outperform cycle time reduction.”

Jan Bosch,

On the other hand, short time-to-market should normally not cannibalize the quality of the software system. High quality is important to convince customers of the value of the software product. Throwing a new product or release onto the market without proper quality assurance, documentation, etc. can speed up time-to-market, but it is not sustainable at all and thus not in the focus of this article (although it might be the right thing to do in exceptional cases).

Optimizing either delivery time or quality is challenging in itself. High quality at short time-to-market (HQ@STTM) is even more challenging, and not every company benefits equally from high-frequency releases, or would have to change too many things so that the investment would not be worth the benefit. So you should start asking the following questions, describing your goals:

  • What are the key reasons in your market and for your product to release it with short time-to-market?
  • What is a reasonable time-to-market that you want to achieve?
  • What is the level of quality that should not be affected?

These business-related questions have to be answered roughly first, followed by technical and organizational questions aimed at realizing the identified goals and checking the feasibility of achieving these goals. Many new questions emerge when striving towards shorter time-to-market, e.g.:

  • What does an efficient release process look like for you?
  • What architecture do you need?
  • What is the necessary infrastructure you have to provide?
  • What is a reasonable team structure you have to create?
  • What tools support your fast delivery?

In this blog article, we will give answers to the following questions about HQ@STTM:

  1. Why is HQ@STTM of any value at all? (see above)
  2. What exactly does high quality mean in this context?
  3. Where and how to invest for HQ@STTM?
  4. What is the applicability of HQ@STTM?

The following figure illustrates the answers and the transition towards HQ@STTM.

What exactly does high quality mean in this context?

The key reason why we build software is the functionality it realizes. However, only if this functionality comes with an adequate level of quality in the software is it actually useful. When we talk about HQ@STTM, we need a more precise understanding of high quality and thus distinguish four categories of quality characteristics of a software product (see Figure 1):

  • Absence of bugs
  • Runtime quality (e.g., performance, security)
  • Devtime (development time) quality (e.g., maintainability, testability)
  • Operation quality (e.g., updateability, recoverability).

The focus in development organizations is often on functionality, absence of bugs, and runtime qualities. This is quite natural because these quality characteristics are directly visible to the customer, while devtime quality and operation quality rather serve the development organization (in particular if it also operates the software). This is also backed by the ISTQB Worldwide Testing Practice Report from 2015 ), which revealed a focus on runtime qualities, such as performance, usability, or security.

If we talk about HQ@STTM, high quality thus also means absence of bugs and runtime quality. However, in order to be able to deliver these quality characteristics with high speed, it becomes inevitable to also increase devtime quality and operation quality!

  • Devtime quality is necessary to allow making additions and changes quickly (maintainability, extensibility, flexibility, …) and testing the changes with a high level of confidence within a reasonable period of time (which necessarily implies a large degree of automated testing).
  • Operation quality is necessary to enable reliable and fast releases with a high degree of automation and to quickly react to potential failures of the newly released software.

That is, the goal is to deliver absence of bugs and runtime quality to the customer, and the means for realizing this is to invest in devtime quality and operation quality. As functionality is available earlier, a slightly reduced amount of functionality might even be acceptable. Due to the ability to correct problems much faster than before, a bit more tolerance for bugs might exist. Figure 1 depicts this relationship. It is very important that all the people in a development organization have a clear picture of these different characteristics of quality and how they will change when they strive for more speed.

Where and how to invest regarding HQ@STTM?

HQ@STTM does not come for free. It is clearly a business value and a competitive advantage, and thus it is obvious that investments are needed. The previous section already pointed out two areas of quality that need strong improvement in order to realize HQ@STTM: devtime quality attributes and operation quality attributes.

In this section, we will broaden the view on areas of investment. We have identified four high-level areas that require investments in order to make HQ@STTM happen:

  • Culture / Organization: The people in the development organization have to be fully aware that fast releases have value and that everyone has to contribute. Changes to the organizational structure might be necessary to empower people to develop and release fast.
  • Architecture: The architecture of the software has to strongly support fast releases, that is, in particular the realization of development time and operation quality attributes (e.g., updateability, recoverability, testability, …) while maintaining the runtime quality attributes (e.g., performance, user experience, security, availability, …) at the same time.
  • Tools / Automation: Automation is key for fast releases with high quality: Only if quality assurance, build, and release are highly automated and reliable can releases be made with high confidence at high frequency.
  • Processes: Processes have to focus on full end-to-end coverage, from ideation of new features to putting them into production with low friction and delay.

The four areas that require investment are connected and overlap. In the following, we will provide more concrete topics and guidelines, which mostly touch several of these areas. (Take continuous delivery, for example: For continuous delivery, the software architecture has to cope with fast integration and deployment, and a full process needs to be defined with a high degree of automation.)

Concrete topics and guidelines supporting HQ@STTM:

  • Focus on customer and business value:
    • Focus on building the right software system that serves your customers and provides the highest value for your business.
    • Build as little as necessary; building less takes less time.
    • Consistently prioritize in requirements engineering.
    • Incorporate early feedback and data to enable continuous adjustment.
  • Focus on innovation and differentiation, use common features where possible:
    • Do not reinvent the wheel; do not invest your time into things that are already there.
    • Focus on the things that make your product and your business unique.
    • Use cloud-based technologies where possible.
    • Continuously renew: What is innovation today may be a common feature tomorrow.
  • Optimize release capability
    • Introduce continuous delivery, integration, and deployment for (partially) automated, and thus faster, releases.
    • Adopt DevOps practices; they aim at assuring smooth interplay between development and operation throughout the release step.
    • Design for updateability: provide the ability to run different software product versions; use effective API version management; migrate data; etc.
    • Modularize software to enable independent releases of features and software parts: Microservices are an architectural style that proposes many decisions supporting decoupled development and releases.
    • Make teams responsible for the development, release, and operation of their modules and create the ability to release independently (respect Conway’s law concerning the organizational structure).
  • Invest into high quality:
    • Do quality assurance early to avoid going in the wrong direction (prototyping, architecture evaluation, …).
    • Try out concepts and features early with a strong customer focus.
    • Design for high testability and, in particular, for a high degree of automated testing.
    • Design for robustness: provide the ability to keep failures local and to recover quickly in the case of failures.
    • Establish a culture of making even good things better over time.
  • Make the overall development organization agile
    • Establish a culture of speed and fast decisions.
    • Follow agile development principles and be responsive.
  • Utilize data to improve business and software
    • Perform A/B tests, for example, to get early feedback about alternative features and about the quality by gradually delivering the software to the customers.
    • Ask your users for (anonymous) feedback, respectively collect data from log files.

What is the applicability of HQ@STTM?

We believe that HQ@STTM will become more relevant for many industries and companies, as it offers a strong ability to create business value. HQ@STTM is nothing that can be bought out of the box. Rather, it is a deliberate business decision that comes with many consequences, changes, and investments. To make it happen, the company developing the software has to strongly adapt and invest into the areas of Culture/Organization, Architecture, Tools/Automation, and Processes.

The concrete manifestation differs from company to company, starting with different releases cycles and ending with the specific technologies being used. Such particular environmental factors have to be considered during the definition of a concrete migration and improvement strategy.

The following aspects have an impact on the applicability and the concrete definitions of HQ@STTM:

  • Adherence to quality standards and certifications: Whether high release cycles are possible can be determined by regulations concerning quality assurance and certification.
  • Customer expectations and ability to create value: Only if regular and fast updates are perceived to be accepted by customers and can result in business value are the investments into HQ@STTM justified.
  • Status of existing software: The age and overall quality of your software (in particular devtime quality and operation quality) have an impact on whether it is advisable to invest in HQ@STTM for the current software (or rather do it for a successor).
  • Control over execution environment: Companies offering software-as-a-service (SaaS) have the advantage that they have good control over the execution environment, while companies offering physical goods like cars might have to update their software in millions of hardware instances. However, even there, things might change as network capabilities are greatly improving, allowing more and more functions to be moved to a cloud-based environment.

If you want to move towards HQ@STTM, you should ask the following questions when you start your journey:

  • What does “high quality” mean for you? How do you interpret “short” in terms of time-to-market?
  • What is the respective improvement in value that you expect to gain?
  • What does this direction mean for your organization, your processes, your architecture, and your tools?
  • Which topics make the most sense to you to start with?

You should keep in mind that this is all about the balance between high quality and fast delivery, and you have to consider both and find the right balance. This means that it is about acceptable quality and acceptable release frequency. The guidelines presented in this article point out aspects to reason about, to prioritize, and to start introducing. They are deliberately not presented as a migration roadmap because your transition to HQ@STTM will be individual and thus requires your own individual migration roadmap.

Recommended literature for further reading:

  • Jan Bosch, „Speed, Data, and Ecosystems: Excelling in a Software-Driven World“
  • Len Bass, Ingo Weber, Liming Zhu „DevOps: A Software Architect’s Perspective“

On Tour: O’Reilly Software Architecture Conference 2017, London

Am 16.-18. Oktober findet in London The O’Reilly Software Architecture Conference 2017 statt. Wir freuen uns schon sehr, dabei wieder auf unterhaltsame Weise unseren Zuhörern nahezubringen, wie eng die Verbindung zwischen User Experience und Softwarearchitektur ist (oder sein sollte!):

How do Software Architects find the way to User Experience? With Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von Softwaresystemen. Unser Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Wir freuen uns auf spannende Tage mit inspirierenden Vorträgen, Begegnungen und Diskussionen. Alle Informationen zur Konferenz gibt es hier.

On Tour: Tutorial Architecture Evaluation @ ICSA 2017

Bei der ICSA 2017 in Göteborg halten Jens Knodel und Matthias Naab am 03. April ein Tutorial zur Bewertung von Softwarearchitekturen.

How to Evaluate Software Architectures:

Tutorial on Practical Insights on Architecture Evaluation Projects with Industrial Customers

Hier die offizielle Ankündigung und Beschreibung:

„Thorough and continuous architecting is the key to overall success in software engineering, and architecture evaluation is a crucial part of it. This tutorial presents a pragmatic architecture evaluation approach and insights gained from its application in more than 75 projects with industrial customers in the past decade. It presents context factors, empirical data, and example cases, as well as lessons learned on mitigating the risk of change through architecture evaluation.

By providing comprehensive answers to many typical questions and discussing lessons learned, the tutorial allows the audience to not only learn how to conduct architecture evaluations and interpret its results, but also to become aware of risks such as false conclusions, manipulating data, and unsound lines of argument.

The target audience includes both practitioners and researchers. It encourages practitioners to conduct architecture evaluations. At the same time, it offers researchers insights into industrial architecture evaluations, which can inspire future research directions.“

Das Tutorial basiert auf unserem Buch „Pragmatic Evaluation of Software Architectures“.

Wir freuen uns auf viele Teilnehmer und interessante Diskussionen.

Was ist eigentlich ein Softwarearchitekt?

Die Rolle des Softwarearchitekten wird je nach Unternehmen sehr unterschiedlich interpretiert und durch die jeweiligen Menschen noch unterschiedlicher ausgefüllt. Deshalb gibt es auch nicht DEN Softwarearchitekten.

Im Gegensatz zu anderen Rollen im Softwareengineering scheint jedoch die Bandbreite der unterschiedlichen Interpretationen viel größer zu sein. Deshalb verwundert es nicht, dass es zahlreiche Analogien aus anderen Bereichen gibt, um den Softwarearchitekten, das unbekannte Wesen, etwas greifbarer zu machen. In vielen Präsentationen zu Softwarearchitektur sieht man immer wieder solche Analogien. Gregor Hohpe und Rebecca Whirfs-Brock haben mich mit ihren Vorträgen bei der OOP 2017 inspiriert, eine (sicherlich unvollständige) Aufstellung von Charakterisierungen zu machen.

  • Architekt als Generalplaner: Der Architekt plant alles ganz genau voraus und macht dann den Entwicklern klare Vorgaben bezüglich der Umsetzung. Er ist als einzelne Instanz, die über die Integrität des Gesamtsystems wacht, unabdingbar. (Siehe Martin Fowler, Architectus Reloadus)
  • Architekt als Gärtner: Der Architekt gibt Leitplanken vor, wie ein Gärtner einen Garten strukturiert. Darin wächst dann alles eigenständig und der Architekt beobachtet den Fortschritt und greift korrigierend ein.
  • Architekt als Mentor und Coach: Der Architekt versteht sich als Kümmerer im Projekt und klinkt sich immer wieder an unterschiedlichen Stellen ein. Er hilft Kollegen und unterstützt sie, auch bei Implementierungsaufgaben. Dadurch hat er einen sehr guten Überblick über das gesamte System und ist sehr nah an der Entwicklung dran. (Siehe Martin Fowler, Architectus Oryzus)
  • Architekt als Reiseführer: Der Architekt nimmt andere Rollen in der Entwicklung mit auf eine Reise und kann zu allem etwas erläutern.
  • Architekt als Barkeeper: Der Architekt mixt verschiedene Dinge zusammen: Insbesondere Business und Technologie. Dabei versteht er das Business und zeigt durch die Technologie neue Möglichkeiten auf, die er dann auch realisieren kann.
  • Architekt im Aufzug, Architekt als Mediator: Der Architekt ist in einem Aufzug unterwegs, der zwischen verschiedenen Stockwerken eines Unternehmens fährt. Diese Stockwerke symbolisieren alles von der Entwicklung bis zum Vorstand. Ein Architekt wird dadurch charakterisiert, wie viele Stockwerke er fahren kann, das heißt auf welchen Ebenen er mit den Menschen sprechen kann und auch zwischen den verschiedenen Ebenen vermitteln. Das bezieht sich einerseits auf die Fähigkeit, zwischen Abstraktionsebenen zu springen und andererseits auf die Fähigkeit mit Menschen unterschiedlicher Profession in der Sprache zu sprechen.
  • Architekt als Verkäufer von Optionen, Architekt als Ökonom: Der Architekt betrachtet die Architektur als Menge von Entscheidungen mit ökonomischem Einfluss auf die Entwicklung und die Zukunft des Softwaresystems. Insbesondere ermöglicht der Architekt es, bestimmte Änderungen am System in der Zukunft kostengünstig machen zu können. Dadurch sind in der Gegenwart Investitionen nötig (ähnlich wie bei Optionsscheinen, die es einem erlauben, in der Zukunft bestimmte Geschäfte zu einem festgelegten Preis zu tätigen).
  • Architekt als Stammesältester: Der Architekt als Respektsperson, die aufgrund ihrer Historie und Verdienste einen hohen Einfluss und Anerkennung genießt.
  • Architekt als Pfadfinder: Der Architekt als Entdecker neuer Wege mit einem Sinn für gute Taten.
  • Architekt als Designer: Der Architekt als Gestalter eines Softwaresystems, der wichtige und weitreichende Entscheidungen über das System trifft.
  • Architekt als Phantombildzeichner: Der Architekt als „Extrahierer und Dokumentierer“ von existierender Softwarearchitektur. Wenn Zeugen einen Verbrecher gesehen haben, so können sie ihn oft zumindest grob beschreiben, obwohl sie nie in der Lage wären, ihn zu zeichnen. Diese Aufgabe kommt dem Phantombildzeichner zu, der fundiertes Wissen über die menschliche Anatomie hat und die Kunst versteht, Informationen den Menschen zu entlocken und zu dokumentieren. Die gleiche Rolle können gute Softwarearchitekten einnehmen. Mit ihrem fundierten Wissen über Architektur und Dokumentation können sie gemeinsam mit Entwicklern Informationen extrahieren und geeignet dokumentieren. Obwohl es nicht direkt zu erwarten ist, können viele Entwickler und sogar viele Softwarearchitekten ihre Architektur nicht gut visualisieren, dokumentieren und kommunizieren. Deshalb ist der Phantombildzeichner oft sehr hilfreich.

Gregor Hohpe @ OOP 2017: Architekt als Phantombildzeichner

  • Architekt als Technologieexperte: Der Architekt als Kenner von Technologien in einem bestimmten Technologiebereich. Diese Übersicht erlaubt ihm, Technologien zu identifizieren, zu bewerten und auszuwählen.
  • Architekt als Domänenexperte: Der Architekt als Kenner der Domäne, für die ein System entwickelt wird.
  • Architekt als Möwe: Der Architekt stürzt sich auf ein bestimmtes Thema herab, wirbelt dort einigen Staub auf und fliegt dann wieder von dannen J
  • Architekt als Astronaut: Der Architekt bewegt sich in ganz anderen Sphären und ist so weit von der Entwicklung weg, dass er kaum was über den System weiß, wenig Einfluss hat und bei den Entwicklern wenig Wertschätzung erfährt.
  • Architekt im Elfenbeinturm: Der Architekt ist eher wissenschaftlich angehaucht und schottet sich von der eigentlichen Entwicklung ab. Damit geht es ihm so ähnlich wie dem Astronauten.
  • Architekt als Powerpoint-Künstler: Der Architekt als Ersteller von schönen Powerpoint-Bildern, die mit der Realität (dem Code) häufig wenig zu tun haben und ihm deshalb bei Entwicklern wenig Respekt einbringen.

Diese Analogien greifen akzentuiert bestimmte (positive wie negative) Eigenschaften des Softwarearchitekten heraus und machen sie verständlich. Letztlich dürfte natürlich keine der Analogien einen Softwarearchitekten wirklich komplett beschreiben und sie schließen sich auch nicht gegenseitig aus. Sie erläutern aber sehr gut verschiedene Persönlichkeitstypen und verschiedene Arbeitsauffassungen.

Da es auch keine einheitliche Definition von Softwarearchitektur gibt, ist es natürlich kein Wunder, dass auch bei Softwarearchitekten keine einheitliche Auffassung existiert. Die Vielfalt der Analogien sollte aber sowohl Softwarearchitekten selbst helfen, über ihr Tun zu reflektieren und anderen Personen die Gelegenheit eröffnen, Softwarearchitekten besser zu verstehen.

Unabhängig von der Analogie scheint Softwarearchitekt aber ein toller Job zu sein. Zum wiederholten Male landete er bei „Best Jobs in America (CNN Money)“ auf dem ersten Platz :-).

CNN Money: Best Jobs in America (2015)

Die Liste mit Analogien für Softwarearchitekten ist bestimmt noch viel länger und darf gerne in den Kommentaren ergänzt werden!

On Tour: OOP 2017, München

OOP 2017

Wir freuen uns sehr, bei der OOP 2017 als Sprecher dabei sein zu dürfen. Mit 8 Tracks zu spannenden Themen rund um Softwareentwicklung verspricht die OOP wieder ein echtes Highlight zu werden.

Who is engineering the Software, which is eating the world?

Software revolutioniert fast jede Art von Business durch neuartige Ökosysteme. Die Erstellung erfordert Kompetenzen, die weit über das klassische Systems- und Software-Engineering hinausgehen. Zentrale Herausforderungen sind höhere Komplexität bei kürzerer Time-To-Market, geteilte Verantwortung und Kontrolle über mehrere Unternehmen und Domänen hinweg sowie die immer höher werden Anforderungen an Sicherheit, User Experience, und andere Qualitäten. Wir charakterisieren Softwareökosysteme und zeigen notwendige Kompetenzen, um diese zu bauen.

Ereignisorientierung im App-Ökosystem – Architekturdetails als Garant für erfolgreiche Integration

Ereignisorientierung ist in vielen Aspekten für IoT-Systeme geeignet, weil reale Ereignisse verarbeitet werden. Die passende Architektur und Implementierung ist aber alles andere als offensichtlich und erfordert, dass sich Architekten und Entwickler gemeinsam um viele Details kümmern. Wir zeigen Lösungen für ein skalierbares und erweiterbares App-Ökosystem mit Logistikfokus: Error Handling, Schnittstellen, Daten- und Eventmodellierung mit Generierung von Entwickler-spezifischen Sichten, Einfluss auf die Clients und Umsetzung in AWS mit Reactor.

Dieser Vortrag ist zusammen mit unserem Kollegen Balthasar Weitzel.

Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen. Hier geht es zum vollständigen Konferenzprogramm.

ältere Beiträge

© 2017 mibinu

Theme von Anders NorenNach oben ↑