Il primo decennio degli anni '2000, professionalmente è stato caratterizzato dalla mia esperienza di formatore con la Sun Educational Services, la divisione della Sun Microsystems Italia che si occupava dei servizi di training.

In quel periodo la mia esperienza in DGS si era conclusa; volevo creare qualcosa di innovativo nel settore della formazione, ma nel nuovo modello di business di DGS la formazione non era più strategica, per questo motivo abbandonai l'azienda e fondai il Consorzio Copernicus. L'obiettivo era quello di rivoluzionare il mondo della formazione con le mie idee -  non fu un caso se scelsi il nome Copernicus.

Nel 2003, quando ci fu la fusione tra Telecom Italia e l'Olivetti, Adriana Fasano, la mia ex responsabile dell'area formazione in Olivetti, diventò  account manager education in Sun Educational Services. Questo evento mi diede l'opportunità d'iniziare a collaborare, attraverso il Consorzio Copernicus, con la più importante azienda di formazione al mondo. Naturalmente devo tutto ad Adriana Fasano che mi permise di entrare a far parte del suo team di formatori.

In Sun, collaboravo anche con Claudia Castellano responsabile dei servizi di formazione,  che ho conosciuto a Milano, quando tenevo i corsi persso la sede di v.le Fulvio Testi, 327 e Alberto Mosca,  che ho conosciuto a Roma, lui svolgeva il ruolo di commerciale.

Grazie ad Adriana Fasano, Claudia Castellano e Alberto Mosca, ho avuto l'opportunità di formare i dipendneti delle aziende d'informatica più importanti d’Italia.

All'inizio, facevo  corsi di Unix Sun Solaris, formavo i dipendenti delle aziende IT che utilizzavano le workstation oppure i server Sun; già conoscevo Unix System V (Unix System Five) e le mie conoscenze di C risultarono molto utili perché con Solaris si utilizzava la C shell, che permetteva di creare script Unix con il linguaggio C, mentre con Unix System V si usava la Korn shell, che invece permetteva di creare gli script Unix con un linguaggio proprietario.

Poi, a causa della profonda crisi del mercato dello sviluppo software che si verificò tra la fine degli anni '90 e l'inizio del 2000, Java diventò uno dei linguaggi di programmazione ad oggetti più utilizzati dai programmatori. Il passaggio dalla programmazione procedurale a quella ad oggetti creò una grossa richiesta di corsi, prima di alfabettizzazione e via via sempre di maggiore specializzazione. Fu così che iniziò la mia esperinza in Sun di formatore Java. 

QUANDO E' NATO L'OBJECT ORIENTED
Alla fine degli anni '90, il Modello a cascata (Waterfall) venne messo in discussione, perché non era adatto alla produzione di software di qualità sempre più complesso e che richiedeva la riusabilità del codice e  continui aggiornamenti.

Il Waterfall prevedeva che il ciclo di vita del software si basasse sulle seguenti fasi, svolte in sequenza: pianificazione (plan), analisi (analysis), progettazione (design), implementazione (code), collaudo (test), installazione (install), utilizzo (use),  come mostra l'immagine seguente:

Questo tipo di modello di sviluppo software andava bene solo per applicazioni dove i requisiti funzionali e di business, definiti durante la fase di analisi, non cambiavano nel tempo, altrimenti si rischiava di non soddisfare mai i clienti. 

Naturalmente cambiarono anche i linguaggi di programmazione utilizzati, tra questi quelli che ebbero il maggiore successo furono il linguaggio C++ (C plus plus) creato da Bjarne Stroustrup e il linguaggio Java creato da James Gosling della Sun Microsytems e il linguaggio C# (C sharp) creato da Anders Hejlsberg della Microsoft. 

Tutti è tre i linguaggi permettevano di sviluppare applicazioni orientate agli  oggetti, ma Java e C# erano stati pensati per il Web, per questo motivo erano trasportabili (generavano codice intermedio, diverso dal linguaggio macchina,  eseguibile con Virtual Machine), a differenza del C++ non permettevano l'ereditarietà multipla e disponevano di linguaggi di tipo SERVER SIDE come JSP (Java Server Page) per Java e ASP (Active Server Page) per C#, che permettevano di creare pagine Html dinamiche.

