SlideShare a Scribd company logo

Comparing Legacy and Modern e-commerce solutions

•Download as PPTX, PDF•
•
Mike Ensor
Mike Ensor

As a result of fantastic growth, the software industry has undergone the next step in "solution evolution" over the past 5 years. Enablement tools like Docker, AWS/GCE/Azure, OSS visibility/availability and architecture structures such as distributed computation, microservices, event sourcing and reactive solutions have brought forth more robust and scaleable solutions. The platforms of the past have either kept up with the trends and become more nimble and lean, or have fallen off to the side and become relics of the past. This deck discusses the differences between large monolithic e-commerce platforms versus more modern, lean e-commerce frameworks and why architectural structures are important when selecting a platform to increase the likelihood of future proofing your solution.

Related slideshows

Achieving Microservices Maturity
Achieving Microservices MaturityAchieving Microservices Maturity
Achieving Microservices Maturity
 
2015-12-02 - WebCamp - Microsoft Azure Logic Apps
2015-12-02 - WebCamp - Microsoft Azure Logic Apps2015-12-02 - WebCamp - Microsoft Azure Logic Apps
2015-12-02 - WebCamp - Microsoft Azure Logic Apps
 
Mule iON - OSS ESB to iPaaS
Mule iON - OSS ESB to iPaaSMule iON - OSS ESB to iPaaS
Mule iON - OSS ESB to iPaaS
 
