Evolutionary Enterprise Architectures

A discussion point for how to take an evolutionary approach to platform architectures in large enterprises.

Transcript

1. Evolutionary Architectures Our experience of evolving the platform architecture for a large enterprise.
2. A difficult start • Large monolithic code base on a dated technology stack • Legacy UI (aka. poor usability) • No application tests • Complex business rules • Multiple integrations with other enterprise systems • Global rollout • Poor understanding of Agile • Departments working in silo’s • Big upfront architectures • Mandate for enterprise middleware • Long deployment cycles • Inconsistent data across systems • No visibility of application/code base
3. Start empowering teams CI infrastructure jenkins/gocd Version control git/mercurial Application frameworks spring/dropwizard, angular/ember Deployment tools maven/gradle, tomcat/jetty Code quality jacoco/sonar Collaboration tools mingle/jira Testing frameworks cucumber-jvm/selenium
4. enabling incremental & evolutionary design Decompose the backend application logic into a collection of small, independent, loosely-coupled, reusable, REST-ful µ-services. monolithic-app db-1 db-n presentation, business-logic, data-persistence
5. building a modern, responsive user-interface Using client-side javascript frameworks like AngularJS to separate the UI concerns from the web application logic. angular-js-ui spring-mvc-app rest-api-1 rest-api-n authentication, authorization, caching, orchestration mvc, routing, ui-models 2-way binding, templates, coffee-script domain models, business validations, persistence db-1 db-n HTTP verbs json …
6. CI as the engine for collaborative development Source: https://blog.snap-ci.com/blog/2015/11/24/architecting-for-continuous-delivery/
7. build library build api build web-app smoke regression staging pre-production compile test publish package prepare deploy publish run-tests showcase, integrations performance, penetration-testing Aligning teams with CI
8. a hierarchy of application tests Unit Tests Integration tests Functional tests The higher we go, the fewer the number, the slower the feedback, the higher the development cost cucumber-jvm, selenium protractor, rest-assured junit, mockito
9. trunk-based development One repository per component. Everyone commits to trunk (every day). No branches. Feature toggles help.
10. conway’s guidance & team decomposition Organize teams around business capabilities e.g. catalog, pricing, feeds, subscriptions, personalization, etc. and not around areas of technology specialization e.g. data-integration, reporting/analytics, search, etc.
11. Some lessons Embrace modularity and loose-coupling Avoid big upfront design Seek continuous feedback via the automated delivery pipeline Align teams around business capabilities Collaborate when defining service contracts
12. @ ThoughtWorks Demonstrating influence across business, technology, and user-experience.