Per approfondire la conoscenza del linguaggio C clicca qui.
Per maggiori informazioni sugli oggetti e sul linguaggio C++ clicca qui.
Per imparare tutto quello che ti serve su Java Object Oriented clicca qui.

Allora conoscevo benissimo il C++ e in breve tempo, attraverso il supporto della Sun Educational Services, imparai tutto quello che bisognava sapere su Java.

Con il diffondersi di Java, iniziarono ad aumentare le richieste di corsi e di certificazioni Java da parte del mercato IT. Fu così che iniziò la mia esperienza di formatore esperto di linguaggio Java. Ricordo ancora i codici dei corsi che erogavo in tutta Italia:

1) SL-110 (Introduzione al linguaggio Java);
2) SL-275 (Java Programming Language);
3) SL-314 (Java Web Component);
4) SL-351 (Java Business Component);
5) FJ-310 (Developing Application for Java EE Platform);
6) SL-425 (Architecting and Designing J2EE Applications);
7) DWS-385 (Java Web Service);
8) DTJ-3109 (Developing Secure Web Applications).

A Roma, la sede della Sun si trovava in via Gian Domenico Romagnosi, 4,  nei pressi di p.zza del Popolo, ma i corsi si tenevano presso la sede di Atlantica, in P.zza Barberini, adiacente a Via Veneto e a pochi passi dalla fontana di Trevi e da P.zza di Spagna - è lì che ho imparato ad amare Roma e la Formazione, quella con la EFFE maiuscola.

Conservo ancora in libreria i manuali originali da cui studiavo:

Purtroppo, non trovo il manuale SL-275 Java Programming Language, devo averlo prestato a qualche collega o a qualche mio studente; in questo manuale c'era tutto quello che bisognava sapere per lavorare con Java SE (Standard Edition). Con questa versione di Java si potevano creare applicazione a due livelli di tipo desktop che permettevano di archiviare informazioni in un database relazionale.

Per creare le interfacce grafiche, inizialmente usavo la libreria Java AWT, successivamente passai alla libreria Java SWING, perché era molto più dinamica della precedente. Per gestire i database usavo la libreria Java JDBC, ovviamente combinata con il linguaggio SQL. 

Sono molto legato all'SL-275, perché tutte le conoscenze di Object Oriented che ho appreso da questo manuale sono state utili superare l'esame di certificazione Java Programmer.

LA PIATTAFROMA JAVA EE (ENTERPRISE EDITION)
La Sun Microsystems a dicembre del 1999 estende la versione Java SE con una versione molto più potente che, inizialmente venne chiamata Java 2 EE, poi qualeche anno dopo Java EE.

Java EE è un framework potente e completo per lo sviluppo e la distribuzione di applicazioni aziendali su larga scala, affidabili e sicure. Fornisce un'architettura solida e multilivello che separa i livelli di logica aziendale, presentazione e accesso ai dati, promuovendo modularità e manutenibilità.

La piattaforma comprende un'ampia gamma di API (Application Programming Interface) che facilitano vari aspetti dello sviluppo di applicazioni, come servizi Web, architettura basata su componenti e servizi a livello aziendale. Queste API aiutano gli sviluppatori a gestire attività come la connettività del database, la messaggistica, la gestione delle transazioni e la sicurezza, consentendo la creazione di applicazioni scalabili e ad alte prestazioni.

I componenti principali di Java EE sono:

• servlet
• JavaServer Pagine (JSP)
• JavaBean aziendali (EJB)
• API di persistenza Java (JPA)
• Servizio messaggi Java (JMS)
• API di transazione Java (JTA)
• JavaMail
• API Java per servizi Web RESTful (JAX-RS)
• API Java per servizi Web XML (JAX-WS)
• Interfaccia di denominazione e directory Java (JNDI).

Tutto quello che mi serviva per lavorare con questi nuovi componenti l'ho appreso dai manuali seguenti: 

1) SL-351 (Java Business Component);
2) FJ-310 (Developing Application for Java EE Platform);
3) SL-425 (Architecting and Designing J2EE Applications);
4) DWS-385 (Java Web Service);
5) DTJ-3109 (Developing Secure Web Applications).