1 of 29
Legacy vs Modern e-commerce Mike Ensor – Practice Director, Digital Transformation Services
Dev9 provides technology delivery that dramatically improves time-to-market. We make software delivery predictable and transparent with a high level of automation.
Java & JavaScript Continuous Delivery Application Platform Modernization Amazon Web Services Content Management and Custom e- commerce Identity Management Software Quality Strategy & Implementation
Mike Ensor • Dev > Architect > Mgmt • Worked with many e-commerce platforms • ATG, Demandware, Intershop, Broadleaf, hybris, os commerce, magento, CommerceTools • 9 major e-commerce implementations
•Why do we care about modernization? •What is legacy anyway? •Compare critical areas for modern software •Conclusion •Q&A
Comparing Legacy and Modern e-commerce solutions
Comparing Legacy and Modern e-commerce solutions
• Software degrades with time • 3-5 year shelf-life • Fear of change • Companies evolve • New features • Respond to customer demand • Regulation and compliance changes • Company changes directions • Speed, quality, performance enhancements • Mergers and acquisitions • New leadership or competition
•Security risks •Out of compliance/regulatory •Incompatibility w/new software, techniques and delivery methods •Rising operational costs • Resources are rare and expensive • Infrastructure costs • Lose top resources •Decreasing time-to-market and feature development
Complexity Resources Budget Requirements Political capital Fear
•E-commerce is no longer a side division •Sports Authority •Scale is everything •Victoria Secret and Macy’s •Closing gap vs brick-and- mortar •2016 online sales up 4.2%
•What replaces legacy for e- commerce? •Case study: Amazon Go •Modern software delivery (CI/CD) •Shareability of data •Built for integration •Machine Learning, hardware, inventory, identity mgmt, mobile devices, many, many more
• Large monolith tied to single enterprise database • License costs tied to success • Quarterly or Yearly updates • Center of architecture • Desktop first, bolt on channels later • Scale added as bolt-on • Requires downtime or low volume for updates • Limited hosting options
• Reduce costs and increase speed with full automation • Tools & processes to mitigate risk • Encapsulate functionality (modularity) • Operate within the ecosystem • Highly communicatable • Designed for scale • Payment type that doesn’t prohibit scale • *-First (quality, cloud, mobile, i18n, security) • Framework over Features • Microservcies and Reactive Programming
Feature Sets Modularity Resources Deployment Model
•Large feature sets are like concrete • Slow feature growth • Long time-to-market • Quarterly or longer • Requires larger QA regression • Most companies do not use a fraction of features •Overloaded functions cause version lock •Can’t create common feature set beyond generic •Most companies don’t use all of the features
• Provides building blocks for commerce • Products, Categorization/Catalog, Promotions, Cart, Basic pricing, Checkout, Customers • Decoupled Entities • Domain Driven • Quality first: Includes automated testing coverage • Ensure core functionality continues to work • Flexible enough to extend for integrations • Designed for feature extension • Custom Attribute/Value support • More in a moment • Liskov principle for feature enhancement
• Community-driven or closed modules • Introducing risks • Security, roadmap, additional licenses, ownership, performance, inconsistent UX • Inconsistent development standards • Bolt-on functionality • Often through M&A (aka “Oracle Integrated” or “Frankenstein”) • Course grained • Monolithic application • Small changes require full deployment • ”Modules” are built into the application • Mitigated using Enterprise Service Bus (ESB) • Channels are additional “sites” • Back office “jobs” are same system
• Utilize or enable microservices • Loosely coupled, highly cohesive, independent services • Functionality in services by domain • Promotes re-use across ecosystem • Makes use of modern practices such as reactive development • Use of queues • Addresses common parallel functionality • Utilize interfaces over concrete services • Ephemeral compute components
•Legacy experience is expensive •Require specialized training & certifications •Estimated certification costs ~$30k for IBM Advanced Developer •Proprietary source •Hidden documentation and community
• Leverage Open Source technologies • Right tool for the job • Utilize tools for frequent, quality releases • General technologists over specialists • Only train for “commerce” concepts • Large abundance of developers • DevOps and Continuous Delivery at core • Practice Agile development methodologies
• Monolithic application relying on single enterprise database • Difficulty in changing model or data • Small changes result in entire deployment • Long boot times • “Big Bang” deployments • Software and architecture not designed for horizontal scale • Not ready for cloud • Inefficient static infrastructure • Licenses based on best-guess “peak” numbers
• Utilize microservices • Containers for isolated deployments • Immutable infrastructure • Smaller work in progress (WIP) • Extend functionality w/ external services • Framework over Platform • Cloud First mentality • Start with Continuous Delivery • Respond quickly to changes in market • Apply updates as they become available • Designed for multiple uses (true omnichannel) • Architected on top of APIs
Comparing Legacy and Modern e-commerce solutions
•Focus on data and service shareability within enterprise •Resources are expensive, pick technologies to reduce costs from proprietary software •Composability and distributed computing allows for less downtime and allows scale where needed •Large feature sets inhibit growth and slow down patches •Cloud-first architectures provide flexibility
Thank You! Contact Us for Help or Questions mike.ensor@dev9.com
Legacy Real-time Modern Real-time
Comparing Legacy and Modern e-commerce solutions
Comparing Legacy and Modern e-commerce solutions

More Related Content

