SOA: An enabler for Continuous Delivery and innovation
Report
Share
•1 like•5,044 views
SOA: An enabler for Continuous Delivery and innovation
•1 like•5,044 views
Report
Share
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
More Related Content
What's hot
What's hot(20)
Similar to SOA: An enabler for Continuous Delivery and innovation
Similar to SOA: An enabler for Continuous Delivery and innovation(20)
![[Webinar] Test First, Fail Fast - Simplifying the Tester's Transition to DevOps](https://cdn.slidesharecdn.com/ss_thumbnails/testfirstfailfastfinal-170323164615-thumbnail.jpg?width=768&fit=bounds)
Recently uploaded
Recently uploaded(20)
SOA: An enabler for Continuous Delivery and innovation
- 1. SOA: An enabler for Continuous Delivery and innovation
- 2. Why did we want an SOA and Continuous Delivery?
- 3. Driven by Engineering team Stagnant Architecture
- 4. Huge automated testing overhead Over 50% of engineers time spent maintaining tests Slow Continuous Integration
- 5. Poor feedback loop between feature specifications and engineers Engineers as code monkeys Bureaucratic Overhead managing Scrum
- 6. Too much time spent managing and patching releases Manual Regression Sign-off Repeat
- 7. What did ‘the business’ want To pivot To build the prototype To deliver on all the metrics
- 8. Restructure!
- 9. Cross-Functional Teams Teams dedicated to business goals Data over opinions Culture of discovery
- 10. Iterate Quickly Small change Measure success Adjust
- 11. How did an SOA help?
- 12. Discrete focus for the mind For the individual For the team
- 13. Ownership and personal responsibility Abstraction allows ownership and autonomy Test your own work Manage your own releases Definition of done: In Production
- 14. Pragmatic test coverage Honour your SLA’s Focus on unit tests Test where you need it Test in production?
- 15. Continuous Delivery Independent Releases A mindset or philosophy Product of behavioural changes
- 16. Observations?
- 17. Faster iterations Smaller pieces of work Faster feedback loop Focus on why?
- 18. Greater Collaboration Visual Design / UX and engineers collaborating Devops Responsibility for Quality is shared
- 19. Better Quality The QA paradox Bugs managed themselves
- 20. Steady cadence Predictable Wider understanding of capability Features ‘grew’
- 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