Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building Better Software Faster

543 views

Published on

The slide deck to my kick-off keynote at software vendor ANVA's new year on January 10, 2017. This talk covers agile, Scrum, Kanban, continuous delivery, microservices.

Published in: Software
  • Be the first to comment

Building Better Software Faster

  1. 1. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 1 @aahoogendoorn | www.ditisagile.nl Building better software faster Sander Hoogendoorn ditisagile.nl
  2. 2. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 2 Sander Hoogendoorn Me Dad, software architect, agile coach, programmer, trainer, speaker, writer Books, articles, conferences, courses Work Owner ditisagile.nl CTO ANVA Former CTO insurance company Former global agile thoughtleader Capgemini Web www.sanderhoogendoorn.com aahoogendoorn aahoogendoorn sander@ditisagile.nl
  3. 3. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 3
  4. 4. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 4 As a project manager I would like to demo untested code so I embarrass myself
  5. 5. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 5 @aahoogendoorn | www.ditisagile.nl The Times They Are a-Changin'
  6. 6. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 6 Moore’s Law The number of transistors in a dense integrated circuit doubles approximately every two years.
  7. 7. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 7
  8. 8. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 8
  9. 9. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 9
  10. 10. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 10 @aahoogendoorn | www.ditisagile.nl The Times They Are a-Changin' On our block
  11. 11. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 11
  12. 12. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 12
  13. 13. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 13
  14. 14. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 14 Too much, too soon Hard to deliver, harder to test, impossible to maintain
  15. 15. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 15
  16. 16. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 16
  17. 17. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 17
  18. 18. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 18
  19. 19. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 19 Dependencies will kill you
  20. 20. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 20 @aahoogendoorn | www.ditisagile.nl Microservices A definition
  21. 21. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 21 Microservices In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Martin Fowler
  22. 22. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 22
  23. 23. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 23 @aahoogendoorn | www.ditisagile.nl From the trenches Microservices in real life
  24. 24. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 24 For the things we have to learn before we can do them, we learn by doing them Aristotle
  25. 25. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 25
  26. 26. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 26 Microservices require an evolutionary software architecture
  27. 27. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 27 @aahoogendoorn | www.ditisagile.nl Some guiding principles Business processes first
  28. 28. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 28 We implement business processes We move towards a systems landscape consisting of micro-applications and micro-components Requirements are modeled (in smart use cases) Micro-applications implement a single elementary business process Micro-applications and micro-components all have their own bounded context Micro-applications do not have storage, and only talk to other micro-applications and micro-components Micro-components have their own storage (in MongoDB), and only talk to other micro-components Communication uses a simple open protocol – JSON on REST We avoid transactions as much as possible Some guiding principles
  29. 29. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 30 Smart use cases
  30. 30. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 31 Presentation Process Domain Services Outside world Pages Grids, Panels, Controls Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways ComponentsRelations Dossiers Intermediaries Accounts Rates
  31. 31. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 32 Service interface Process Domain Data / Services Outside world Resources Representations Use cases Flow Factories, Repositories Entities, Enums, Value objects Gateways StorageRelations Dossiers Intermediaries MongoDB
  32. 32. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 33 @aahoogendoorn | www.ditisagile.nl Designing microservices Modular design and bounded contexts
  33. 33. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 34 Doing big up-front design is dumb, doing no design up-front is even dumber Dave Thomas
  34. 34. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 35 Bounded contexts
  35. 35. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 36 Single responsibility principle Group together things that change together Separate things that change for different reason
  36. 36. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 37 Bounded context When you model larger domains, it becomes progressively harder to create this single unified model. Instead of creating a single unified model, you create several, all valid within their bounded context
  37. 37. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 38 The single unified domain model Or more often the humongous data model Product Vendor Stock Order Client Delivery Payment
  38. 38. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 39 Bounded contexts Product Vendor Stock Order Client Delivery Payment Product
  39. 39. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 40
  40. 40. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 44 @aahoogendoorn | www.ditisagile.nl Testing microservices Failing fast
  41. 41. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 45 Fail fast, fail often, fail forward
  42. 42. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 46 Manual tests Scenario tests Integration tests Unit tests
  43. 43. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 47 Manual tests Scenario tests API tests Unit tests
  44. 44. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 48 A development lifecycle What to test? Code Developer Test Test Integration Test Acceptance Test Live Prepare and Design Developers Unit tests Developers Peer review Testers Scenario’s And API’s Testers Scenario’s and API’s Product owner Product
  45. 45. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 49 Even though you might have really brilliant testers… Exploratory Testing, anyone?
  46. 46. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 52 @aahoogendoorn | www.ditisagile.nl Deploying microservices Continuous integration and build pipelines
  47. 47. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 53 How often do you deploy to production?
  48. 48. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 54 A typical build pipeline Code Developer Test Test Integration Test Acceptance Test Live Prepare and Design
  49. 49. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 55 ProductionAcceptanceIntegrationTestDevelopment A typical build pipeline Traditional (virtual) infrastructure Code Developer Test Test Integration Test Acceptance Test Live Prepare and Design
  50. 50. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 56 ProductionProvisionedProvisionedProvisionedDevelopment A typical build pipeline Provisioned infrastructure (on the fly) Code Developer Test Test Integration Test Acceptance Test Live Prepare and Design
  51. 51. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 58 Microservices Building multiple deployment pipelines Code Developer Test Test Acceptance Test Acceptance Live Code Developer Test Test Acceptance Test Acceptance Live Code Developer Test Test Acceptance Test Acceptance Live Code Developer Test Test Acceptance Test Acceptance Live
  52. 52. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 59 Infrastructure as code
  53. 53. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 60 @aahoogendoorn | www.ditisagile.nl Agile beyond Scrum Towards continuously delivering software
  54. 54. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 61 Lowering our fences
  55. 55. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 62 Dogmagile
  56. 56. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 63 The red sprint anti-pattern
  57. 57. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 64 Minimal viable products Think small, deploy early and frequently
  58. 58. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 65 Do we need this NOW?
  59. 59. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 66 Roadmaps over plans While there is value in the items on the right, we value the items on the left more
  60. 60. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 67
  61. 61. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 68 Continuous delivery An approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Aimed to make releases boring, so we can deliver frequently and get fast feedback on what users care about.Jez Humble
  62. 62. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 71 @aahoogendoorn | www.ditisagile.nl In retrospective Some final thoughts
  63. 63. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 72 The times are a-changin’ How are we going to keep up? Towards micro-applications and microservices Modeling requirements Focus on core technologies Continuous delivery Minimal viable products Rationalize our legacy Domain driven design Leverage the cloud
  64. 64. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 73
  65. 65. @aahoogendoorn | www.ditisagile.nlBuilding better software faster 74 @aahoogendoorn | www.ditisagile.nl References and questions www.sanderhoogendoorn.com www.ditisagile.nl aahoogendoorn aahoogendoorn sander@ditisagile.nl

×