Episodit
-
Systems thinking is the macro behaviour that we must understand in analyzing our world. A system always produces what it is designed to do, even if that isn't at all what we meant it to do!
Systems are self-maintaining, and contain balancing and/or reinforcing feedback loops.
We'll look at how these work, and what happens when they fail. You'll see how to apply systems thinking to the systems that are all around us.
This is an introductory talk to the world of Systems Thinking, condensed into 45 mins plus time for questions at the end.
-
From example mapping, to BDD, to DDD practices like event storming and domain storytelling, we're fortunate to have a wide range of tools for collaboratively building domain knowledge and creating models of those domains in software.
One gap that many organisations experience is the management of that domain knowledge over time. Domains evolve. Team members learn new aspects of the domain, or invent more useful models. Team members leave - taking knowledge with them, and new members join but never get the chance to participate in foundational collaborative modelling sessions.
Living documentation is a set of practices to help ensure institutional knowledge is reliable, collaborative and low-effort.
In this session, Chris will do some live domain modelling with volunteers from the audience to demonstrate a new approach to capturing domain knowledge as living documentation, and how to use open source tools like Contextive (https://contextive.tech) to help ensure the knowledge is absorbed, maintained, and relevant over time.
-
Puuttuva jakso?
-
The strongest tech skills don’t necessarily guarantee success. To get the best from those around you—and maximize your own influence—you need to boost your tech skills with soft skills. Luckily, small changes in the way you work can produce big results.
In this free webinar, Jacqui Read, author of Communication Patterns: A Guide for Developers and Architects, takes you on a whistle-stop tour of patterns and techniques to improve your visual, verbal, nonverbal, written, knowledge, and remote communication skills. You’ll learn communication soft skills tuned specifically to a technical audience, which you can easily integrate into your existing workflows for quick and transformative results.
You’ll learn how to:Use soft skills to boost your technical skills
Explore visual, nonverbal, written, knowledge, and remote communication skills
Integrate communication soft skills into your everyday workflow for transformative results -
When building event-driven architectures, one of the challenges we face is coordinating work across many services. How do we implement complex data flows or complex business transactions that consist of multiple asynchronously executed steps? Luckily, there are patterns that can help us manage this complexity: orchestration and choreography. Join us in this fireside chat with Udi Dahan and Laila Bougria as we discuss how each pattern works, the pros and cons of each, and the trade-offs involved when choosing one over the other in specific contexts. See you there!
-
As systemic complexity increases around us, many technologists are redefining “leadership.” What is technical leadership when good decision-making depends on collective, cross-functional thinking? How is collaborative modeling a form of leadership? What type of leadership does a systems architect provide?
Eb Ikonne, author of “Becoming a Leader in Product Development: An Evidence-Based Guide to the Essentials”, opened our open space event with a keynote. Eb will create the context for our discussions, describing adaptive leadership as something we can practice and a skill we can cultivate. This is the extract of that keynote.
-
As the relational complexity of software increases, we need, more than ever, smart architecture. Domain-aligned, team-decoupling, cohesiveness-driving, constantly evolving architecture has a massive positive impact. To design systems, we need to evolve the role of “architect” away from the dualistic most-experienced implementor vs ivory tower strategist.
Architecture is a technology-agnostic skillset. You practice it regardless of which tools or programming language you work with. Architecture practice is a solitary, intra-group, and inter-group activity. We practice it within the human system, when we collaboratively design patterns and relationships, empower decision making and construct cross-functional feedback loops.
In this talk, we explore:* “What is an architectural decision?” (The answers might surprise you).
* How do we work effectively individually, intra-team, and inter-team to make them?
* What is the “advice process” and what has it taught us? -
Does your team suffer from:
Inconsistent views of your systems? Producing incohesive solutions? Ineffective architecture practices and tools?Introducing Bytesize Architecture Sessions!
Improved systems thinking. Enriching collaboration within the team. Understanding architecture practices and tools in a safe environment. A feedback loop controlled by the team produces better documentation across sessions. Revealing the Bermuda Triangles!
Bytesize Sessions are a workshop format that enables collaborative and iterative knowledge sharing.
This talk will enable you to run Bytesize Sessions resulting in the following benefits:About Andrea Magnorsky
Andrea is a professional software developer with over 20 years of experience. These days she is a consultant / contractor focusing on strongly typed functional languages and software architecture . Andrea founded Kats Conf, Global GameCraft and many other communities. She also co-founded BatCat Games, a PC and Console game development company in Ireland. -
oday most software products are highly networked and distributed solutions used by 1000s if not -10000s of people spread across the globe. To produce an experience that is intuitive and delivers a quality service worldwide, multi-culturally, and 24/7 across all time zones, you need a multi-disciplinary and diverse set of individuals i.e. a tailored team.
Join us in this panel with:
Dawn Ahukanna
Jessica Kerr
Ruth Malan
Rebecca Wirfs-Brock
Mathias Verraes
Trond Hjorteland -
There is a quote made famous by Ruth Malan from Grady Booch: "Architecture represents the significant design decisions that shape a system." And shaping a system takes time, and seeing the impact of these significant design decisions can take years after the changes have been done. And most of us are usually not there to reak the benefit, or worse, feel its pain. So in collaboration with D-EDGE we will have a panel of people that did experience and will discuss how architecture decisions shaped the system years after the change.
-
Our models should be driven by the domain, but not constrained by what domain experts tell us. After all, the domain language is messy, organic, ambiguous, social, incomplete, and if it has any intentional design to it at all, it's not designed to be turned into software. Modelling is more than capturing requirements, it's the opportunity to create novel concepts. This talk will use real-world stories to invite you to discuss.
-
In the last week of this year, we are closing another full year of virtual Domain-driven design meetups with the last meetup. So grab your drinks (tea, lemonade or anything you want!) and come join with your DDD questions to this lean coffee! We all post topics we want to discuss and together we will get into dialogues, so bring us your knowledge and DDD questions and see you then!
Miro https://miro.com/app/board/uXjVOY0dIIk=/
-
The term “sociotechnical” seems to have gotten a bit or renaissance lately, which is a great thing given all the positive impact it has had on many organisations and their workers around the world over the years. It also seems to have gotten some traction outside the academic circles this time after being developed and pushed from there mostly using action research since its humble beginning in the post-war British coal mines. It is an entry into systems thinking for many, with its idea about joint optimisation of both the technical and social aspects of an organisation. A common example is setting up the team topology to match the service architecture in an attempt to cater for negative effects of Conway’s law. This is all well and good, but if we think about it, viewing the modern organisation as a sociotechnical system is a bit of a tautology; all organisations have social and technical elements that people deal with on a daily basis. As with systems thinking, the value of sociotechnical system design is more about perspective and understanding rather than any specific outcome. There is so much more to sociotechnical design than DevOps and team setup that we need in order to cope in our increasingly complex and hazardous “digital coal mines.”
-
Some will say that you shouldn't even try to tackle a system bigger than what a typical agile team can absorb; others will say that agile just doesn’t scale beyond the simplest of systems. Experience suggests that reality lives somewhere between these two extremes, but where, exactly, is the clear and present question. In this talk, we’ll first consider the dimensions of scale - complexity, risk, and time - and then explore the ways that agility works (and sometimes doesn’t). Along, the way, we’ll study contemporary approaches to scaling agile, and conclude with an examination of work yet to be done.
-
Do Software architects have a bad name? Why? What are your expectations, what anti-patterns you experience? What are you thankful for from your architects? Should you have a software architect in the team, or between the teams?
Changing the world starts with thinking and sharing the reasons. This podcast is the recording of our open discussion with the community.
-
Cat Swetel gave a brilliant Technologist's Introduction to Epistemic Injustice explaining "epistemic injustice"—what we know, how we know, and who gets to decide and influence our reality. There are two kinds of epistemic injustice:
Testimonial injustice; When someone is ignored, or not believed, because of their sex, sexuality, gender presentation, race, or, broadly, because of their identity.
Hermeneutical injustice; injustice related to how people interpret their lives.Join us in this session where Cat will do a short introduction on the topic, and after, we will talk about how this impact domain crunching. For instance, if we don't include software developers in requirements engineering, what is the impact? What if the software teams only allowed to build user stories and aren't part of the narrative for their building? And what about the exchange of narratives across the ecosystem, i.e. across domains. Do we have the hermeneutic resources to describe emergent behaviour across the system?
-
Join us in this special fireside chat with Udi Dahan answering all your questions spanning from Domain-Driven Design, Software Architecture from SOA, event-driven, CQRS, Large-scale distributed systems, Saga Patterns, Event sourcing, microservices and anything in between. Ask your questions upfront or during the session! You can also already engage and see the questions that are already asked at this Twitter thread: https://twitter.com/UdiDahan/status/1349302917648568321
-
Domain-Driven Design is a lot about collaborative modelling, understanding the user's needs collaboratively to design and implement the best fitting model. We want the teams to do this as autonomous as possible, getting fast feedback and new insights into improving that model. At the same time, they need to stay aligned with the company goals and strategy and other teams. To ensure this alignment, companies hire managers and architects for that task. But what decisions should be made centralized, and what decentralized? What part of managing should be autocratic, and what should be participatory?
Join us in a dialogue with Ellis de Haan, Marc Burgauer, Andrew Harmel-Law and Trond Hjorteland. We will discuss everything concerning the culture around autonomous teams. Patterns of anarchy, command and control decision making, architects as a job, the long going discussion of 'do we really need a manager' and can leaders be managers? And dive into the stratified systems theory or "levels of work" by Elliot Jaques.
-
People wonder how distilling the Core with the Core, supportive and generic subdomains fit and what space. What concepts are in the problem space, and what is the solution? And what is a precise definition of problem and solution space?
Join us in this session are a diverse group of people spanning multiple disciplines to look at how they see the relationship(s) between problem and solution space in IT. And hopefully, in the end, we can have a useful, consistent model of those relationships between problem and solution space, core, supportive, generics (sub)domains for the #DDDesign community.
-
There are many reasons to split up large-scale systems towards more modular, smaller services with their own model and language. You can decouple teams and give full autonomy of that service to a team. By decoupling services and teams you can handle changes to the domain faster, having a faster time to market. You decrease the cognitive load of the teams, empowering teams to truly understand the complexity of their shared models with domain experts.
But how do we split up large-scale systems? What are the characteristics we can dissect a bounded context? How do we split towards a microservices architecture? We do not only have to deal with shifting terminology here but also different rates of change in the business.
Join us in this Panel where we will hunt for design heuristics to split systems towards bounded contexts and microservices.
-
Just before all the holidays start we are closing this year virtual Domain-driven design meetups with the last meetup. So grab your drinks (tea, lemonade or anything you want!) and come join with your DDD questions to this Ask us anything party! We have invited several people from the community who will join an online fishbowl in a zoom webinar. You post your questions and we will discuss them.
- Näytä enemmän
