Mike Wojtyna
IT Consultant 🌱 Technical Business Partner 🌳 and Software Architect 🏡
Bydgoszcz, Poland
Actions
I'm a software architect with a passion for creating great products. Domain-driven design & Test-driven development are some of my favorite tools. My code is clean and easy to modify, thanks to the modular, loosely coupled design achieved by continuous TDD iterations backed by a deep understanding of business requirements.
I'm also a professional consultant and trainer. In my free time I create online courses and write articles about software development, DDD and clean code.
Check out how I can help you
http://www.wojtyna.pl
Area of Expertise
Topics
Archetypes - your secret superpower
Imagine jumping into a new project. In a very short time you start asking meaningful questions, understand the business, and model it correctly. Somehow you just feel what’s right. You manage to solve some of the problems the team was facing for months. You suggest improvements that can benefit your clients tremendously. All within the first few weeks. Some team members may admire you, while others might make accusations that you are cheating or faking your abilities, or that you possess some special superpowers. Sounds like a fairy tale? During this presentation I’m going to show you how you can utilize archetypes to immediately recognize the business patterns, make right modeling decisions and astonish your fellow team members.
Domain Experiments
Our clients don't know what they need.
This happens because no one can foresee the future.
Requirements will evolve and change rapidly over the lifecycle of the project. That's why we need to constantly refine systems.
We can keep building and discarding prototypes, but it's extremely costly.
Often we can't afford to rewrite everything from scratch only because some new domain insights were discovered.
This eventually leads to a mismatched model.
Is there another way?
We can focus on domain only and refine our model through examples, until we find the right conceptual contours (http://ddd.fed.wiki.org/view/welcome-visitors/view/conceptual-contours).
Each such iteration of the model is a kind of experiment challenging the upfront decisions.
During this presentation I'm going to show how you can use example mapping combined with business-oriented TDD to be able to run rapid experiments directly on the domain model, without a need to rewrite the system again.
Becoming a Technical Business Partner
We often consider business and developers as separate teams. The “Business” part needs something, while “Developers” implement it. This clearly defines the Customer-Supplier relationship at best and Conformist at worst. In these relationships Business acts as Upstream, while Developers as Downstream. Doesn’t sound like the best option when developing custom solutions, does it? I’m going to show you how to upgrade this relationship into Partnership.
During this presentation I’ll show you how you can make your first step into becoming a Technical Business Partner. Technical Business Partner is a business-oriented engineer with deep technological expertise. Instead of just implementing stuff correctly, TBP understands the business and therefore is able to suggest improvements in the business model or any other aspects of running the company. This approach allows us to build better models, increase velocity of the development and focus on what’s really important instead of wasting time and energy on technological bikeshedding.
Take your first step to become a Technical Business Partner!
My design is better than yours: bridging the gap between tactical modeling and business
Engineers have a tendency to create emotional connections with their models. At best, this can end up with a lot of pointless discussions, at worst escalate to nearly-religious wars in the defense of "the only right model”. So… Are we doomed to repeat these nonsensical fights all the time? Fortunately, there’s an entity that can decide which model is better. It’s called business.
During this presentation I’m going to show you how you can avoid analysis paralysis, pointless discussions, common design pitfalls and creating overengineered, often totally unnecessary code. Together, we’ll bridge the gap between tactical modeling and true business drivers.
Domain-driven architecture
You can't avoid essential complexity when creating architecture. What you can avoid, though, is accidental complexity. During this talk, I'll show you how to align architecture with strategic DDD to focus on what truly matters. No time wasted on technological bikeshedding. You'll see the full journey of a business-oriented architect, starting with product vision and business goals, and ending with high-level architectural boundaries expressed in code as an architectural meta-model.
You'll discover the value of making your architecture domain-driven and expressing it as code. You'll learn how to compare architectures using metrics, verify alignment between architecture and application, and clearly represent business processes and personas. You'll also see how to generate diagrams tailored to any audience or purpose. And the best part? Once the domain-driven meta-model is in place, all of this becomes almost effortless.
Architecting the Future with Wardley Maps
Making good architectural decisions is impossible without understanding the business context. Choosing the right team topology or allocating engineering capacity effectively depends on knowing which parts of your system are core, supporting, or generic. But these boundaries shift over time. Domains evolve as fast as the business ecosystem around them.
That's where Wardley Mapping comes in. It helps you see where you are today and where you're heading. When business priorities change, your software and architecture need to keep up. These dynamics will increase greatly in the upcoming years. So, the real question is: are you ready to work with that change and step into the role of a true Technical Business Partner?
In this talk, I'll show how you can use Wardley Mapping to understand business strategy, compare your solution with competition and make architectural decisions that actually support business goals.
How being a dungeon master helped be to become a better architect
About 20 years ago, my parents were convinced I was wasting time on "silly stuff" like "playing with little figures and casting fireballs". They had no idea those RPG sessions were teaching me something far more valuable than just how to play a game.
Fast-forward two decades: when I run modelling workshops today, I’m using the exact same skills I built while leading RPG campaigns all those years ago.
In this talk, I’ll show how facilitation patterns used by dungeon masters can help you guide teams, uncover insights and design better architecture.
How Agents Can Help You Become a Better Facilitator
Facilitation is quickly becoming a core hard skill. Techniques like Event Storming, Context Mapping or Impact Mapping can deliver incredible results. The problem? Good facilitation takes time, practice and real world experience, but most engineers don’t get many chances to run workshops. Even when they do, they usually work in just a handful of domains throughout their careers. That's definitely not enough to spot recurring patterns and archetypes.
But what if you could learn these facilitation patterns at your own pace, without constantly switching projects or relying on rare workshop opportunities? Yes, you guessed it: this is where agents come in. 😉
In this talk, you’ll see how agents can help you practice facilitation, explore collaborative modelling scenarios and build the skills needed to run effective workshops.
Mike Wojtyna
IT Consultant 🌱 Technical Business Partner 🌳 and Software Architect 🏡
Bydgoszcz, Poland
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top