Your tech-stack is awesome but so is your domain

Of course we all love our favorite technologies and of couse it is important to understand your tech stack as a developer. Certainly you become a great developer or architect by understanding modern patterns and architectures.

But isn’t it a bit boring to just churn out code just for codes sake?

In this talk I want to motivate you to leave your comfort zone and to take a step back. This talk aims at motivating you as a developer or an architect to dig deep into the domain of your business and your product. I firmly believe that this will make you a great and especially a more valuable developer. If we understand the business we can make better design choices as developers / architects. We can highlight misalignments in our organization. We will be able to come up with better tests.

This talk will not just be limited to the motivating side of this topic. I will also give you tons of hints and tips how you can get started in this journey, who your allies may be and how to tackle this difficult task. This talk will also come with many examples of success and failure from the real world. I guess we will laugh a lot during this session but sometimes we’ll also shake our heads in utter disbelieve in those 50 minutes.

Transcript

1. Your Tech-Stack is
   awesome
   
   
   but so is your domain
   MICHAEL PLÖD
   FELLOW
   

   View Slide

2. Michael Plöd
   Fellow at INNOQ
   
   
   Mastodon (or Twitter): @bitboss@mastodon.social
   
   
   LinkedIn: https://www.linkedin.com/in/michael-ploed/
   
   
   Current consulting topics:
   
   
   • Domain-Driven Design
   
   
   • Team Topologies
   
   
   • Transformation from IT Delivery to digital product orgs
   
   
   Regular speaker at (inter-)national conferences and author of a
   book + various articles
   

   View Slide

3. Get my DDD book cheaper
   Book Voucher: 7.99 instead of (min) 9.99
   
   
   http://leanpub.com/ddd-by-example/c/speakerdeck
   

   View Slide

4. Why did you become a software engineer?
   

   View Slide

5. Tech is awesome
   

   View Slide

6. your domain and some business stuff
   Let me motivate you for
   

   View Slide

7. Don’t be afraid: I
   don’t want to turn
   you into a business
   suit
   

   View Slide

8. Instead I think that
   business and
   domain knowledge
   will make you a
   more valuable
   developer
   Photo by Jon Tyson on Unsplash
   

   View Slide

9. You write better code which is more maintainable
   You will make better modularization decisions
   You will communicate better and therefore be heard more
   You can make a signi
   f
   icant impact on the product design
   Your value will increase
   VALUE
   

   View Slide

10. You write better code which is more maintainable
    You will make better modularization decisions
    You will communicate better and therefore be heard more
    You can make a signi
    f
    Let’s approach this bottom-up
    VALUE
    

    View Slide

11. 11
    Innovation Cycles
    Teams
    Market
    Look for signals from
    Great User
    

    Experience
    Expects
    Software
    Is enabled by Is developed by
    Source: https://www.ntcoding.com
    

    View Slide

12. „the key to incremental architecture
    is to build on a framework that can
    accommodate change... that
    framework is the domain.... By
    modeling the domain, you can more
    easily handle changes to the domain“
    Allen Holub
    
    
    https:/
    /holub.com
    

    View Slide

13. 13
    Innovation Cycles
    Teams
    Market
    Look for signals from
    Great User
    

    Experience
    Expects
    Software Architecture
    Is enabled by Is developed by
    Business
    

    Domain
    Should be
    

    a model of
    Source: https://www.ntcoding.com
    

    View Slide

14. We can drive this even further
    

    View Slide

15. 15
    “A loosely coupled software
    architecture and org structure
    to match” is a key predictor of:
    
    
    •Continuous Delivery Performance
    
    
    •Ability to scale organization and
    increase performance linearly
    

    View Slide

16. 16
    Innovation Cycles
    Teams
    Market
    Look for signals from
    Great User
    

    Experience
    Expects
    Software
    Is enabled by Is developed by
    Business
    

    Domain
    Should be
    

    a model of Should be
    

    aligned with
    Source: https://www.ntcoding.com
    

    View Slide

17. Let me tell you a story
    
    
    Michael as a young developer for a
    mortgage loan scoring engine
    

    View Slide

18. Michael
    Requirements
    

    Engineers Risk
    

    Managers
    

    View Slide

19. I had a great and thorough speci
    f
    ication
    

    View Slide

20. The starting point
    

    View Slide

21. Let’s look at the business rules
    

    View Slide

22. View Slide

23. The rules in the bigger picture
    

    View Slide

24. The speci
    f
    ication implied the
    following structure
    

    View Slide

25. View Slide

26. So I built my scoring engine
    according to that structure
    which I assumed in my head
    which roughly looked like this
    

    View Slide

