Recommended
More Related Content
What's hot
What's hot (11)
Similar to Scaleconf 2018: I used to be an architect
Similar to Scaleconf 2018: I used to be an architect (20)
Recently uploaded
Recently uploaded (20)
Scaleconf 2018: I used to be an architect
- 1. ScaleConf 2018 Dom Parry CTO: Simply Financial Services I used to be an architect
- 2. Simply: What we do Simple issue, direct life insurance, at better value than currently available in the market
- 3. Simply: How we do it •Highly experimental •Evidence driven decisions •Human centred design •Rapid iterations •As simple as possible
- 4. Simply: How we do it
- 5. Simply: How we do it
- 6. The Simply tech team Simply Tech Team Pieter (Full Stack) Aya (Front-end) Pierre (UX Lead) Gwena (Full stack) Dom
- 7. The Path
- 8. Typical tech career path
- 9. So this is what we’re set up for. Right? Income Happiness
- 12. My path Developer Solution Architect Enterprise Architect IT Strategist Integration Architect Consultant Architect Chief Architect Solutions Sales SME IT Strategy Director Programme Manager Startup CTO
- 13. My tools as an architect
- 14. But…. What did I learn?
- 15. What did I learn? Strategy is important,
- 16. What did I learn? but the value is in the delivery.
- 17. What did I learn? Architecture is important,
- 18. What did I learn? but ivory towers are harmful.
- 19. What did I learn? Standards (and frameworks) are helpful,
- 20. What did I learn? but not at the expense of new ideas.
- 21. What did I learn? Stability is a great goal,
- 22. What did I learn? but stagnation is a real killjoy.
- 23. What did I learn? Technology may build the product,
- 24. What did I learn? but sales bring in the cash!
- 25. What did I learn? Programme management is the worst job in the world.
- 26. What did I learn? No, really.
- 27. So, I used to be an architect OSS Systems MDM BI User Interface Users Users Subscribers / Devices interactingwith Network Subscribers , Partners, Employees Interactingwith IS Transformation Framework Network Old World BSS OSS ESB BPM New World IntegrationInfrastructure: bustechnology/middleware/businessprocessmanagement Strategy, Infrastructure & Product Operational Support & Readiness Fulfilment Assurance Billing Market_Sales Domain Campaign & Funnel Managemen t Sales & Marketing Reporting Compensati on & Results Sales Account Management Sales Account Management Channel Sales Managemen t Solution Managemen t Contract Management Sales Portals Product Domain Product Lifecycle Management Product Strategy / Proposition Management Product Catalogue Managemen t Product Performance Managemen t Cross Domain Catalog Management Fallout Management Customer Domain Customer Information Management Transaction Document Production Customer Order Managemen t Case Managemen t Customer SLA Manageme nt Customer Problem Manageme nt Receivables Management Billing Account Management Billing Enquirey, Dispute & Adjustment Managemen t Collection Management Bill Calculation Billing Events Management Bill Format / Render Charge Calculation and Balance Management Customer Self Management Customer Retention Management Customer Loyalty Management Customer Service Representative Toolbox Service Domain Service Catalog Managemen t Service Inventory Managemen t Service Test Management Service Order Managemen t Service Problem Managemen t Service Quality Managemen tService Performance Managemen t Resource Domain Resource Lifecycle Management Workforce Management Network Number Inventory Managemen tResource Inventory Management Location Managemen t Resource Test Management Resource Process Management (Workflow/Integration) Resource Domain Management Resource Order Managemen t Resource Performance Management Fault Managemen t Voucher Management Usage Management Supplier_Partner Domain Partner Management Supply Chain Management Wholesale / Interconnect Billing Enterprise Domain Revenue Assurance Management HR Management Financial Managemen t Administrati ve Services Regulatory & Compliance Managemen t Fraud Management Knowledge Management Security Managemen t Asset Management
- 28. What didn’t I learn? I knew nothing about: •Infrastructure •Development tooling •Ops •Scaling •Data •CSS
- 29. The Journey
- 30. The Journey: The Event – March 2016
- 31. The Journey: The Event – March 2016
- 32. The Journey
- 33. The Build
- 34. Concept (06/2016) Strategy(06/20 16) Vendor engagement (07/2016) Design(08/201 6) Build (09/2016) Soft Launch (end 10/2016) Go-Live! 11/2016) The Build: September & October 2016
- 35. The Build: September & October 2016
- 36. The Build: Tech Stack
- 37. The Build: All the data, all the time.
- 38. There is no such thing as big data
- 39. There is no such thing as big data
- 40. There is no such thing as big data
- 41. There is no such thing as big data
- 42. There is no such thing as big data
- 43. There is no such thing as big data
- 44. There is no such thing as big data
- 45. The shift (what did I learn 2.0)
- 46. The shift Instead of off the shelf, pre- built and pre-integrated,
- 47. The shift build only what we need, nothing you don’t.
- 48. The shift Instead of specialised individuals with specific skills,
- 49. The shift find curious, wonderful human beings that love tech.
- 50. The shift Becoming the expert feels awesome,
- 51. The shift but learning something completely new is often more rewarding.
- 52. Finally: stuff we really like •Automation keeps the team small •All the data, all the time •Functional programming •Build only what you need, and nothing you don’t •Hammock Driven development •Stay Curious
- 53. Thanks for listening, Questions Welcome. (I still know nothing about CSS.) I’m done.
Editor's Notes
- Hi, I’m Dom. Thanks for having me. But more importantly, this is simpleton.
- Simple issue life = simple underwriting, no medical tests. We’re generally competing with people like Sanlam sky, Vodacom, FNB, ABSA, etc on product, but attempting to compete with fully underwritten cover on price (for some strategic profiles).
- We basically live by the principles in this book, but specifically, the business is: - Highly experimental – in every aspect. From Acquisition to collections. We experiment with Tech, Marketing messaging and creative, ad placements, scripting in the call centre, collections techniques - Evidence driven decisions – We measure everything, Compare it to previous results, and decide what to try next. - Human centred design – Every aspect of the business from policy documents to ux to the products themselves try to leverage the human centred design. We test different versions of products, docs, etc with as many people as we can. - Rapid iterations – build – measure - learn. As fast and often as possible (While collecting enough evidence in between). - As simple as possible – Our favourite word here is blowtorch. The site, the process, our code, the messaging. It’s everywhere.
- Here's an example the results in a bunch of UX feedback, hotjar, and user feedback sessions. - Slider - Amounts - Checkbox - Clicking Progress bar
- Here's an example the results in a bunch of UX feedback, hotjar, and user feedback sessions. - Slider - Amounts - Checkbox - Clicking Progress bar
- Small team. Only recently increased from 3 to 5.
- This is a typical career path of a developer right? Trying to “move up”?
- I would argue it most likely looks a little more like this.
- Certainly for me, the experience was more like this. Allow me to briefly tell you the story. More reasons here for why it is a trap.
- I moved back into integration architecture because I always felt something was missing.
- I used to tell people that you should spend as little time as possible at work. I chased money, hard. I was very unhappy.
- Of course, we need to know where we’re headed. This is at all levels. The business, each department, and roughly how to get there. Tech is there as an enabler to strategy, and so it needs to be planned in step with the business. Not separately on the side, but together with the business. These are broad strokes, BHAGs
- Strategy alone doesn't ship products / features. I once worked for a large partially government owned telecommunications company. We did 3 massive strategy exercises to plan out how we were going to completely modernise our systems. I worked there for 6 years, and never saw one of those programmes even start.
- If strategy defines where we going, I'd say Architecture talks a little more to how we're planning on getting there. Possibly defines some of the rules of the game.
- "Thou shalt"
- Don’t try be stable by inaction. The business moves, so you shouldn’t lose the ability to be flexible.
- Change slide and add animation.
- Change slide and add animation.
- I remember thinking something on the the day that I started watching the GCP next videos. Where the hell have I been hiding! Greg Young – Event Sourcing / CQRS Rich Hickey Sam Newman Jez Humble
- I don’t have a better way to summarise this period. One week before production, we switched to Kube **** Crop the twitter pic ****
- I don’t have a better way to summarise this period. One week before production, we switched to Kube **** Crop the twitter pic ****
- First go through all the things, and then: Key points: - Automation - Use what’s available
- Examples of data processes we run, on tiny infrastructure.
- Examples of data processes we run, on tiny infrastructure.
- Examples of data processes we run, on tiny infrastructure.
- Examples of data processes we run, on tiny infrastructure.
- Examples of data processes we run, on tiny infrastructure.
- Examples of data processes we run, on tiny infrastructure.
- Great quote from someone in my team: “doing mostly hammocking today, and the more I don’t write code, the less code I have to write”