Per lavorare con gli EJB usavo i seguenti Application Server:

1) Glassfish (della Oracle)
2) WebLogic (della Oracle)
3) WebSphere (dell'IBM)
4) JBoss (allora era un prodotto Open Source, oggi della Red Hat).

Gli EJB erano oggetti che potevano essere istanziati solo in un EJB Container di un Application Server, a differenza dei POJO (Plan Old Java Object - Oggetti Java Standard), che possono essere istanziati sia in una Java Virtual Machine, sia in un Web Container di un Web Server come Apache o di un Application Server qualsiasi, perchè questo servizio dispone sia di un Web Container, sia di un EJB Containar, come mostra l'immagine seguente:

PERCHE'  OGGI I POJO SONO MOLTO PIU' UTILIZZATI DEGLI EJB? 
Gli EJB permettono di fare in modo più professionale esattamente tutto quello che facciamo oggi con i POJO (Plan Old Java Object - Oggetti Java standard), utilizzando Hibernate e Spring. Il motivo per cui oggi quasi tutti i programmatori, per implementare la Dipendency Injection e l'ORM, usano oggetti POJO,  si spiega con il fatto che i framework  Hibernate e Spring sono più semplici da utilizzare e quindi richiedono un minore costo d'implementazione rispetto alle soluzioni di tipo EJB che invece risultano più complesse da utilizzare, ma probabilmente esiste anche un'altra spiegazione dovuta a un fattore storico che ho vissuto personalmente ...

Purtroppo, la versione EJB 2.0 della piattaforma Java EE, aveva diversi problemi, che creavano grosse difficoltà ai programmatori, quindi erano considerati non affidabili. Questo ha dato spazio a soluzioni alternative  come Hibernate prima e Spring dopo. Quando la Sun, con la versione EJB 3.5 ha risolto tutti i problemi, probabilmente non sono più riusciti a riconquistare la fiducia dei programmatori che ormai avevano iniziato ad usare le soluzioni alternative.

Questo grave errore della Sun ha permesso a Hibernate e Spring di diventare i leader di questa fascia di mercato.

LA RIVOLUZIONE DELLO SVILUPPO AGILE
Quando si è verificata la crisi dello sviluppo software, oltre al paradigma di sviluppo, cambiarono anche i modelli di sviluppo software che diventarono prima iterativi e successivamente iterativi incrementali. Allora collaboravo anche con l'IBM e altre società del gruppo come la Sistemi Informativi e la Selfin, per i clienti del gruppo ho fatto molti corsi di Rational Unified Process (RUP), uno dei primi modelli di sviluppo software iterativi.

Il RUP a differenza del Waterfall divideva il ciclo di vita del software in quattro transazioni: avvio (inception), elaborazione (elaboration), costruzione (construction) e transizione (transaction), ciascuna indicava il livello di maturità di un progetto di sviluppo software.  In base alla transazione, le fasi del modello a cascata venivano gestite in modo diverso, in base agli obiettivi da raggiungere. Ad esempio, per le transazioni iniziali (avvio/elaborazione), dove la conoscenza del progetto software era minore, si dedicava più tempo alle fasi di analisi e di progettazione, mentre per le transizioni finali (costruzione/transizione), dove l'applicazione cominciava a prendere forma, si dedicava più tempo alle fasi d'implementazione, testing e deployment.

L'immagine seguente mostra il RUP (Rational Unified Process):  

Comunque, l'evento più importante che cambiò radicalmente il modo di sviluppare le applicazioni software e da cui dipendono gli attuali modelli di sviluppo software, fu l'incontro del 2001 a Snowbird (Utah), tra i più grandi produttori di software del mondo. Alla fine di questo storico incontro, in diciassette, sottoscrissero il Manifesto Agile che conteneva i 4 valori e 12 principi guida da seguire per progettare e sviluppare applicazioni complesse in modo agile.

I quattro valori del Manifesto agile erano:

1. Individui e interazioni su processi e strumenti;
2. Software funzionante sulla documentazione completa;
3. Collaborazione con i clienti sulla negoziazione del contratto;
4. Rispondere al cambiamento anziché seguire un piano.

