Successfully reported this slideshow.
Your SlideShare is downloading. ×

SOA: An enabler for Continuous Delivery and innovation

SOA: An enabler for Continuous Delivery and innovation

Download to read offline

Building on my experience at Westfield Labs, this presentation explores how implementing a Service Oriented Architecture allowed Westfield to embrace a Lean, Agile approach to Product delivery.

Presentation was originally delivered to CTO Summit Sydney
https://ti.to/startup-cto-summit/sydney

Building on my experience at Westfield Labs, this presentation explores how implementing a Service Oriented Architecture allowed Westfield to embrace a Lean, Agile approach to Product delivery.

Presentation was originally delivered to CTO Summit Sydney
https://ti.to/startup-cto-summit/sydney

Advertisement
Advertisement

More Related Content

Advertisement

Related Books

Free with a 30 day trial from Scribd

See all

SOA: An enabler for Continuous Delivery and innovation

  1. 1. SOA: An enabler for Continuous Delivery and innovation
  2. 2. Why did we want an SOA and Continuous Delivery?
  3. 3. Driven by Engineering team Stagnant Architecture
  4. 4. Huge automated testing overhead Over 50% of engineers time spent maintaining tests Slow Continuous Integration
  5. 5. Poor feedback loop between feature specifications and engineers Engineers as code monkeys Bureaucratic Overhead managing Scrum
  6. 6. Too much time spent managing and patching releases Manual Regression Sign-off Repeat
  7. 7. What did ‘the business’ want To pivot To build the prototype To deliver on all the metrics
  8. 8. Restructure!
  9. 9. Cross-Functional Teams Teams dedicated to business goals Data over opinions Culture of discovery
  10. 10. Iterate Quickly Small change Measure success Adjust
  11. 11. How did an SOA help?
  12. 12. Discrete focus for the mind For the individual For the team
  13. 13. Ownership and personal responsibility Abstraction allows ownership and autonomy Test your own work Manage your own releases Definition of done: In Production
  14. 14. Pragmatic test coverage Honour your SLA’s Focus on unit tests Test where you need it Test in production?
  15. 15. Continuous Delivery Independent Releases A mindset or philosophy Product of behavioural changes
  16. 16. Observations?
  17. 17. Faster iterations Smaller pieces of work Faster feedback loop Focus on why?
  18. 18. Greater Collaboration Visual Design / UX and engineers collaborating Devops Responsibility for Quality is shared
  19. 19. Better Quality The QA paradox Bugs managed themselves
  20. 20. Steady cadence Predictable Wider understanding of capability Features ‘grew’
  21. 21. Finally.. Drop the silos Let testability drive your architecture It’s not an engineering capability

Editor's Notes

  • Our Engineering team was stuck on Rails 2.3.5, architecture had become stagnant. Change was needed!
  • 75% Cucumber/BDD code coverage
    100% unit test coverage
    At least 15 hours worth of tests end to end
    Jenkins for parallel processing still took at least an hour
    Legacy of poorly written and/or Flaky tests a maintenance nightmare
  • Engineers given “Tablets of stone” requirements from above
    Bug Tsar was required to manage and prioritise the hundreds of outsanding bugs
    Huge overhead of Feature prioritisation meetings and negotiated commitment
    Points not treated as abstract by management
  • Process of cut Release Candidate > Regression Test > Patch every Sprint caused large overhead and delays to release code.
    Late entry to ‘production-like’ environment meant issues around content/scale/usabilty etc are discovered late
  • ‘The Business’ meaning marketing, the guys that are paying - note, see http://vertical-slice.com/2014/05/19/we-are-the-business/
    What the business wants is always simple, it’s the implementation that is hard
  • We didn’t have all the answers, that was accepted. We needed to discover them.
    Achieve a goal rather than complete a task
    Team should be able to unblock itself
    A cross functional team may consist of the following: UX/BA/VD/Ops/FED/BED/SME
  • A developer should always be able to hold the project in his head – the architecture needs to be separated into discrete components
    With separation of services separation of scope and ownership becomes much easier.
    It is very difficult to achieve X-func teams, autonomy and quick iterations without a decoupled architecture which allows it.
  • Defining done as “Released to production” focuses the mind
    Create a culture where engineers cannot hand over sub-standard work to QA
    Who is responsible for quality in a Traditional Cycle
    With great power comes great responsibility
  • BDD can protect you from poor abstractions but it’s slow and expensive
    Automate heavily across crucial areas such as Payments or brittle areas such as maps. Less so on edge cases
    Sometimes it’s cheaper to find and fix a bug in production than support test automation overhead
  • See http://vertical-slice.com/2014/02/15/the-philosophy-of-continuous-deployment/
    An SOA enables the abstractions and behavioural changes that allow small changes to be released fast. This enables Continuous Delivery.
  • Encourage the team to ask why they are implementing a piece of work and measure it’s success
  • Small iterations make greater collaboration a necessity
    Ops have to give up control so collaborate closely with engineers
    Engineers accept they are on call for operational issues
    At Westfield Labs there was great collaboration on a Release Pipeline application built by QA/Engineers/Ops

  • Asking QA’s not to take responsibility for functional testing actually seemed to reduce bugs
    Bugs given parity with features when being prioritised by the team
    Less bugs, less bug management
    Smaller, more focused teams meant the team implicitly understood bugs, saving time on bureaucracy
  • Stable, steady output of measured enhancements
    Points abolished, commitment reached far more often
    Features tended to grow out of a series of minor enhancements toward a larger goal rather than lurching forward then stabilising afterward
  • Don’t have teams structured by functional silo
    Don’t leave Continuous Delivery to your Engineering team, it must be collaborative across all areas of the business

×