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.

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

15. Feature Sets Modularity
Resources
Deployment
Model

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

27. Legacy Real-time Modern Real-time