Per ricevere maggiori informazioni sul manifesto agile clicca qui.

Oggi il modello di sviluppo software che maggiormente si rifà ai valori e ai principi del Manifesto agile è il modello iterativo incrementale DevOps, riportato nell'immagine seguente:

La metodologia Agile più usata nelle aziende che fanno sviluppo software è SCRUM, un framework, inteso come insieme di regole, ruoli, eventi e artefatti, che permette di accelerare le attività di progettazione applicativa, migliorando contestualmente la qualità del software.

L'immagine seguente mostra gli elementi che compongono il framework SCRUM:

Conosco bene sia il modello di sviluppo software DevOps, sia la metodologia SCRUM,  perché sono corsi molto richiesti dalle aziende IT che devono aggiornare oppure riqualificare i propri dipendenti. Faccio anche molta consulenza per supportare le aziende IT che vogliono implementare il modello DevOps e applicare un project management di tipo Agile, svolgendo spesso il ruolo di SCRUM Master.

IL TRAMONTO DELLA SUN MICROSYSTEMS: LA FINE DI UNA GRANDE VISIONE AZIENDALE
Prima degli anni '80 i sistemi informatici erano di tipo mainframe, sistemi centralizzati, molto affidabili, con grosse capacità di elaborazione dati, utilizzati solo dalle grandi aziende; i principali produttori mondiali di mainframe erano l'IBM, l'HP e l'Olivetti.

Solo qualche anno più tardi arriveranno i minicomputer e i personal computer, accessibili a tutti e che attraverso le reti comunicavano tra loro, rendendo i sistemi non più centralizzati, ma distribuiti; fu così che inizio l'era della trasformazione digitale. 

Tra le aziende che hanno favorito il passaggio dai sistemi centralizzati verso i sistemi distribuiti,  la Sun Microsystems ha avuto un ruolo molto importante, dovuto soprattutto all'innovativa visione commerciale di questa grande azienda Californiana.

Lo slogan della SUN era "La rete è il computer", anticipando quello che poi diventerà Internet e il cloud. 

La Sun Microsystems nasce nel 1982 da un piccolo gruppo di compagni di classe dell'Università di Stanford in California: Vinod Khosla, Scott MacNealy, Bill Joy, Andy Bechtolsheim, Vaughan Pratt; la vision di quest'azienda rivoluzionerà completamente il mondo dell'informatica. 

Scott McNealy, uno dei co-fondatori della Sun, affermava: "Il mondo sta cambiando, sarà tutto in rete". È assurdo che conserviamo tutti i nostri dati su PC e laptop, dove possono essere persi troppo facilmente. Se affidi i tuoi soldi alla banca, perché non dovresti affidare i tuoi dati alla rete? Affidando i dati alla rete li potresti scaricare quando ti servono, così come prelevi soldi quando ne hai bisogno.

Inizialmente era un'azienda di nicchia che produceva workstation con sistema operativo Unix Sun Solaris, alla fine degli anni '80 è entrata nel mercato dei server multiutente e verso la meta degli anni '90 ha iniziato ad operare anche nel mercato emergente dei server web. 

La Sun, attraverso le sue scelte di mercato s'era riposizionata dal mercato delle workstation, considerato a crescita lenta, verso il mercato Internet a crescita elevata. I suoi server gestivano siti Web di alto profilo come AOL, Amazon.com ed e-bay.

Nel 1997, ogni giorno dagli stabilimenti Sun, venivano spediti ai clienti circa 100 server e 2.500 workstation. Il prezzo di un Server SUN oscillava dai 14.000 a un milione di dollari ($), mentre una workstation costava in media 15.000 dollari ($).

Alla fine del 1998, Sun era cresciuta fino a raggiungere quasi 26.300 dipendenti con circa 10 miliardi di dollari di ricavi. I ricavi erano suddivisi per il 52% negli Stati Uniti e per il 48% a livello mondiale. 

Sun rispetto ai suoi concorrenti offriva soluzioni hardware scalabili e affidabili per il funzionamento di Unix; era il principale concorrente di Microsoft. Insieme ad Apple, era l'unico fornitore a non installare Windows NT sui propri server o Windows sulle workstation.

