Menu
Everyone is talking about APIs, be it simple services or complete ecosystems that you want to expose via API. With all the tooling available, that is quite easy, is the first thought. But it is not. The challenge of an API is not its implementation, but its design: What needs to go into the API, what do I leave out? How do I present it in a way that users find it good? What else do I need to take into account if I want my API to be a success? In this workshop we will examine several API design anti-patterns and figure out what is needed to turn them into good design. Where needed, we will intersperse a bit of theory to fill our tool box. And we will take the time to create alternative designs together. This way, we will learn good functional API design step by step – aha-experiences included.
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speaker will start after lunch break each day due to the time difference.
When building modern architectures, the hard part isn’t learning Kubernetes. The hard part is changing the way (almost) everyone thinks. If we don’t transform our mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are. Everyone can develop confidence in the thinking they facilitate. To develop trustworthy thinking, we need to practice argumentation: reasoning systematically in support of an idea, action, or theory. This systemic reasoning is the key to all transformational success because it delivers Integration Leadership. We apply this leadership as: – a method of inquiry – a skill we must practice – the integration of differing points of view – good judgement – the process of enabling others to make up their own mind Systemic reasoning enables people to communicate about systems, collectively arriving at the best possible solution, under the circumstances, when conditions are uncertain. (Conditions are always uncertain.) Developing this skill contributes more value than our technology-specific expertise. In this workshop, we’ll explore methods for providing integrative leadership by crafting sound reasoning, together. Feedback from previous workshops: ” I am often involved in such discussions as receiver of arguments and in most cases the offered solution only solves symptoms, doesn’t go deep enough. Now I have an advice ready why and how to go deeper.” “I went in with something that was more of a vague frustration for me and ended up with a well-organized argument that I’d feel comfortable bringing up with anyone.” “It changed my way of thinking and challenging others”
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speakers will start after lunch break each day due to the time difference.
Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class is divided into 2 main parts. Pulling things apart (Part 1) focuses on how to break up systems and identify levels of modularity. However, once you’ve broken apart your systems, how do you tie them back together? Putting them back together (Part 2) focuses on just this – the techniques of how to do contracts, orchestration, workflows, and transactions, while keeping everything loosely tied together and running smoothly.
Functional Software Architecture is architecture using functional programming. Not everything is different, but almost. Primarily: – pervasive use of immutable data / value objects – documented and controlled side effects – higher-order abstractions, based on math – combinator models These four building blocks make for architecture that is more robust and more flexible than traditional OO architecture: fewer dependencies, better reuse, less complexity. Moreover, the abstraction facilities in FP are more powerful, affording better models that are closer to the domain, come with less technical overhead, and can dredge hidden domain knowledge to the surface. This all works well with the strategic patterns of DDD. The workshop gives an introduction with examples that you can follow along.
Architecture documentation is very often treated stepmotherly. Yet documentation supports the design work and creates transparency and guard rails for the implementation and maintenance of the software architecture. On the one hand, it is not simple however to hold the important information from the draft of the software architecture structured and easily understandable. On the other hand, most attempts in search of practicable handling for creation and maintenance end in the WYSIWYG hell of a word processor or the deep maw of a wiki. Building on lightweight tools and text formats, this workshop shows how to create documentation that is as redundancy-free as possible and can be delivered in appealing formats optimized for different target groups. With the help of many practical exercises, the seminar deals with concepts such as Continuous Documentation and Documentation as Code. The goal is modern, effective, and pragmatic documentation of software architecture. We build on proven methods, formats, and tools like AsciiDoc/Markdown, PlantUML, docToolchain, Maven/Gradle, jqAssistant, and many more. In detail, we take care of the automation of the documentation build process, the generation of content from the model, database schema or source code, the structured storage including versioning and historicization, and the use or creation of meaningful and easily maintainable graphics. Agile development teams can thus integrate documentation work into their daily tasks and deliver up-to-date, comprehensive, and well-structured results at any time. In addition, the creation of documentation can be integrated into the review process and thus constantly improved and further developed.
Did you ever experiment tension between different people inside of an organisation, with regards to design strategies? On one field, the Enterprise Architects and their business capabilities, and on the other side the Domain-Driven Design practitioners with their patterns? Endless hours of discussion about the design strategy, leading to waste and polarisation. What if we could combine these two worlds? Are they so different? Join us on this hands-on, where we will work a serious of exercises where you can leverage business capabilities modelling and strategic Domain-Driven Design patterns to model different functions inside of an organisation. You will learn on to move from the different methods while leveraging the strengths of each other. Leveraging those perspectives, you can start modelling based on intention, creating highly autonomous agents, whilst aligned with the organisation purpose and mission. If your role is architect, line manager or you just want to gain experience in modelling at the enterprise level, then this is the right spot. We will model a use case, and walk through several scenarios where we apply the different modelling techniques. Previous knowledge of Strategic Domain-Driven Design and Enterprise Architecture is welcomed, but not required. You will leave the hands-on with a toolset that will allow you to apply to your product portfolio, creating sensible boundaries.
Distributed data-intensive systems are increasingly designed to be only eventually consistent. Persistent data is no longer processed with serialized and transactional access, exposing applications to a range of potential consistency and concurrency anomalies that need to be handled by the application itself. Controlling concurrent data access in monolithic systems is already challenging, but the problem is exacerbated in distributed systems. To make it worse, only little systematic engineering guidance is provided by the software architecture community regarding this issue. Susanne shares her experiences from different case studies with industry clients, and novel design guidelines developed by means of action research. In this hands-on workshop you will learn settled and novel approaches to tackle consistency- and concurrency related design challenges. After the workshop you will know how to use them in practice, and in combination with Domain Driven Design (DDD). The goals of this workshop are: • You learn the most fundamental basics of ACID transactions, distributed transactions, Sagas, Multilevel Transactions, Eventual Consistency, Conflict-Free-Replicated Data Types (CRDTS), ACID 2.0 and the CALM Theorem.
• You learn the general recommendations of DDD in relation to consistency, transactions and concurrency control. • You learn and practice novel design guidelines and patterns extending the DDD philosophy. These will enable you to design distributed data-intensive systems in such a way that you can exploit the benefits of eventual consistency, and at the same time avoid its common pitfalls. Workshop participants should already have some basic knowledge in distributed systems, database transactions and DDD.
In Domain Driven Design it is important to focus on commonalities. The ubiquitous language was also developed for this purpose.The exclusive focus on commonalities, however, often leads to the separation and categorization of stakeholders – a good ground for stereotyping processes and conflicts. Focusing on differences and similarities at the same time promotes constructive relationships and trust. In Domain Driven Design, it is therefore helpful to work with a diversity understanding of differences and commonalities. This is because looking at the similarities and differences very often makes it easier to deal with differences in the expectations of the IT system. In this workshop, we will use a practical example to illustrate the extent to which an understanding of diversity is a success factor for DDD.
Aino will share her experiences with distributed retrospectives; those that went well as well as those which did not go well. She will describe what worked in those that worked and what did not work in those that did not. You will come away with things to be aware of when preparing a distributed retrospective, how to organise it, how to prepare it and how to facilitate it during the retrospective in a virtual setting. There will be links to different technologies also, but also an opportunity to ask questions and share your own experiences.
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speaker will start after lunch break each day due to the time difference.
When building modern architectures, the hard part isn’t learning Kubernetes. The hard part is changing the way (almost) everyone thinks. If we don’t transform our mental models and communication patterns, we will deliver the exact same system we already have. Regardless of how performant our microservices are. Everyone can develop confidence in the thinking they facilitate. To develop trustworthy thinking, we need to practice argumentation: reasoning systematically in support of an idea, action, or theory. This systemic reasoning is the key to all transformational success because it delivers Integration Leadership. We apply this leadership as: – a method of inquiry – a skill we must practice – the integration of differing points of view – good judgement – the process of enabling others to make up their own mind Systemic reasoning enables people to communicate about systems, collectively arriving at the best possible solution, under the circumstances, when conditions are uncertain. (Conditions are always uncertain.) Developing this skill contributes more value than our technology-specific expertise. In this workshop, we’ll explore methods for providing integrative leadership by crafting sound reasoning, together. Feedback from previous workshops: ” I am often involved in such discussions as receiver of arguments and in most cases the offered solution only solves symptoms, doesn’t go deep enough. Now I have an advice ready why and how to go deeper.” “I went in with something that was more of a vague frustration for me and ended up with a well-organized argument that I’d feel comfortable bringing up with anyone.” “It changed my way of thinking and challenging others”
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speakers will start after lunch break each day due to the time difference.
Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class is divided into 2 main parts. Pulling things apart (Part 1) focuses on how to break up systems and identify levels of modularity. However, once you’ve broken apart your systems, how do you tie them back together? Putting them back together (Part 2) focuses on just this – the techniques of how to do contracts, orchestration, workflows, and transactions, while keeping everything loosely tied together and running smoothly.
The microservice architecture functionally decomposes an application into a set of services. Each service has its own private database that’s only accessible indirectly through the services API. Consequently, implementing queries and transactions that span multiple services is challenging. In this tutorial, you will learn how to solve these distributed data management challenges. I will share with you how to implement transactions using sagas, which are sequences of local transactions. You will learn how to coordinate sagas using either events or command messages. I will also explore how to implement queries using the API Composition and Command Query Responsibility Segregation (CQRS) patterns.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