Comparing Legacy and Modern e-commerce solutions

  • 1. Legacy vs Modern e-commerce Mike Ensor – Practice Director, Digital Transformation Services
  • 2. Dev9 provides technology delivery that dramatically improves time-to-market. We make software delivery predictable and transparent with a high level of automation.
  • 3. Java & JavaScript Continuous Delivery Application Platform Modernization Amazon Web Services Content Management and Custom e- commerce Identity Management Software Quality Strategy & Implementation
  • 4. Mike Ensor • Dev > Architect > Mgmt • Worked with many e-commerce platforms • ATG, Demandware, Intershop, Broadleaf, hybris, os commerce, magento, CommerceTools • 9 major e-commerce implementations
  • 5. •Why do we care about modernization? •What is legacy anyway? •Compare critical areas for modern software •Conclusion •Q&A
  • 8. • Software degrades with time • 3-5 year shelf-life • Fear of change • Companies evolve • New features • Respond to customer demand • Regulation and compliance changes • Company changes directions • Speed, quality, performance enhancements • Mergers and acquisitions • New leadership or competition
  • 9. •Security risks •Out of compliance/regulatory •Incompatibility w/new software, techniques and delivery methods •Rising operational costs • Resources are rare and expensive • Infrastructure costs • Lose top resources •Decreasing time-to-market and feature development
  • 10. Complexity Resources Budget Requirements Political capital Fear
  • 11. •E-commerce is no longer a side division •Sports Authority •Scale is everything •Victoria Secret and Macy’s •Closing gap vs brick-and- mortar •2016 online sales up 4.2%
  • 12. •What replaces legacy for e- commerce? •Case study: Amazon Go •Modern software delivery (CI/CD) •Shareability of data •Built for integration •Machine Learning, hardware, inventory, identity mgmt, mobile devices, many, many more
  • 13. • Large monolith tied to single enterprise database • License costs tied to success • Quarterly or Yearly updates • Center of architecture • Desktop first, bolt on channels later • Scale added as bolt-on • Requires downtime or low volume for updates • Limited hosting options
  • 14. • Reduce costs and increase speed with full automation • Tools & processes to mitigate risk • Encapsulate functionality (modularity) • Operate within the ecosystem • Highly communicatable • Designed for scale • Payment type that doesn’t prohibit scale • *-First (quality, cloud, mobile, i18n, security) • Framework over Features • Microservcies and Reactive Programming
  • 16. •Large feature sets are like concrete • Slow feature growth • Long time-to-market • Quarterly or longer • Requires larger QA regression • Most companies do not use a fraction of features •Overloaded functions cause version lock •Can’t create common feature set beyond generic •Most companies don’t use all of the features
  • 17. • Provides building blocks for commerce • Products, Categorization/Catalog, Promotions, Cart, Basic pricing, Checkout, Customers • Decoupled Entities • Domain Driven • Quality first: Includes automated testing coverage • Ensure core functionality continues to work • Flexible enough to extend for integrations • Designed for feature extension • Custom Attribute/Value support • More in a moment • Liskov principle for feature enhancement
  • 18. • Community-driven or closed modules • Introducing risks • Security, roadmap, additional licenses, ownership, performance, inconsistent UX • Inconsistent development standards • Bolt-on functionality • Often through M&A (aka “Oracle Integrated” or “Frankenstein”) • Course grained • Monolithic application • Small changes require full deployment • ”Modules” are built into the application • Mitigated using Enterprise Service Bus (ESB) • Channels are additional “sites” • Back office “jobs” are same system
  • 19. • Utilize or enable microservices • Loosely coupled, highly cohesive, independent services • Functionality in services by domain • Promotes re-use across ecosystem • Makes use of modern practices such as reactive development • Use of queues • Addresses common parallel functionality • Utilize interfaces over concrete services • Ephemeral compute components
  • 20. •Legacy experience is expensive •Require specialized training & certifications •Estimated certification costs ~$30k for IBM Advanced Developer •Proprietary source •Hidden documentation and community
  • 21. • Leverage Open Source technologies • Right tool for the job • Utilize tools for frequent, quality releases • General technologists over specialists • Only train for “commerce” concepts • Large abundance of developers • DevOps and Continuous Delivery at core • Practice Agile development methodologies
  • 22. • Monolithic application relying on single enterprise database • Difficulty in changing model or data • Small changes result in entire deployment • Long boot times • “Big Bang” deployments • Software and architecture not designed for horizontal scale • Not ready for cloud • Inefficient static infrastructure • Licenses based on best-guess “peak” numbers
  • 23. • Utilize microservices • Containers for isolated deployments • Immutable infrastructure • Smaller work in progress (WIP) • Extend functionality w/ external services • Framework over Platform • Cloud First mentality • Start with Continuous Delivery • Respond quickly to changes in market • Apply updates as they become available • Designed for multiple uses (true omnichannel) • Architected on top of APIs
  • 25. •Focus on data and service shareability within enterprise •Resources are expensive, pick technologies to reduce costs from proprietary software •Composability and distributed computing allows for less downtime and allows scale where needed •Large feature sets inhibit growth and slow down patches •Cloud-first architectures provide flexibility
  • 26. Thank You! Contact Us for Help or Questions mike.ensor@dev9.com