Please note:
On this site, there is only displayed the English speaking sessions of the OOP 2021 Digital. You can find all conference sessions, including the German speaking ones, here.
Theme: Architecture
- Monday
08.02. - Tuesday
09.02. - Wednesday
10.02. - Thursday
11.02. - Friday
12.02.
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session.
Maximum number of participants: 75
Target Audience: Architects and Developers
Prerequisites: Java Programming
Level: Advanced
Extended Abstract:
Applications, services, and systems are changing out of necessity because of the kinds of platforms that are available today: distributed and multi-core. Have you been curious about Reactive Architecture and Programming but haven't had time to dig in? Join this session and you will be in a good position to put Reactive to use on your projects. We will start from foundational building blocks and scale up to full Reactive implementations. If you bring your laptop and Java 1.8+ or C# for .NET Core 2.1+ you can try out Reactive during the session.
Some architecture decisions are more consequential and higher impact than others, and need to be preserved. We work on systems where the architecture is too large for each person to hold all the details in their head. New team members struggle to understand what they need to know about the architecture. Current team members have challenges knowing what architecture decisions were made, by whom, and for what reason. Architecture Decision Records (ADRs) are a useful, agile, lightweight approach to tackling these, and other challenges.
Target Audience: Anyone who affects, or is affected by architecture decisions
Prerequisites: Some experience in software design and architecture would be beneficial
Level: Advanced
Extended Abstract:
Are you working on a system where the architecture is too large for each person on the team to hold all the details in their head for all time? Do new team members struggle to understand what they need to know about the architecture? Do current team members have challenges in knowing what architecture decisions were made, by whom, and for what reason? Some architecture decisions are more consequential and higher impact than others, and need to be preserved.
The right level of architecture documentation supports agility. Architecture Decision Records (ADRs) are a useful, lightweight approach for this. Often no more than a page in length, they capture the key decisions that we need to remember. This hands-on session shares experiences with ADRs, giving you a set of tools to be successful in your team.
Through this interactive session we will explore these questions together:
What are Architecture Decision Records (ADRs) and why are they useful?
How do ADRs promote or help agility?
What are the motivations that led to trying ADRs for preserving decisions?
What are some scenarios and examples where ADRs are helpful?
What kinds of decisions should we record with ADRs, and why?
What are some of the cultural challenges associated with using ADRs, and how do we address them?
This session provides participants with hands-on practice of creating and reviewing ADRs. The session draws from experiences with multiple large-scale, global organisations and system architectures, and builds on established work with ADRs from other authors and practitioners.
Vortrag Teilen
The growth of Kafka inside an organization sometimes follows the development of the broader Kafka ecosystem over its lifetime. The initial use case may be something conceptually simple, like mainframe offload or point-to-point integration, evoking the simple Large Pipe architectures of Kafka’s infancy. Then those newly populated streams of events present themselves as fertile grounds for real-time analytics, as stream processing applications grow up around them to perform analysis event-by-event, leaving behind legacy ETL processes and their long batch times. Finally, a rich set of event streams gradually comes to describe more and more of the evolving state of the business, forming the substrate on which an ecosystem of event-driven microservices can thrive.This growth in architectural sophistication of an organization’s Kafka usage mirrors the development of those same concepts in the Kafka community over the past decade. In many cases, the process can be played forward at an accelerated rate as leaders draw on lessons learned and concepts developed by the community. This talk traces this development, ending with a comprehensive vision of an event-driven architecture suitable for the next generation of information technology deployments. You’ll leave knowing where you need to go and how this new architectural paradigm will help you get there.
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.
Vortrag Teilen
SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced
Extended Abstract:
It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":
(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.
(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.
(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call.
(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency.
(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling.
(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.
We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).
Vortrag Teilen
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
Vortrag Teilen
Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? Polarities cannot be solved, only managed. With polarity mapping we manage that polarity and go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.
Target Audience: Architects, Developers, Decision Makers, CTO, Tech Leads, designers, facilitators
Prerequisites: None
Level: Advanced
Extended Abstract:
Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? And the moment you think you solved it they come back again. The thing is, polarisations like these cannot be solved, like breathing in and breathing out but need to be managed. If we don't, we will make compromises or stay in one polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.
In this session, we will interactively expose you to polarity thinking. We will explore how to identify polarities and how we can start managing them with Barry Johnson Polarity Mapping. We will take a common polarity in software design, like too much vs too little upfront design, mob/pair programming vs programming in isolation, and planning vs taking action. By filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.
Vortrag Teilen
Modern architectures (e.g. event-driven and reactive) will gain more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, many companies don’t update their business processes to reflect this. I’ll give an example and discuss the consequences, motivating you to advocate for a redesign of your business processes internally. Too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.
Target Audience: Architects, Developers, Business Analysts
Prerequisites: Experiences with software architecture
Level: Advanced
Extended Abstract:
There is a lot of buzz around reactive architectures. Take, for example, event-driven architectures, event-streaming or reactive programming. These architectures will gain more and more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, I see many companies that don’t update their business processes to reflect this new world. In this talk, I’ll give an example and discuss the consequences, hopefully motivating you to advocate for a redesign of your business processes internally–because too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.
This talk will examine principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. It is important to commit to "stop adding to the monolith" - all new code is added as microservices; the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, when writing new microservices code, it is important to avoid dependencies to the monolith.
Target Audience: English, Developers, Architects, QAs, Testers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced
Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, focus on features provides a lot of value and starting with a monolith architecture can be advantageous. However, over time, although you might be committed to keeping the code clean, and having lots of tests — the architecture can become harder to evolve. Ultimately technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. Also, evolving the system quickly can become harder. If things are changing quickly with lots of teams, evolving using the microservices architectural style can have many possible benefits.
Many Microservices architectures start from the evolution of a Monolith system by gradually applying the microservices architectural style. There are considerations and principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. There are good principles that help with this evolutionary process. For example, it is important to commit to "stop adding to the monolith" - all new code is added as microservices. This is the core of the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, there might be important pieces of the monolith that are getting hard to maintain and you want to pull these out. When this happens, you find design seams within the monolith, refactoring these out to components, that can ultimately be replaced with microservices. Early on, it is ok to create macro services first and then evolve (refactor) them to microservices. Also, when writing new microservices code, it is important to avoid dependencies to the monolith. Finally, you can use DDD modeling to identify aggregates and bounded contexts to pull them out from the monolith. This talk will examine various patterns when evolving from the monolith to microservices specifically with variations of the Strangler Pattern.
Vortrag Teilen
Over the history of software systems, the way we build such artifacts, the way we design them, the way we express them have evolved in seemingly disruptive ways. Even today, the pendulum swings between low ceremony agile methods to more rigid waterfall-ish ones; from big balls of mud to microservices and then back to big balls of microservices. In this talk, we'll examine the past, the present, and the future of software architecture: the role it plays in software systems, and the timeless fundamentals that remain across the fullness of time.
The problem at hand is partly the application of software engineering best practices to AI, but more so the evolution of software engineering to attend to software-intensive systems that contain AI components. In this lecture, I'll examine both dimensions: emerging AI architectures, neuro-symbolic systems, designing/testing/deploying/refactoring/maintaining systems with AI components; the future of software engineering.
Target Audience: Software engineers
Prerequisites: Curiosity and a desire to think different
Level: Advanced
Vortrag Teilen
DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in with DevOps you need to provide a “Quality Delivery Pipeline” to assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
Target Audience: English, Developers, Architects, QAs, Testers, Product Owners
Prerequisites: Basic Understanding of architecture and microservices and familiarity with DevOps
Level: Advanced
Extended Abstract:
Many software development processes such as Agile and Lean focus on the delivery of working software that meets the needs of the end-users. Many of these development processes help teams respond to unpredictability through incremental, iterative work cadences, and through empirical feedback. There is a commitment to quickly deliver reliable working software that has the highest value to those using or benefiting from the software. DevOps has become a common practice to assist with quality delivery in these practices, specifically when developing using the microservices architectural style. DevOps as a software engineering practice unifies software development (Dev) and software operation (Ops). To assist with quality delivery in these practices you need to provide a “Quality Delivery Pipeline” to help assure the delivery meets the requirements and proper validation and checks are done before releasing into full production. At the end of the pipeline the validated system will be deployed into production. There are various deployment techniques to help successfully and reliably deploy more quickly. The goal is to give confidence by providing "reliable, working software" to the user (making the user confident in the system). Also, the teams will have more confidence the system is working. This talk will focus on the “Quality Delivery Pipeline” as a practice that can help sustain delivering with confidence by addressing important qualities in the pipeline.
Vortrag Teilen
Service-orientation seems to be in vogue again, this time dressed up as microservices. Many seem to get going with very little plan and thought, running the risk of sliding down the slippery slope towards distributed monoliths. Some experts try to encourage domain-driven design, but that may confuse even more. We crave more guidance. Maybe the classic business capability maps could help?
Target Audience: Architects, developers
Prerequisites: Some experience with modularisation and enterprises
Level: Basic
Extended Abstract:
Service-orientation is still a surprisingly hard and complicated endeavour after all these years and the risk of getting it wrong, potentially ending up with a distributed monolith with its tight coupling, fragility, and high cognitive load, is still very real to many. Our industry is fairly immature and moves so fast that internalising acquired knowledge seems difficult and we often go through cycles of re-discovery of findings made decades ago. Maybe some SOA practitioners from the previous attempts made some breakthroughs that we have missed as we now have another go with microservices?
The concept of business capabilities from business architecture can be one approach to take a closer look at, with its holistic outside-in perspective of the company. The capability vantage point inherently abstracts away the 'what' a company does from the 'how' , describing the essence of what the business offers. In this talk we will take a closer look at what they are and what they can help us with, all the way from business strategies and analysis, via organisational design to data management and technical design. They may just be the tool we need to design services, micro or not, as parts in a business aligned sociotechnical system, where people, information, processes, and technology are jointly driving business outcomes.
Vortrag Teilen
When we look at where we are now with software development and applications, we can see the roots of today's world in the past. Ideas in current practice are not new, they are just more popular — machine learning, (micro)services, DevOps, Agility, etc. And some things have always been promised as revolutionary but have never taken centre stage, such as the story of CASE tools, MDA, AOP and generative programming. We trace back through time to examine these trends so that we can go forward. What are we seeing now that will be our future?
Target Audience: Anyone interested in developing and delivering software
Prerequisites: Experiences in software architecture and development
Level: Advanced
Extended Abstract:
Science fiction author William Gibson said that "The future is already here — it's just not very evenly distributed." When we look at where we are now with software development and applications, we can see the roots of today's world in the past. Ideas in current practice are not new, they are just more popular — machine learning, (micro)services, DevOps, functional programming, Agile development, etc. And some things have always been promised as revolutionary but have never taken centre stage, such as the story of CASE tools, MDA, AOP and generative programming. We trace back through time to examine these trends so that we can go forward. What are we seeing now that will be our future?
Vortrag Teilen
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. However, to be successful organisations need to have the correct boundaries for the microservices. Using the bounded context pattern from Domain-Driven Design it is possible to achieve team autonomy!
Maximum number of participants: 24
Target Audience: Architects, Developers, Testers, Analysts, Product Owner, Manager, Decision Makers
Prerequisites: None. It is an interactive workshop, with brown paper, post-its and whiteboards
Level: Basic
Extended Abstract:
There is an industry trend where businesses are moving towards autonomous product teams. These teams aim to be end-to-end responsible for the product they are building and maintaining. With the help of Continuous Delivery, teams have faster feedback cycles in which they can probe if a certain feature works. To achieve end-to-end team autonomy, companies move towards a microservices architecture to successfully inspect and adapt. To be effective with a microservices architecture, we require Conway's alignment, engineering teams aligned to business models/products; to achieve Conway’s alignment it’s required to design and model the domain. Domain-Driven Design’s bounded context is the essential pattern that helps to create Conway’s alignment.
Join us in this hands-on session where we show you how visual collaboration is the most effective way in co-creating sustainable Conway’s alignment. We will distil bounded contexts with visual collaboration tools Big Picture EventStorming, Context Mapping and the Bounded Context Canvas.
With visual collaboration:
- We create a shared understanding of the business flow, uncovering inconsistencies and competing goals
- Using the Theory of Constraints, we can discover, highlight and create a shared vision and strategy to focus our effort
- A critical part of doing visual collaboration is effective facilitation, especially facilitating workshops with +30 people at the same time
You leave our session understanding that to be effective with microservices, you need to start discover and design bounded contexts. You will learn heuristics that guide you in using visual tools in specific situations, and how to move on towards microservices.
Vortrag Teilen