MongoDB Milano, 19 Aprile 2018

1. Con la partecipazione di:
La Modernizzazione dei Dati come
base per La Trasformazione
Digitale
MongoDB Milano, 19 Aprile 2018

2. • Le sfide della Trasformazione Digitale
• Evoluzione, innovazione, automazione:
cos'è la modernizzazione legacy
• Perché MongoDB?
• Storie di successo: OASI
• Q&A e Conclusione
Agenda

3. I Nostri Oratori
Marco Rapetti
Regional Director Italy,
MongoDB
marco.rapetti@mongodb.com
Massimo Brignoli
Principal Solutions Architect,
MongoDB
massimo@mongodb.com
Andrea Giuliani
Responsabile Ufficio Architetture
Innovazione e Qualità dei rilasci,
OASI
andrea.giuliani@oasi-it.it
Dario Verghi.
Enterprise Account Manager
MongoDB
dario.verghi@mongodb.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
AgileDev
Scalability
Opex vs Capex
TCO
24/7 availability
Global impact
Business criticality
Talent Acquisition

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
Dario Verghi.
Enterprise Account Manager
MongoDB
dario.verghi@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 Brignoli
Principal Solutions Architect,
MongoDB
massimo@mongodb.com

18. 18
Intelligent Operational Data Platform
Best way to work
with data
Intelligently put data
where you want it
Freedom to run
anywhere

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

20. 20
MongoDB is insanely easy for developers
Mentally easier
Consistent with
the way they code
Less work (less
code to write)

21. 21
Developers code using things
called “objects”

22. 22
Document Model
RDBMS
{
first_name: ‘Paul’,
surname: ‘Miller’,
city: ‘London’,
location: {
type : ‘Point’,
coordinates : [45.123,47.232]
},
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
]
}
MongoDB

23. 23
Documents are Rich Data Structures
{
first_name: ‘Paul’,
surname: ‘Miller’,
cell: 447557505611,
city: ‘London’,
location: {
type : ‘Point’,
coordinates : [45.123,47.232]
},
Profession: [‘banking’, ‘finance’, ‘trader’],
cars: [
{ model: ‘Bentley’,
year: 1973,
value: 100000, … },
{ model: ‘Rolls Royce’,
year: 1965,
value: 330000, … }
]
}
Fields can contain an array
of sub-documents
Typed field values
Fields can contain arraysFields

24. 24
Documents are Flexible
• Documents in the same product catalog collection in MongoDB
{
product_name: ‘Acme Paint’,
color: [‘Red’, ‘Green’],
size_oz: [8, 32],
finish: [‘satin’, ‘eggshell’]
}
{
product_name: ‘T-shirt’,
size: [‘S’, ‘M’, ‘L’, ‘XL’],
color: [‘Heather Gray’ … ],
material: ‘100% cotton’,
wash: ‘cold’,
dry: ‘tumble dry low’
}
{
product_name: ‘Mountain Bike’,
brake_style: ‘mechanical disc’,
color: ‘grey’,
frame_material: ‘aluminum’,
no_speeds: 21,
package_height: ‘7.5x32.9x55’,
weight_lbs: 44.05,
suspension_type: ‘dual’,
wheel_size_in: 26
}

25. 25
MongoDB is Full-Featured
Rich Queries
Find Paul’s cars
Find everybody in London with a car between 1970 and 1980
Geospatial Find all of the car owners within 5km of Trafalgar Sq.
Text Search Find all the cars described as having leather seats
Aggregation Calculate the average value of Paul’s car collection
Map Reduce
What is the ownership pattern of colors by geography over time
(is purple trending in China?)

26. 26
Model of the Aggregation Framework

27. 27
Analytics & BI Integration

28. 28
Intelligently
put data where
you want it
Availability Scalability
Workload
Isolation
Locality

29. 29
Replica Sets
• Replica set – 2 to 50 copies
• Replica sets make up a self-healing ‘shard’
• Data center awareness
• Replica sets address:
• High availability
• Data durability, consistency
• Maintenance (e.g., HW swaps)
• Disaster Recovery
Application
Driver
Primary
Secondary
Secondary
Replication

30. 30
Runs the
same
everywhere
Coverage
in
any geo
Leverage
multi-cloud
strategy
Avoid
lock-in
Freedom
to run anywhere

31. L’Esperienza di OASI
Andrea Giuliani
Responsabile Ufficio Architetture
Innovazione e Qualità dei rilasci,
OASI
andrea.giuliani@oasi-it.it

32. 32
• Leader nel mercato bancario, assicurativo e finanziario, propone:
– soluzioni informatiche,
– servizi di outsourcing applicativo e amministrativo, progetti
– Aree: sistemi direzionali e di sintesi, segnalazioni agli organi di vigilanza nazionale e comunitaria,
antiriciclaggio.
• Le soluzioni devono adattarsi ai continui cambiamenti normativi
• Nuove esigenze di mercato impongono prodotti:
– più performanti
– calabili per grandi clienti
– sviluppati con linguaggi di programmazione moderni
– Facili e veloci da manutenere
Chi è OASI

