In this presentation we will look at strategies we can use to make a more nimble commerce platform that developers are excited to contribute too and customers are wow'ed by its ease of use.

2. INTRODUCTION
• IDENTIFYING QUICK WINS
• CONTINUOUS DEPLOYMENT
• API FIRST APPROACH
• SHIFTING FROM MONOLITHIC TO
MICROSERVICES
• FEATURE CANDIDATES FOR REAL IMPACT
• GROWING THE TEAMS TO MAKE IT HAPPEN

3. PLEASE ASK QUESTIONS!

5. TYPES OF QUICK WINS
• RESOLVE AS MANY BUGS AS POSSIBLE
• UPGRADE THE LOOK AND FEEL TO CURRENT
• TRANSPARENT CUSTOMER COMMUNICATION
• BUILD AROUND THE PLATFORM, NOT IN IT

6. FIXING CUSTOMER ISSUES
THERE ARE 900 ”BUGS” IN THE SYSTEM OVER THE PAST FEW YEARS

7. BUG BASHING FIRST
• PLATFORM TEAM IN BUG BASHING MODE
• PRIORITIZING THE LOW HANGING FRUIT
• FIXING THE TOP ISSUES OUR CUSTOMERS ARE
DEALING WITH
• COMMUNICATE OUR RE-FOCUS TO THE
CUSTOMERS

8. “
”
DELETED CODE IS DEBUGGED CODE.
- JEFF SICKEL
• THIS EFFORT IS HAPPENING NOW AND WILL CONTINUE THROUGH-OUT THIS YEAR
• FOCUSING ON CODE REMOVAL, OR REFACTORING OFF EXISTING PLATFORM

9. TRANSPARENCY WITH THE CUSTOMER
• STATUS PAGE
• FEATURE REQUESTS
• OWNING UP TO OUR PAST

10. MODERNIZE THE PLATFORM UI
FRESHENING UP OUR PLATFORM’S LOOK AND FEEL IS AN EASY WIN

11. APPLYING THE
MODERNIZATION
ADMIN UI REFRESH

12. APPLYING THE
MODERNIZATION
ADMIN UI REFRESH

13. APPLYING THE
MODERNIZATION
ADMIN UI REFRESH

14. APPLYING THE
MODERNIZATION
STOREFRONT REFRESH

15. APPLYING THE
MODERNIZATION
STOREFRONT REFRESH

16. “
”
SIMPLICITY IS THE ULTIMATE FORM OF
SOPHISTICATION.
- LEONARDO DA VINCI
• ADMIN RESKIN TO BE LAUNCHED IN Q2
• NEW STOREFRONT TO BE LAUNCHED IN Q2

18. START WITH CONTINUOUS DELIVERY
• UNDERSTAND ROAD BLOCKS
• WORK TO REMOVE ROAD BLOCKS
• AUTOMATE PATH TO PRODUCTION
• PERFORM PATH TO PRODUCTION MANUALLY
• TEST AUTOMATICALLY
• MEASURE AUTOMATICALLY

19. THEN CONTINUOUS DEPLOYMENT
• AUTOMATE LAST STEPS THROUGH
• AUTOMATIC TESTING – RESULTS
• AUTOMATIC MEASUREMENT – RESULTS

20. CI/CD STRATEGIES
• A / B – BLUE / GREEN – CANARY
• DARK LAUNCHING
• SLOW BLEED OVER OF TRAFFIC
• NON-DESTRUCTIVE DEPLOYMENTS
• ROLL BACK BECOMES SWAP TO LAST
• EXCEPT DB
• MEASURE ANYTHING / MEASURE EVERYTHING
• CREATE AND WATCH BASELINES
• LISTEN FOR UNACCEPTABLE DRIFT
• EXCEPTIONS, OUTAGES, RESPONSE TIMES
• DASHBOARD FOR ”ALL THE THINGS”
• PROD LIKE EVERYWHERE

21. “
”
PROGRAM TESTING CAN BE USED TO
SHOW THE PRESENCE OF BUGS, BUT
NEVER TO SHOW THEIR ABSENCE!
- EDSGER DIJKSTRA
• AS SIMPLE AS POSSIBLE, LESS COMPLEXITY IS BETTER
• PROD LIKE FROM THE START ENABLES NO SURPRISES DOWN THE ROAD
• MEASURE ANYTHING, MEASURE EVERYTHING

23. DOG FOODING MAKES THE BEST API
• ENABLES CUSTOMER TO EXTEND THE PLATFORM
• DECOUPLE THE FRONT END FROM THE BACKEND
• OPEN UP MOBILE OPPORTUNITIES
• OPEN APP STORE FOR VOLUSION
• OPEN NEW MARKETS FOR VOLUSION

24. A COLLECTION OF SMALL API’S
• CAN BE WEB API
• CAN BE NODE.JS AND LAMBDA
• FRONTED BY GATEWAY
• DEPLOYS SEPARATE FROM FRONT END
• VERSIONED INDIVIDUALLY
From one big code base
To small specific
code bases

25. “
”
PLAN TO THROW ONE AWAY; YOU WILL,
ANYHOW.
- FRED BROOKS
• SMALL, PURPOSE BUILT APPS, WILL LAST LONGER
• SMALL, PURPOSE BUILT APPS, ARE EASY TO RE-WRITE

27. WHAT IS A MICROSERVICE?
• IT DEPENDS!
• CAN BE A 10 LINE LAMBDA METHOD
• CAN BE A WEB API PROJECT
• ALWAYS – JUST ENOUGH, NO MORE
• AUTONOMOUS
• HIGH RATE OF CHANGE NOT NECESSARY

