In vielen Institutionen gibt es noch jede Menge Software, die monolithisch aufgebaut ist und von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. Doch mal eben Kubernetes einzuführen ist eine gewaltige Aufgabe. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud Native betrachten und dabei (OpenSource) Werkzeuge kennen lernen für die schrittweise Anpassung der (on-premise) Infrastruktur, ohne Kubernetes.

Zielpublikum: Architekt:innen Entwickler:innen, DevOpser, Manager:innen, Entscheider:innen
Voraussetzungen: Grundverständnis verteilter Architekturen
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In vielen größeren Institutionen gibt es noch jede Menge Software, die eher monolithisch aufgebaut ist, die häufig in Applikation-Servern auf dedizierten virtuellen Maschinen von einem eher klassisch aufgestellten und organisatorisch separierten IT-Betrieb betrieben wird. In Fachzeitschriften, Online-Artikeln und Konferenzen wird vorgeführt, wie einfach es doch ist, einen Hello-World Spring Boot Microservice mit mehreren Instanzen auf Kubernetes zu deployen. Doch zurück im Unternehmen wird klar: Sollte man es tatsächlich schaffen, alle notwendigen Personen davon zu überzeugen, ab sofort Kubernetes einzuführen, wird das für einen meist auch personell am Limit arbeitenden IT-Betrieb schnell zu einem Projekt mit vermutlich 1-2 Jahren Laufzeit (je nach Erfahrung), mit möglichen Seiteneffekten wie reduzierter Handlungsfähigkeit für das laufende Geschäft und dem Zurückstellen anderer Modernisierungsmaßnahmen. In diesem Vortrag werden wir die sich kontinuierlich entwickelnde (evolving) Architektur einer Anwendungslandschaft hin zu Cloud-native betrachten und dabei mehrere spezielle Open-Source-Werkzeuge kennenlernen für die schrittweise Anpassung der on-premise Infrastruktur, ohne Kubernetes.

How much can you separate what you are building from how you are building it? This becomes an increasingly relevant question with IT moving from building systems to cultivating ecosystems. At the enterprise architecture level, one of the challenges nowadays is to decide which constraints to put in place to get a robust and evolvable landscape of interacting components, while at the same time it is important to minimize these constraints so that teams and units have some autonomy, and that the overall architecture can evolve continuously.

Target Audience: Interest in enterprise & software architecture and in digital transformation
Prerequisites: None
Level: Advanced

Extended Abstract:
In this presentation, we look at this interesting challenge from the standpoint of APIs, and how they can help to reduce the constraints to the necessary ones, while still resulting in an effective architecture.

One of the main challenges of enterprise architecture and software architecture today is to move from building systems to cultivating ecosystems. With business and IT moving closer together, and the demands on businesses to become better at changing and adapting, this introduces new constraints into architecture that looked different when the main goals were mostly centered around being secure, robust, and efficient.

Ecosystems exhibit different qualities from systems in the sense that they afford more autonomy to components, while at the same time introducing models of fitness and continuous change. With today's demand on business and IT to become faster and more effective at changing, the question is how to reflect those demands in new practices and models for architecting. We argue that one way of doing this is to focus on constraints, and to also focus on minimizing the constraints so that components can adapt and evolve as freely as possible.

We present a model of how to address API issues in the four areas of strategy, program, platform, and products. The goal of this model is to have as much coordination and alignment between these areas as necessary. The way this is done is by having clearly structured guidelines that represent and communicate the constraints, and that always clearly explain the rationale, the constraint itself, as well as possible ways how to comply with the constraint and how to test for compliance. The goal of this is to create loose coupling while still having a structure that allows governance. While in practice it would be ideal to fully automate all tests so that governance can be done in a full self-service model, so far we have concluded that automated testing is a good goal to have, but that some constraints still need a process of human review and approval.

Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen abgeleitet.

Zielpublikum: Solution-, Enterprise-Architekt:innen, CTOs, interessierte Manager:innen
Voraussetzungen: Erfahrung in der Entwicklung größerer Systeme und Systemlandschaften
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen, sich bietende Möglichkeiten wollen rasch genutzt werden. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Dazu werden organisatorische, methodisch/agile und technische Trends der IT-Industrie eingeordnet. Es entstehen sechs Themenblöcke, mit denen sich wandelnde Unternehmen in den letzten Jahren viel beschäftigt haben. Experimentierkultur und empirische Prozesse zu stärken, technisches und organisatorisches Feedback auf allen Ebenen zu fördern, oder auch gut gelebte Transparenz und die Öffnung von einst etwas "elitären" Architekturdiskussionen sind einige Beispiele, die ich diskutieren werde.

Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen der eigenen Arbeit abgeleitet. Ein paar Mythen der EA-Disziplin könnten am Weg leiden.

Architecture work is all about trade-offs. We weigh security against ease of use, we balance availability with maintainability and contrast performance with reliability. But how do we evaluate the cost and benefits of change? As architecture is a means to an end, not an end in itself, architectural improvements have to be governed by sound reasoning, and more often than not that has to be based on numbers. Which in turn implies the need for good practices for the financial evaluation of technical decisions. Here we'll explore a dozen of these.

Target Audience: Software architects, developers, managers
Prerequisites: Some experience with real world architectural and design decision (even without putting numbers on them)
Level: Advanced