27. View Slide

28. The acceptance test and a
    change in communication
    

    View Slide

29. Michael
    Requirements
    

    Engineers Risk
    

    Managers
    

    View Slide

30. I developed a bad gut feeling
    but go-live was
    f
    ine, just two
    minor bugs.
    

    

    But then came a new
    requirement…
    

    View Slide

31. We want to see if a red scoring
    can become green with more
    own funds
    

    

    if yes: how much more money
    do the applicants need?
    

    View Slide

32. Michael: „this affects nearly everything“
    

    View Slide

33. Risk Management: „no, it’s only in one part“
    ?
    

    View Slide

34. The risk managers started to
    think that I do my surname
    justice
    

    (just replace the P in Plöd by a B)
    

    View Slide

35. They had a different mental model
    

    View Slide

36. Everyone was right, from their perspective
    

    View Slide

37. I refactored my code to their
    mental model and the new
    requirement was suddenly
    very easy to implement
    

    View Slide

38. View Slide

39. Key
    

    Learnings
    It is essential that you understand the mental
    model which is in the heads of the business folks.
    Implement the structures in your domain logic code
    according to this shared understanding.
    Their requirements and assumptions stem from this
    mental model.
    Try to reduce the amount of implicit assumptions in
    your head as much as possible.
    

    View Slide

40. „It is not the domain
    experts knowledge that
    goes into production, it is
    the assumption of the
    developers that goes into
    production”
    40
    Alberto Brandolini
    
    
    Inventor of EventStorming
    

    View Slide

41. Use collaborative modeling methods
    Image for example mapping taken from: https://openpracticelibrary.com/practice/example-mapping/
    

    Image for user story mapping taken from: https://www.hanssamios.com/dokuwiki/how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list
    

    View Slide

42. View Slide

43. Design Level EventStorming
    

    View Slide

44. Starting point
    

    View Slide

45. Chaotic Exploration on business rules
    

    View Slide

46. You can already start to write tests!
    

    View Slide

47. Which grouping of the rules is the right one?
    

    View Slide

48. You write better code which is more maintainable
    You will make better modularization decisions
    You will communicate better and therefore be heard more
    You can make a signi
    f
    Let’s approach this bottom-up
    VALUE
    

    View Slide

49. We already talked about modularization
    on a lower level…
    

    View Slide

50. View Slide

51. Modularization on a higher level
    

    View Slide

52. Text...
    Shape... Color... Size...
    There are many choices to group domain concepts
    Output quantity
    

    View Slide

53. George Box
    All models are wrong, some are useful
    

    View Slide

54. Who can give me a DETAILED description of the
    business model of your application including:
    

    

    Customer Segments
    

    Channels
    

    Value Proposition
    

    Cost Structure
    

    Revenue Streams
    

    View Slide

55. View Slide

56. „When companies do not understand their
    customers’ or users’ problems well, they
    cannot possibly de
    f
    ine value for them.
    Instead of doing the work to learn this
    information about customers, they create
    a proxy that is easy to measure. ‚Value‘
    becomes the quantity of features that are
    delivered, and, as a result, the number of
    features shipped becomes the primary
    metric of success.”
    

    View Slide

57. View Slide

58. Who agrees with the following sentence?
    
    
    There are modularization options that
    work for or against a value proposition
    

    View Slide

59. How can we come up with proper boundaries for
    modules (be it in monoliths or microservices) when we
    don’t know or understand the value proposition?
    

    View Slide

60. Ask these questions
    •What value do we deliver to the customer?
    
    
    •Which one of our customer's problems are we helping to solve?
    
    
    •Which job are we helping the customer get done?
    
    
    •Which customer needs are we satisfying?
    
    
    •What bundles of products and services are we offering to each Customer
    Segment?
    
    
    Source: https://www.strategyzer.com/business-model-canvas/value-propositions
    

    View Slide

61. Types of value propositions
    •Newness
    
    
    •Performance
    
    
    •Customization
    
    
    •„Getting the job done“
    
    
    •Design
    
    
    •Usability
    
    
    Source: https://www.strategyzer.com/business-model-canvas/value-propositions
    •Brand / Status
    
    
    •Price
    
    
    •Cost Reduction
    
    
    •Risk Reduction
    
    
    •Accessibility
    
    
    •Convenience
    
    
    

    View Slide

62. Book hints
    

    View Slide

63. Check out DDD-CREW on GitHub
    https://github.com/ddd-crew
    

    View Slide

64. https://github.com/ddd-crew/ddd-starter-modelling-process
    

    View Slide