33. 33
• Poter gestire un cliente 13 volte più grande rispetto al maggior cliente
attualmente in servizio di outsourcing, nei tempi compatibili con le
scadenze ufficiali. Abbattere significativamente i tempi elaborativi :
– caricamento,
– generazioni
– predisposizione del db a fini di reporting
• Adeguamento alle nuove normative e alle nuove direttive
Nuove Necessità

34. 34
• Le informazioni devono essere disponibili in modo:
• Friendly:
– Report regolamentari standard sempre disponibili e aggiornati
– Report navigabili in modalità drill-down fino alla massima granularità
• Open:
– Accessibili con servizi SOA e/o Rest
– Esportabili in maniera rapida ed intuitiva
– I dati devono essere disponibili al massimo dettaglio ma velocemente aggregabili secondo l’esigenza
del business
• Fast:
– I dati devono essere sempre aggiornati in tempi veloci
– Il tempo di aggiornamento dei dati non deve essere proporzionale al volume dei dati trattati, ma si
deve poter far scalare il sistema mantenendo costante il tempo di elaborazione
Requisiti della Nuova Architettura

35. 35
DBMS tradizionalmente utilizzati
Schema Tabellare Scalabilità
Schemirigidiresistentiai
cambiamenti
Trasferimentodeidati &
Costirendonolascalabilità
difficilmentepraticabile
Ilformatodeidaticambianocostantemente,
Inmolticasimoltofrequentemente
Iclusterrichiedonosoluzionidicompromesso
perlimitareIvolumi

36. 36
Requisiti del Nuovo Database
Schema Flessibile
01
10JSON
Scalabilità
Orizzontale
…
Schemaflessibileèadattoasupportare cambiamenti
Alcresceredeivolumisiaggiungononodisuhardwaredi
costocontenuto

37. 37
Requisiti del Nuovo Database
Scalabilità
L’architettura deve permettere di partire con una configurazione di
«basso profilo» che soddisfi le necessita iniziali e che possa essere in
seguito adeguata in base alle necessità crescenti, e quindi abbia la
possibilità di scalare sia orizzontalmente (ovvero con l’aggiunta di
nodi o il cambio di hardware) o verticalmente (ovvero aumentando le
le risorse dei vari server).
Quindi dovranno essere privilegiate nella scelta quelle soluzioni che
possano operare in ambienti ridondati (sia cluster che con presenza
di bilanciatori) senza modifiche applicative e che possano lavorare
in-memory.
Scale-up
Scale-out
In-memory

38. 38
Requisiti del Nuovo Database
Base dati a schema flessibile
• Aggiungere, rimuovere o modificare gli attributi delle Entità
deve essere agile senza sforzi per i test di non regressione.
• I nostri utenti concepiscono più facilmente i dati contenuti
all’interno di un unico documento. Fino ad oggi gli abbiamo
invece divisi per categorie e riuniti nella loro esposizione.
Codice sorgente unico
• Le varie applicazioni, ed i linguaggi di programmazione,
devono essere installate su diverse piattaforme hardware e su
vari sistemi operativi
• Privilegiare quelle applicazioni che prevedono l’utilizzo di
linguaggi cross-platform e che sfruttino al massimo le risorse
hardware
AGILE
High
Performance

39. 39
NDG Name Stato Punteggio Verifica Fascia
9950 Mario Rossi 086 35 Rafforzata A
Modello Tabellare
PuntID BenFK Punt
100 1 15
200 2 20
Codice
Dato
NDGF
K
PuntFK
1 9950 100
2 9950 200
DatoID Descr
1 Liste
2 Inatteso
StatoID Descrizione
086 Italia
FasciaID Descrizione
A Alta
Profilo
Calc
35
Stato
Italia 086
Dato
liste
Inatteso
La struttura
Documentale
evita JOINs
per maggiori
performance e
semplicità di
utilizzo

40. 40
NDG Name Stato TitleID Verifica Fascia
9950 Mario
Rossi
086 1500 Rafforzat
a
AListe 15
Inattes
o
20
Modello Documentale
PuntID Benefit Punt
100 Liste 15
200 Inatteso 20
Profilo
35
Stato
Italia 086
{
_id : 9950,
name: “Mario Rossi",
Stato : { codice : “086",
descrizione: “Italia" },
Profilo : 35,
verifica: “Rafforzata",
fascia: “A",
dettaglio : [
{ punteggio : 15,
dato : “liste” },
{ punteggio : 20,
dato : “inatteso” }
]
}
La struttura
Documentale evita
JOINs per maggiori
performance e
semplicità di utilizzo

41. 41
Back-End Technical Architecture - Overview
Input streams
from external systems
IBM DataStage
Mongo DB
Catalog
Data
Collection
IBM ODM
BI
Analytics
Java
Back-End
Data Governance
Environment
Develop
Environments
Data
warehouses
Web
Application
Office Online
Server
Sistema di Produzione

42. Thank you.