I server e le workstation Sun non usavano processori Intel, ma avevano una propria architettura basata su processori SPARC RISC. Anche IBM, Compaq e Hewlett-Packard avevano sistemi operativi e architetture proprietarie, ma vendevano anche macchine basate sullo standard Wintel (Windows/Intel). 

Compaq, Dell e la maggior parte dei piccoli venditori operavano quasi completamente nel campo Wintel. 

I prodotti della Sun erano progettati per comunicare attraverso le reti e il protocollo TCP/IP, erano scalabili e affidabili, per questo motivo la Sun riuscì a soddisfare anche le esigenze delle grandi aziende, che si convertirono ai server basati su Unix su cui potevano girare applicazioni come SAP, PeopleSoft, Baan e Oracle.

Sun, oltre a progettare il proprio microprocessore SPARC, il proprio sistema operativo Unix Solaris, creò anche il linguaggio di programmazione Java, per sviluppare applicazioni a oggetti basate sul web. Tutte queste tecnologie pur essendo proprietarie erano considerate aperte, perché Sun pubblicava gli standard e i protocolli concedendoli in licenza per l'utilizzo ad altri.

Sun faceva molto affidamento su terze parti per i servizi di integrazione e il supporto, tra i partner software strategici di Sun cerano: Baan, BEA, Computer Associates, Informix, J.D. Edwards,Lotus, Netscape, Oracle, PeopleSoft, SAP, SAS Institute, Sybase, Tivoli e IBM.

Aveva anche forti rapporti con le principali società di consulenza, tra cui KPMG, Price Waterhouse, Andersen Consulting, EDS, MCI e Cambridge Technology Partner, Perot Systems, Ernst and Young, CSC, Cap Gemini e Deloitte ICS.

La più grande debolezza di Sun fu la sua focalizzazione sul mercato Unix; mentre altri fornitori iniziavano ad investire su Windows NT e Linux e sulla tecnologia Wintel, il CIO (chief information officer) della Sun, ovvero il  responsabile della gestione strategica dei sistemi informativi dichiarava: 

“La tecnologia Sun on Sun è un punto religioso... Gestiamo la nostra azienda da soli.

Sebbene Java proliferasse con una penetrazione dell'85% sui client, la concorrenza dei prodotti Microsoft e delle tecnologie Intel compatibili aumentò a tal punto che la Sun entrò in crisi.

Dopo una serie di voci sulla possibile acquisizione da parte di IBM e di Cisco, a gennaio del 2010, arrivò inaspettata la mossa di Oracle, che acquistò Sun Microsystems per un valore di 7,4 miliardi di dollari ($).

Con questa acquisizione la Oracle ottenne grossi vantaggi di mercato perché poteva disporre di un ottimo sistema operativo Unix, di un ottimo linguaggio di programmazione come Java e dalla disponibilità di tutto l'hardware prodotto dalla Sun.

Con l'acquisto di Sun, Oracle portò in casa anche MySQL, acquistato da Sun nel gennaio 2008.

Il resto lo conoscete perché è storia recente ...

LA BREVE ESPERIENZA DI FORMATORE IN ORACLE
In Sun, oltre a ricevere una grande crescita professionale come formatore, avevo avuto anche l'opportunità di diventare un programmatore molto esperto; tutto quello che insegnavo, lo sapevo anche applicare praticamente. Quindi oltre alla formazione ero capace di fare anche progettazione ed implementazione di applicazioni aziendali distribuite, multilivello.

La gratificazione maggiore che ho ricevuto durante la mia esperienza in Sun è stato l'invito in Scozia, ricevuto direttamente dalla Sun Microsystems al meeting degli Educational Center Sun di tutto il mondo. E' stata un'esperienza bellissima che mi ha ripagato di tutto lo studio e i sacrifici che avevo fatto per arrivare a quel livello.

Conservo ancora il badge che mi consegnarono per accedere all'evento:

Ho continuato a collaborare con la Sun fino al 2010, quando in modo inaspettato, arrivò la notizia improvvisa che la Oracle aveva acquistato la Sun Microsystems.