KURTOGLU
SINAN

Contesto del progetto

Il lavoro è iniziato nel 1998 con l’obiettivo di sviluppare un’infrastruttura informativa condivisa e affidabile per i comuni di Eskişehir. L’ambito andava dalla revisione delle applicazioni comunali esistenti al collegamento tra registri amministrativi, informazioni geografiche, dati sul campo e infrastruttura necessaria a supportarli.

All’epoca l’attività comunale si basava in gran parte su applicazioni separate in COBOL fornite da SAMPAŞ. Queste applicazioni supportavano le rispettive funzioni, ma le loro strutture dati sottostanti creavano difficoltà quando i registri dovevano essere condivisi tra comuni e uffici.

La stessa persona poteva avere più numeri di registrazione, creati nel corso di molti anni da uffici, comuni o pratiche diversi. I registri duplicati di cittadini e contribuenti rendevano difficile stabilire relazioni affidabili tra persone, immobili, accertamenti e pratiche comunali.

Il lavoro si è svolto inoltre prima che l’abbinamento e la verifica basati sull’identità nazionale diventassero una prassi ordinaria nei sistemi informativi comunali. Stabilire un’identità coerente tra i registri esistenti ha quindi richiesto un’analisi e una riconciliazione approfondite.

Il punto di partenza è stato il rapporto tra identità, registri anagrafici, integrità dei dati e condivisione delle informazioni. Quel rapporto è diventato il fondamento del più ampio sistema informativo urbano.

1. Valutazione dei sistemi e dei dati esistenti

La prima fase ha riguardato l’esame delle applicazioni comunali esistenti, delle loro strutture dati e del modo in cui gli uffici le utilizzavano.

Prima di introdurre il software sostitutivo era necessario capire lo stato dei dati esistenti e individuare dove i sistemi generassero incoerenze.

I problemi principali comprendevano:

• Più registri per la stessa persona.
• Registri separati di cittadini e contribuenti tenuti da comuni diversi.
• Insiemi di dati specifici di ciascun ufficio, organizzati attorno a singole esigenze operative.
• Registri storici archiviati in formati incoerenti.
• Relazioni inaffidabili tra persone e registri degli immobili.
• Condivisione limitata delle informazioni tra istituzioni.
• Assenza di collegamenti diretti tra gli elementi fisici della città e i registri amministrativi.
• Assenza di un inventario aggiornato dell’intera città che potesse essere verificato rispetto alla situazione sul campo.

La valutazione ha stabilito che disporre di dati affidabili era un presupposto per il sistema nel suo complesso. I registri esistenti dovevano prima essere esaminati, riconciliati e resi adatti a un uso condiviso.

2. Un registro condiviso dei cittadini

Una parte centrale dell’approccio consisteva nell’identificare ogni persona attraverso un registro condiviso, dove possibile, anziché creare un ulteriore registro indipendente per ogni servizio comunale.

Il rapporto previsto era:

Persona → Registro condiviso → Pratiche comunali

Ottenerlo richiedeva più che assegnare un numero comune. La stessa persona poteva comparire con grafie diverse del nome, indirizzi diversi, dati incompleti, formati di registro storici o registri di uffici diversi.

Il lavoro comprendeva quindi:

• Revisione dei registri esistenti.
• Individuazione dei possibili duplicati.
• Abbinamento dei registri collegati tra i diversi sistemi.
• Salvaguardia dell’integrità delle pratiche associate.
• Sviluppo di un modello di dati comune.

Questo approccio a registro condiviso ha fornito una base per collegare i registri tra i servizi comunali ed è diventato una parte essenziale del sistema informativo urbano in sviluppo.

3. Definizione dei requisiti tecnici

Attuare l’approccio a registro condiviso richiedeva modifiche coordinate su tutta l’infrastruttura di supporto.

I requisiti riguardavano la capacità dei server, l’archiviazione, il backup, i sistemi client, l’infrastruttura di rete, la comunicazione tra istituzioni, la migrazione dei dati, l’organizzazione degli utenti e il personale tecnico.

Sono state predisposte e presentate alla direzione valutazioni su hardware, infrastruttura di rete, personale e capacità tecnica necessari.

Man mano che questi requisiti si chiarivano, il lavoro si è sviluppato in un progetto di infrastruttura informativa comunale, con più livelli tecnici e operativi interdipendenti.

4. Rilievi sul campo in tutta la città e inventario di residenti e immobili