28. N-TIER OF THE 90’S
• A COLLECTION OF LAYERS TO SEPARATE
CROSS CUTTING RESPONSIBILITIES
• ADDING FEATURES GOES SLOWER AS
UNDERSTANDING IMPACT GETS DIFFICULT
• SMALL CHANGES REQUIRE FULL TEST
SUITE EXECUTION

29. DEATH STAR
ARCHITECTURE
• A COLLECTION OF SERVICES THAT DO
THEIR SINGLE JOB WELL
• EACH SERVICE USES THE TECH THAT BEST
SOLVES THE JOB
• WIDTH VS. DEPTH APPROACH

30. GO FASTER, MOVE THE
COMPLEXITY
• INFRASTRUCTURE COMPLEXITY IS
INITIALLY HIGHER WITH MICROSERVICES,
BUT CAN ADD FEATURES FASTER
• LOWER INITIAL INFRASTRUCTURE
FRICTION IN MONOLITH, FEATURES GET
HARDER TO ADD OVER TIME

31. “
”
PERFECTION IS ACHIEVED NOT WHEN
THERE IS NOTHING MORE TO ADD, BUT
RATHER WHEN THERE IS NOTHING MORE
TO TAKE AWAY
- ANTOINE DE SAINT-EXUPERY
• JUST ENOUGH CODE, AND NO MORE
• NO PRECONCEIVED TECHNOLOGY CHOICES MADE UP FRONT
• CAN BE 5 LINES OF CODE, CAN BE A VISUAL STUDIO “PROJECT”

33. HOW TO IDENTIFY
• CAUSES INTERNAL CUSTOMERS PAIN
• CAUSES EXTERNAL CUSTOMERS PAIN
• IMPACTS STABILITY OF THE PLATFORM
• NOT PART OF OUR CORE OFFERING
• REQUIRES COMPLEX UNDERSTANDING
• RIDDLED WITH BUGS
• BUILT ON OLD, NO LONGER SUPPORTED,
TECHNOLOGY
• GET OUT OF THE HABIT OF
“NOT INVENTED HERE”

34. WE CAN BUY SOME FEATURES
• SEARCH, TAX, SHIPPING, IMAGE RESIZE, APPLICATION ACCELERATION,CDN

35. VOLUSION SEARCH
• CUSTOM BUILT ON SQL SERVER
• MORE COMPLEX THAN NEEDED
• INDEXING CAN CAUSE OUTAGES
• MISSINGFEATURES
• HARD TO SET UP
• CONFUSES CUSTOMERS

36. SEARCH AS A SERVICE
• ANOTHER COMPANY’S CORE OFFERING
• FACETED & FILTERING OUT OF THE BOX
• RE-INDEXING IN REAL TIME
• MULTI-LANGUAGE SUPPORT
• SUPPORTED BY THEM, NOT US
• PROMOTES EROSION OF OLD TECH

37. WE CAN BUILD OTHER FEATURES
• STORE FRONTS – API’S – ADMIN INTERFACE – STYLE EDITOR – PRODUCT CATALOG

38. STORE FRONTS CAN BE RE-WRITTEN
REASONS TO REFACTOR
• NEW RESPONSIVE BASE THEME
• STYLE EDITOR
• HTML RESTRUCTURE
• HTML 5
REASONS TO RE-WRITE
• MOVE OF OF ASP CLASSIC
• DECOUPLE FROM THE PLATFORM
• SEPARATE DEPLOYMENT FREQUENCY
• ONE TEAM OWNERSHIP

39. WHERE DO WE START?

40. LOOK AT THE
PLATFORM

41. IDENTIFY TARGET:
SEARCH
• SEARCH AS A SERVICE
• ADDS FEATURES: BOOST, FILTERING,
FACETING, AUTO-INDEXING
• STABILIZES PLATFORM
• REDUCES DATA FOOT PRINT
• REDUCES INFRASTRUCTURE FOOTPRINT

42. DO THE WORK
• BUILD NEW SEARCH UI
• SYNC STORE DATA TO SEARCH SERVICE
• HOOK INTO DATA UPDATES
• HOOK INTO DATA IMPORTER
• ADD FEATURE TOGGLES
• SLOWLY ROLL STORES OVER TO NEW SEARCH

43. IDENTIFY TARGET:
STOREFRONT
• ALREADY UPDATING THE STRUCTURE
• ADDING NEW THEME STRATEGY
• ADDING STYLE EDITOR
• API’S COMING ON LINE

44. DO THE WORK
• STOREFRONT AS STAND ALONE APP
• BUILT FROM THE API OUT
• STRUCTURED FOR FLEXIBLE THEMING
• HEAVILY CACHEABLE (CDN)

45. THE GOAL IS TO ERODE
THE PLATFORM
WE ARE STILL AFLOAT BUT WE NEED TO
RE-PLATFORM AS QUICKLY AS WE CAN
• SMALLER AND LIGHTER COMPONENTS
• BUILD A FEELING OF OWNERSHIP
• GET IN FRONT OF OUR COMPETITION
from oil tanker
to
container ship

46. NOT LESS FEATURES!
JUST LESS COMPLEXITY IN THE FEATURES
THINK LEGO!

48. THAT LOOKS LIKE A
LOT OF WORK!
• WE’VE ALREADY STARTED:
• BUG BASHING
• ADMIN REFACTOR
• STYLE EDITOR
• CONTENT BUILDER
• SEARCH AS A SERVICE

49. WE WANT
TO GO FASTER!
• FORMALIZING THE “API TEAM”
• EXPANDING THE FRONT END TEAM
• EXPANDING THE PLATFORM TEAM
• GROWING QA
• ADDING DEVOPS
• REALIGNING PROCESSES

50. BUT WE CAN’T FORGET
• WE NEED PASSION
• SELF DRIVEN
• HIGHLY MOTIVATED
• EAGER TO SOLVE PROBLEMS