L'economia digitale costringe le aziende a innovare per rimanere competitive. Nessuno vuole essere il prossimo Blockbuster, costretto al fallimento da concorrenti più agili ed efficienti nello sfruttamento della tecnologia.

1. La Modernizzazione dei Dati come base
per La Trasformazione Digitale
MongoDB Roma, 4 Luglio 2018

2. • Le sfide della Trasformazione Digitale
• Evoluzione, innovazione, automazione:
cos'è la modernizzazione legacy
• Perché MongoDB?
Agenda

3. I Nostri Oratori
Marco Rapetti
Regional Director Italy,
MongoDB
marco.rapetti@mongodb.com
Diego Daniele.
Enterprise Account Manager
MongoDB
Diego.daniele@mongodb.com
Emanuele Molteni
Senior Solutions
Architect,
MongoDB
emanuele.molteni@mo
ngodb.com

4. Le Sfide della Trasformazione Digitale
Marco Rapetti
Regional Director Italy,
MongoDB
marco.rapetti@mongodb.com

5. 5
Business Priorities
Regulatory &
Compliance
Customer
Expectations
InnovationTime to Market
Margins and
Revenue
Growth
Talent

6. 6
IT Challenges
Data Applications Commercials Risk
Volume
Velocity
Variety
Silos
Time to value
Agile
Development
Scalability
Opex vs Capex
TCO
24/7 availability
Global impact
Business criticality

7. 7
Legacy
RDBMS systems were not created for today’s requirements and consequently try to bolt-on features to compensate for the lack of
capabilities. But this strategy can’t compete with data management systems designed & purpose-built to solve today’s problems.
Legacy RDBMS systems are falling short
Rigid Schemas
Resistant to
change
Throughput &
Cost make Scale-
Up Impractical
Relational Model Scale-up
Data changes constantly,
which fits poorly with a
relational model
Scale-Up clusters were never meant
to handle today’s volumes
Today
Flexible Model
01
10
JSON
Scale-out
Flexible Multi-Structured
Schema that is designed to
adapt to changes
Scale-out to the end of the
world and distribute data
where it needs to be

8. Che cos’è la Legacy Modernization
Diego Daniele.
Enterprise Account Manager
MongoDB
Diego.daniele@mongodb.com

9. 9
Legacy Modernization is a strategic IT initiative targeting a
portfolio of applications.
Multiple underlying technologies are rationalized with a new
technology stack, delivering significant savings to the business
while enabling other transformational initiatives.

10. 10
• Common limitations of RDBMS impeded progress
• Consolidated “data fabric” as future data platform
• £10M in savings in the first year and 100% uptime
Customer Story – Royal Bank of Scotland

11. 11
“Data Fabric will help reduce cost
significantly and dramatically increase
the speed at which we can deploy new
capabilities for our customers”
-Ross McEwan, CEO RBS
RBS’s Investor Report FY’16

12. 12
AutomateEvolve Innovate
Components of Legacy Modernization

13. 13
• Significantly reduce number of overall technologies used
• Seamless integration between modern applications
• Expertise with next generation technologies
• Permit new ways of working (i.e. devops and agile)
• Fully multi-tenant compliant
• Create predictable cost structure
Evolve

14. 14
• Self healing resiliency and elastic scalability
• Streamline engineering feature pipeline
• Self service deployments
Automate

15. 15
• Establish transparency in the data
• Increase development velocity and
deliver differentiated functionality
• Leverage data for new revenue
streams (four main areas of data
insight)
• Deliver new services or applications in
hours instead of months
Innovate

16. 16
Evolve InnovateAutomate
o Native multi-model
o Deployment-agnostic data
layer
o Consumption based
pricing
o MongoDB PS
o Flexible data model
o Native JSON drivers
• Continuous improvement
• On-platform data
processing and analysis
• Generate data insights
• Ops Manager /Cloud
Manager
• Atlas
• Built-in replication
• Scale on demand
• Self-service
Why MongoDB

17. Perché MongoDB?
massimo@mongodb.com
Emanuele Molteni
Senior Solutions Architect,
MongoDB
emanuele.molteni@mongodb.com

18. 18
MongoDB’s
Intelligent Operational Data Platform
is the best way of making your data simple
to Organize, Use, & Enrich
in Real Time, Anywhere

19. 19
Why MongoDB?
Best way to work
with data
Intelligently put data
where you need it
Freedom
to run anywhere
Intelligent Operational Data Platform

20. 20
Best way to work with data
Easy Flexible Fast Versatile

21. You probably have thousands of tables

22. 22
Easy: Contrasting data models
Tabular (Relational) Data Model
Related data split across multiple records and tables
Document Data Model
Related data contained in a single, rich document
{
"_id" : ObjectId("5ad88534e3632e1a35a58d00"),
"name" : {
"first" : "John",
"last" : "Doe" },
"address" : [
{ "location" : "work",
"address" : {
"street" : "16 Hatfields",
"city" : "London",
"postal_code" : "SE1 8DJ"},
"geo" : { "type" : "Point", "coord" : [
51.5065752,-0.109081]}},
+ {...}
],
"phone" : [
{ "location" : "work",
"number" : "+44-1234567890"},
+ {...}
],
"dob" : ISODate("1977-04-01T05:00:00Z"),
"retirement_fund" : NumberDecimal("1292815.75")
}