I soli registri informatici esistenti non potevano fornire un quadro sufficientemente affidabile della città. Occorreva verificarli rispetto a edifici, unità immobiliari, indirizzi e all’effettiva occupazione o utilizzo.

È stato pianificato un rilievo sul campo in tutta la città per raccogliere direttamente queste informazioni.

Ispirandomi ai moduli ottici utilizzati all’epoca nell’istruzione superiore e negli esami centralizzati, ho proposto un approccio basato su moduli ottici per supportare la digitalizzazione efficiente di grandi volumi di dati del rilievo.

Dopo le necessarie approvazioni amministrative e le delibere del consiglio comunale, i moduli sono stati predisposti e stampati presso la tipografia di Anadolu University.

Le squadre sul campo hanno raccolto le informazioni con un rilievo di tipo censuario, registrando:

• Edifici.
• Unità immobiliari all’interno degli edifici.
• Indirizzi.
• Residenti e modalità di utilizzo.

Il rilievo si è ampliato fino a diventare un ampio inventario di residenti e immobili dell’intera città. Ha offerto una fonte di informazioni raccolte sul campo rispetto alla quale valutare e aggiornare i registri comunali esistenti.

5. Crescita dei volumi di dati e infrastruttura server

Con l’espandersi dell’inventario sul campo, il volume dei dati è aumentato rapidamente.

I sistemi dovevano inoltre supportare la conservazione dei registri storici, l’aggiunta delle informazioni raccolte di recente, l’accesso condiviso tra comuni e l’introduzione di ulteriori applicazioni comunali.

Queste esigenze combinate hanno messo sotto crescente pressione la capacità di server e archiviazione. Sono stati installati e configurati nuovi sistemi server per far fronte al carico di lavoro in crescita.

L’esigenza andava oltre la capacità di elaborazione. I comuni e le istituzioni, situati in sedi fisiche distinte, avevano bisogno di un accesso affidabile e ad alta velocità alle risorse informative condivise.

L’architettura si è quindi sviluppata attorno a una sequenza connessa:

Raccolta dei dati sul campo → Risorse dati condivise → Infrastruttura server → Connettività interistituzionale

Supportare sistemi situati in sedi distinte rendeva sempre più necessaria una connettività in fibra ad alta velocità.

All’epoca non descrivevamo l’architettura in sviluppo con termini come stretched cluster, estensione della SAN o infrastruttura distribuita di server e storage. Tuttavia il lavoro si stava già muovendo in quella direzione: estendere le risorse server e dati su sedi fisiche distinte e collegarle tramite un backbone in fibra condiviso e ad alta velocità.

L’esigenza pratica era chiara: i sistemi di sedi diverse dovevano funzionare insieme, con accesso affidabile a risorse dati comuni.

6. Conservazione e migrazione dei dati legacy

Conservare i dati accumulati in anni di attività comunale era un requisito centrale della transizione.

Le applicazioni esistenti SAMPAŞ, basate su COBOL, contenevano registri che dovevano restare disponibili e utilizzabili mentre il comune passava alle soluzioni fornite da İztek A.Ş.

Il lavoro di migrazione comprendeva:

• Esame delle strutture dati esistenti.
• Confronto tra i modelli di dati legacy e sostitutivo.
• Pulizia dei registri.
• Revisione dei duplicati.
• Rivalutazione dei rapporti tra le persone e i registri anagrafici.
• Trasformazione dei dati nei formati richiesti.
• Migrazione dei dati.
• Verifica dell’integrità dei registri trasferiti.

L’obiettivo era ottenere dati che potessero essere abbinati, messi in relazione e utilizzati nelle nuove applicazioni comunali, conservandone il valore storico.

7. Dati condivisi e applicazioni aziendali

L’ambiente sostitutivo ha introdotto database DB2 e applicazioni aziendali basate su Java.

Ciò supportava l’uso previsto di risorse dati sottostanti comuni tra gli uffici comunali.

Il modello di lavoro era:

Dati condivisi → Applicazioni aziendali → Uffici comunali → Servizi comunali

L’informazione è diventata sempre più una risorsa istituzionale condivisa, con relazioni in grado di supportare diversi processi comunali.

8. Pianificazione dell’infrastruttura in fibra durante la costruzione dell’ESTRAM

All’inizio del 2002 le strade lungo i tracciati dell’ESTRAM erano state chiuse e i principali lavori civili erano in corso.