65. 65
    Bounded Context Design Canvas
    
    
    The canvas guides you through the process of designing a bounded context by requiring you to
    consider and make choices about the key elements of its design, from naming to responsibilities, to
    its public interface and dependencies.
    Source: https://github.com/ddd-crew/bounded-context-canvas
    

    View Slide

66. View Slide

67. You write better code which is more maintainable
    You will make better modularization decisions
    You will communicate better and therefore be heard more
    You can make a signi
    f
    Let’s approach this bottom-up
    VALUE
    

    View Slide

68. View Slide

69. How the business names things
    TV
    Window
    Chair
    Trolley
    Painting
    Desk
    What we see in code
    TransparencyFactory
    RollableStuffContainer
    EntertainmentProviderSingleton
    DecoratorImpl
    RestProvider
    WorkEnablementDevice
    

    View Slide

70. EMPATHY
    

    View Slide

71. Food for thought
    

    View Slide

72. https:/
    /architectelevator.com/
    

    View Slide

73. Modern architects align organization and
    technology, reduce friction, and chart
    transformation journeys. In addition to
    working with UML and architecture styles,
    such architects ride the Architect Elevator
    from the penthouse, where the business
    strategy is set, to the engine room, where
    the enabling technologies are implemented.
    They shun popular buzzwords in favor of a
    clear strategy de
    f
    ined by conscious
    decision making.
    
    
    Gregor Hohpe
    
    
    Author of „The Software Architect
    Elevator“
    

    View Slide

74. You write better code which is more maintainable
    You will make better modularization decisions
    You will communicate better and therefore be heard more
    You can make a signi
    f
    icant impact on the product design
    Let’s approach this bottom-up
    VALUE
    

    View Slide

75. Shift
    from
    
    
    Projects
    to
    Products
    Tech-enabled
    Organizations
    •Tech is core strategic asset in
    product and not a cost center
    
    
    •No feature factories
    
    
    •Strong aim to insourcing of
    development of functionality
    which is core to the business
    
    
    

    View Slide

76. Product Thinking 101 by Naren Katakam https://uxplanet.org/product-thinking-101-1d71a0784f60
    Technology
    Product
    Users Business
    

    View Slide

77. „Product thinking is the journey from the
    problem space of the users to the
    solution space of the business.
    
    
    The goal of this journey is to reduce the
    gap between users and the business.”
    
    
    Naren Katakam
    

    View Slide

78. Source: https://medium.com/agileinsider/what-we-learned-from-our-survey-of-550-product-managers-and-leaders-79340126ccab
    "If you're just using your
    engineers to code,
    you're only getting
    about half their value.“
    
    
    Marty Cagan
    

    View Slide

79. What does this management term
    digitalization
    

    mean?
    

    View Slide

80. What is the
    

    purpose of digitalization
    

    from a business perspective
    

    View Slide

81. Purposes of digitalization
    Digitalization
    Improve an existing business
    model with tech
    Create a whole new business
    (model) enabled by tech
    

    View Slide

82. The words business & tech appeared together in both
    purposes
    Did you realize?
    

    View Slide

83. „Let’s just introduce DevOps!“
    

    View Slide

84. You build it, you run it
    Business
    

    Domain
    

    Experts
    Developers
    

    Architects
    Operations
    

    DDD
    Dev
    

    Ops
    You design it, you build it and you run it
    

    View Slide

85. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
    

    View Slide

86. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
    Moving the responsibilities
    

    to the left requires developers
    

    to understand the business
    

    as well as the business to
    

    understand tech
    

    View Slide

87. I am convinced that
    business and
    domain knowledge
    will make you a
    more valuable
    developer
    Photo by Jon Tyson on Unsplash
    

    View Slide

88. Krischerstr. 100
    
    
    40789 Monheim
    
    
    +49 2173 3366-0
    
    
    Ohlauer Str. 43
    

    10999 Berlin
    
    
    

    Ludwigstr. 180E
    

    63067 Offenbach
    
    
    

    Kreuzstr. 16
    

    80331 München
    
    
    

    Hermannstrasse 13
    

    20095 Hamburg
    
    
    

    Erftstr. 15-17
    
    
    50672 Köln
    
    
    

    Königstorgraben 11
    
    
    90402 Nürnberg
    
    
    innoQ Deutschland GmbH
    www.innoq.com
    Thank you!
    Michael Plöd
    
    
    E-Mail: michael.ploed@innoq.com
    
    
    Socials: @bitboss@mastodon.social
    
    
    LinkedIn: https://www.linkedin.com/in/michael-ploed/
    Book Voucher: 7.99 instead of (min) 9.99
    
    
    http://leanpub.com/ddd-by-example/c/speakerdeck
    

    View Slide