23. 23
Easy: Document data model
• Naturally maps to objects in code
• Represent data of any structure
• Strongly typed for ease of processing
– Over 20 binary encoded JSON data types
• Access by idiomatic drivers in all major
programming language
{
"_id" : ObjectId("5ad88534e3632e1a35a58d00"),
"name" : {
"first" : "John",
"last" : "Doe" },
"address" : [
{ "location" : "work",
"address" : {
"street" : "16 Hatfields",
"city" : "London",
"postal_code" : "SE1 8DJ"},
"geo" : { "type" : "Point", "coord" : [
51.5065752,-0.109081]}},
+ {...}
],
"phone" : [
{ "location" : "work",
"number" : "+44-1234567890"},
+ {...}
],
"dob" : ISODate("1977-04-01T05:00:00Z"),
"retirement_fund" : NumberDecimal("1292815.75")
}

24. 24
{
"_id" : ObjectId("5ad88534e3632e1a35a58d00"),
"name" : {
"first" : "John",
"last" : "Doe" },
"address" : [
{ "location" : "work",
"address" : {
"street" : "16 Hatfields",
"city" : "London",
"postal_code" : "SE1 8DJ"},
"geo" : { "type" : "Point", "coord" : [
51.5065752,-0.109081]}},
+ {...}
],
"dob" : ISODate("1977-04-01T05:00:00Z"),
"retirement_fund" : NumberDecimal("1292815.75")
}
Flexible: Adapt to change
Add new fields dynamically at runtime
{
"_id" : ObjectId("5ad88534e3632e1a35a58d00"),
"name" : {
"first" : "John",
"last" : "Doe" },
"address" : [
{ "location" : "work",
"address" : {
"street" : "16 Hatfields",
"city" : "London",
"postal_code" : "SE1 8DJ"},
"geo" : { "type" : "Point", "coord" : [
51.5065752,-0.109081]}},
+ {...}
],
"phone" : [
{ "location" : "work",
"number" : "+44-1234567890"},
+ {...}
],
"dob" : ISODate("1977-04-01T05:00:00Z"),
"retirement_fund" : NumberDecimal("1292815.75")
}

25. 25
Fast: To work with data
Compared to storing data
across multiple tables, a single
document data structure:
• Presents a single place for the
database to read and write data
• Denormalized data eliminates JOINs
for most operational queries
• Simplifies query development and
optimization
_id: 12345678
> name: Object
> address: Array
> phone: Array
email: "john.doe.@mongodb.com"
dob: 1966-07-30 01:00:00:000
˅ interests:Array
0: "Cycling"
1: "IoT"

26. 26
Versatile: Multiple data models, rich query functionality
Rich Queries
Point | Range | Geospatial | Faceted Search | Aggregations | JOINs | Graph Traversals
JSON Documents Tabular Key-Value Text GraphGeospatial

27. 27
Best way to work with data
Easy:
Work with data
in a natural,
intuitive way
Flexible:
Adapt and
make changes
quickly
Fast:
Get great
performance
with less code
Versatile:
Supports a
wide variety of
data models
and queries

28. 28
Intelligently put data where you need it
LocalityScalabilityWorkload IsolationHighly Availability

29. 29
High Availability
Replica Set – 2 to 50 copies
Self-healing
Data Center Aware
Addresses availability considerations:
• High Availability
• Disaster Recovery
• Maintenance
Workload Isolation: operational & analytics
Application
Driver
Primary
Secondary
Secondary
Replication

30. 30
Scaling (“Sharding”)
Multiple sharding policies: hashed, ranged, zoned
Increase or decrease capacity as you go
Automatic balancing for elasticity
Horizontally Scalable
•••Shard 1 Shard 2 Shard 3 Shard N

31. 31
Sharding Architecture
Application
Driver
Mongos
Primary
Secondary
Secondary
Shard 1
Primary
Secondary
Secondary
Shard 2
Primary
Secondary
Secondary
Shard N
Mongos ••••••
•••
High availability
- Replica sets
Horizontal scalability
- Sharding

32. 32
Intelligently put data where you need it
Locality
Declare data locality
rules for governance
(e.g. data sovereignty),
class of service & local
low latency access
Scalability
Elastic horizontal
scalability – add/remove
capacity dynamically
without downtime
Workload Isolation
Ability to run both
operational & analytics
workloads on same
cluster, for timely insight
and lower cost
Highly Availability
Built-in multi-region
high availability,
replication & automated
failover

33. 33
Freedom to run anywhere
Local
On-premises
Server & Mainframe Private cloud
Fully managed
cloud serviceHybrid cloud Public cloud
• Database that runs the same everywhere
• Leverage the benefits of a multi-cloud strategy
• Global coverage
• Avoid lock-in
Convenience: same codebase, same APIs, same tools, wherever you run

34. Thank you.