In quella fase i rilievi sul campo si erano intensificati, i volumi di dati erano cresciuti, erano stati installati nuovi sistemi server e la necessità di una comunicazione ad alta velocità tra le istituzioni era diventata evidente.

Gli scavi in corso offrivano l’occasione di predisporre i percorsi in fibra mentre le strade erano già aperte. Ciò avrebbe soddisfatto le future esigenze di comunicazione senza dover ricorrere a un nuovo scavo lungo gli stessi tracciati.

Le esigenze del sistema informativo urbano e delle comunicazioni comunali sono state quindi considerate durante i lavori civili.

I lavori di predisposizione comprendevano:

• Cavidotti per cavi in fibra.
• Attraversamenti di tracciato.
• Pozzetti di accesso interrati.
• Punti di connessione.
• Armadi tecnici da campo fuori terra in punti selezionati.

Questi lavori hanno creato percorsi fisici in grado di supportare la rete in sviluppo e di consentirne la successiva espansione.

9. Il backbone in fibra intercomunale

I percorsi predisposti hanno permesso di collegare con tratte in fibra i comuni e le istituzioni situati in sedi diverse.

Il mio lavoro diretto ha riguardato sia il backbone sia l’infrastruttura locale necessaria per collegarvi server e utenti:

• Installazione dei cavi in fibra.
• Giunzione a fusione.
• Terminazione della fibra.
• Test dei collegamenti.
• Convertitori di mezzo trasmissivo.
• Switch e hub Nortel.
• Distribuzione della rete locale basata su NetWare.
• Cablaggio di rete in rame.
• Canalizzazione dei cavi.
• Reti interne agli edifici.
• Collegamenti dei server.
• Collegamenti dei client.

Questa infrastruttura ha fornito i collegamenti di comunicazione necessari perché istituzioni geograficamente distanti accedessero a sistemi informativi condivisi.

Il backbone in fibra collegava i livelli di server, dati, applicazioni e utenti del sistema informativo urbano in sviluppo.

10. Infrastruttura in fibra per le comunicazioni e la segnalazione dell’ESTRAM

Anche l’ESTRAM aveva bisogno di connettività in fibra per i propri sistemi di comunicazione operativa e di segnalazione.

I percorsi fisici e i cavidotti predisposti durante i lavori civili potevano soddisfare questa esigenza. Sono stati installati cavi in fibra distinti per l’ESTRAM, e le fibre interessate sono state poste sotto l’uso e il controllo dell’ESTRAM stessa.

Il corridoio fisico condiviso supportava quindi due esigenze distinte:

• Le comunicazioni dati comunali per il sistema informativo urbano.
• Le comunicazioni operative e la segnalazione dell’ESTRAM.

I sistemi beneficiavano della stessa infrastruttura civile, mentre la responsabilità dell’uso e della gestione delle rispettive fibre restava distinta.

Ciò rientrava in un approccio coordinato alla pianificazione dell’infrastruttura urbana per più sistemi di esercizio.

11. Sistema informativo gestionale

Con lo sviluppo dell’infrastruttura di server, dati e comunicazioni, il lavoro si è esteso ai processi operativi degli uffici comunali.

Abbiamo esaminato le informazioni e le regole di business associate a cittadini, contribuenti, immobili, accertamenti, riscossioni, pratiche, date, aliquote e normativa.

Una sfida importante era che le regole di business comunali cambiavano nel tempo. Le modifiche a leggi, regolamenti e avvisi ufficiali potevano incidere su aliquote, metodi di calcolo, date di efficacia e trattamento di determinati periodi.

Le applicazioni dovevano quindi tenere conto della regola applicabile alla data di ciascuna pratica.

Sono stati esaminati migliaia di casi possibili in relazione a:

• Intervalli di date di efficacia.
• Variazioni delle aliquote.
• Modifiche normative.
• Tipi di pratica.

Tradurre questi requisiti in comportamento del software è stata una parte sostanziale del lavoro sul MIS.

12. Sistema informativo geografico

La fase principale successiva ha riguardato il collegamento delle informazioni amministrative comunali con la città fisica.

Il lavoro sul GIS basato su NetCad si è concentrato sulla creazione di relazioni tra gli elementi cartografati e i corrispondenti registri comunali.

La catena informativa prevista era:

Città → Isolato e particella catastali → Edificio → Unità immobiliare → Registro → Cittadino o contribuente → Pratiche comunali

Un risultato pratico è stata la possibilità di selezionare sulla mappa un’unità immobiliare o un elemento geografico correlato e accedere alle relative informazioni del MIS.

Ciò ha fornito un collegamento diretto tra informazione spaziale e amministrazione comunale.

13. Integrazione MIS/GIS

MIS e GIS sono stati trattati come livelli informativi complementari che descrivono la stessa città.

Il MIS conteneva persone, contribuenti, pratiche, accertamenti e processi amministrativi. Il GIS rappresentava località, particelle, edifici, unità immobiliari e altri elementi fisici.

Il lavoro di integrazione ha creato relazioni tra questi livelli, in modo che da un immobile cartografato si potesse risalire ai relativi registri, alle persone e alle pratiche comunali.

Ciò ha permesso agli utenti di esaminare la città fisica e le sue informazioni amministrative all’interno di un ambiente informativo connesso.

Il rapporto che andava delineandosi era:

Ubicazione geografica → Particella → Edificio → Unità immobiliare → Registro → Cittadino o contribuente → Pratiche comunali

14. Lavori preliminari per l’integrazione con il registro fondiario e il catasto

Con lo sviluppo delle relazioni MIS/GIS, i registri ufficiali di proprietà e catastali sono diventati un ulteriore ambito di indagine.

Era necessario mettere in relazione le informazioni comunali su persone, immobili, particelle, edifici e unità immobiliari con i corrispondenti registri ufficiali.

Sono stati avviati confronti con le istituzioni competenti per valutare le possibilità di integrazione dei dati. Contatti preliminari hanno riguardato anche la condivisione delle informazioni nell’ambito delle rispettive competenze istituzionali.

È rimasto un lavoro preparatorio. Ha esplorato come il sistema informativo urbano potesse collegarsi alle informazioni detenute da altre istituzioni pubbliche.

15. Un approccio a sistemi integrati

L’ambito richiedeva che più livelli tecnici e operativi funzionassero insieme:

• Infrastruttura elettrica e fisica.
• Cablaggio e fibra ottica.
• Apparati di rete.
• Server, storage e backup.
• Database e applicazioni aziendali.
• Sistemi legacy e migrazione dei dati.
• MIS e GIS.
• Dati del rilievo sul campo.
• Normativa e regole di business comunali.
• Flussi di lavoro degli utenti.

Il progetto si è sviluppato attorno ai rapporti tra questi livelli:

Infrastruttura fisica → Comunicazioni → Server e dati → Applicazioni aziendali → MIS/GIS → Servizi comunali

Le scelte di installazione, le strutture dati, i requisiti applicativi e i processi degli uffici si influenzavano a vicenda. Coordinarli è stata una parte centrale del lavoro.

16. Il mio ruolo e i miei contributi diretti

Le mie responsabilità abbracciavano diverse discipline e sono cambiate con lo sviluppo del progetto.

Nell’ambito dell’analisi dei sistemi e dei dati, il mio lavoro ha compreso:

• Valutazione delle applicazioni esistenti e dei problemi sui dati.
• Sviluppo dell’approccio a registro condiviso.
• Definizione dei requisiti tecnici.
• Relazione sulle esigenze di hardware e personale.
• Sviluppo del modello di rilievo sul campo e del metodo a moduli ottici.
• Supporto all’inventario dell’intera città.
• Revisione dei sistemi legacy.
• Pulizia e riconciliazione dei registri.
• Esecuzione della migrazione dei dati.

Nell’ambito dell’infrastruttura e delle comunicazioni, il mio lavoro ha compreso:

• Installazione e configurazione dei sistemi server.
• Configurazione di server e client.
• Definizione degli assetti di rete.
• Pianificazione dei percorsi in fibra.
• Lavori su cavidotti, pozzetti di accesso e armadi tecnici da campo.
• Installazione, giunzione, terminazione e test della fibra.
• Lavoro con apparati Nortel, convertitori di mezzo trasmissivo, switch e hub.
• Supporto all’infrastruttura NetWare.
• Installazione del cablaggio in rame e delle reti interne agli edifici.

Nell’ambito delle applicazioni e dell’integrazione, il mio lavoro ha compreso:

• Lavoro con l’ambiente dati DB2 e con applicazioni aziendali basate su Java.
• Supporto allo sviluppo del MIS.
• Lavoro con applicazioni GIS e NetCad.
• Creazione di relazioni tra i dati MIS e GIS.
• Traduzione della normativa e delle regole di business comunali in requisiti software.
• Partecipazione ai lavori preliminari di integrazione con il registro fondiario e il catasto.
• Test dei sistemi e supporto alla messa in servizio sul campo.

È stato uno dei più estesi incarichi di integrazione di sistemi della mia carriera, che ha riunito hardware, reti, comunicazioni, dati, applicazioni aziendali e informazioni geografiche nello stesso ambiente comunale.

Sviluppo nel periodo 1998–2004

Il lavoro si è sviluppato attraverso una serie di fasi collegate:

1. 1998 — Valutazione iniziale: esame delle applicazioni comunali, dei dati legacy, dei registri duplicati e dei problemi di integrità dei dati.
2. Registro condiviso e inventario sul campo: sviluppo dell’approccio a registro comune e raccolta, tramite moduli ottici, di informazioni su edifici, unità, indirizzi, residenti e utilizzi.
3. Espansione di dati e server: installazione di capacità server a supporto dei volumi di dati crescenti, della migrazione dei dati legacy e dell’ambiente applicativo DB2/Java.
4. 2002 — Lavori civili dell’ESTRAM: predisposizione di cavidotti, pozzetti di accesso, attraversamenti di tracciato e armadi tecnici da campo per l’infrastruttura in fibra.
5. Integrazione di comunicazioni e applicazioni: sviluppo del backbone intercomunale, del MIS, del GIS basato su NetCad e delle relazioni tra registri amministrativi e geografici.
6. Pianificazione di ulteriori integrazioni: lavori preliminari sui collegamenti con le informazioni del registro fondiario e del catasto.
7. 2004 — Fine del mio periodo sul progetto: conclusione del mio coinvolgimento in questa fase del lavoro.

Da applicazioni separate a un’infrastruttura informativa urbana connessa

L’ambiente di partenza era costituito da applicazioni comunali separate, insiemi di dati frammentati, registri duplicati, scarsa condivisione delle informazioni e registri amministrativi con pochi collegamenti diretti con la città fisica.

Il lavoro ha introdotto un approccio a registro condiviso, dati di inventario raccolti sul campo, registri ripuliti e migrati, maggiore capacità server, connettività in fibra e relazioni tra MIS e GIS.

Il risultato previsto era un ambiente informativo in cui località, immobili, persone e pratiche comunali potessero essere comprese attraverso le loro relazioni, supportato da dati condivisi e da un’infrastruttura di comunicazione.

Rilevanza tecnica

La rilevanza del lavoro svolto tra il 1998 e il 2004 sta nei metodi e nelle infrastrutture sviluppati in quel periodo.

In un periodo in cui l’abbinamento basato sull’identità nazionale e i servizi digitali interistituzionali erano meno consolidati, il lavoro ha affrontato diversi requisiti che restano centrali per i sistemi informativi urbani:

• Riconciliazione dei registri dei cittadini con un approccio a registro condiviso.
• Produzione di informazioni su residenti e immobili basate sul rilievo sul campo.
• Conservazione dei registri legacy durante la migrazione.
• Creazione di risorse dati istituzionali condivise.
• Aumento della capacità server per far fronte a carichi di lavoro crescenti.
• Collegamento di comuni e istituzioni tramite fibra.
• Pianificazione dei percorsi fisici in vista delle future esigenze di comunicazione.
• Collegamento dei registri amministrativi comunali agli elementi geografici.
• Esplorazione di un’ulteriore condivisione di informazioni tra istituzioni pubbliche.

Queste attività hanno dato vita a un’iniziativa precoce di sistema informativo urbano a Eskişehir, in cui dati, server, comunicazioni, applicazioni, informazioni geografiche e infrastruttura sul campo sono stati sviluppati come parti di uno stesso sistema.

2004 — Fine del mio coinvolgimento

Il mio coinvolgimento nel progetto è terminato nel 2004, dopo sei anni di lavoro che hanno abbracciato dati comunali, infrastruttura fisica, comunicazioni, applicazioni aziendali e informazioni geografiche.

L’esperienza ha costruito una base pratica per lavorare trasversalmente su dati comunali, infrastruttura fisica della città, sistemi aziendali e informazioni geografiche. Ha inoltre rafforzato la mia capacità di valutare un sistema istituzionale complesso attraverso le relazioni tra i suoi componenti tecnici e i servizi che doveva supportare.