KURTOGLU
SINAN

Project Background

The work began in 1998 with the aim of developing a shared, reliable information infrastructure for Eskişehir’s municipalities. The scope extended from reviewing existing municipal applications to connecting administrative records, geographic information, field data, and the infrastructure needed to support them.

At the time, municipal operations relied largely on separate COBOL-based applications supplied by SAMPAŞ. These applications supported their respective functions, but their underlying data structures presented difficulties when records needed to be shared across municipalities and departments.

The same person could have several registration numbers, created by different departments, municipalities, or transactions over many years. Duplicate citizen and taxpayer records made it difficult to establish dependable relationships between people, properties, assessments, and municipal transactions.

The work also took place before national identity-based matching and verification had become a routine part of municipal information systems. Establishing a consistent identity across existing records therefore required substantial analysis and reconciliation.

The starting point was the relationship between identity, registration records, data integrity, and information sharing. That relationship became the foundation for the wider City Information System.

1. Assessment of Existing Systems and Data

The first stage involved examining the existing municipal applications, their data structures, and the way departments used them.

Before introducing replacement software, we needed to understand the condition of the existing data and identify where the systems were creating inconsistencies.

The main issues included:

• Multiple registration records for the same person.
• Separate citizen and taxpayer records maintained by different municipalities.
• Department-specific datasets organized around individual operational requirements.
• Historical records stored in inconsistent formats.
• Unreliable relationships between people and property records.
• Limited information sharing between institutions.
• A lack of direct links between physical features of the city and administrative records.
• The absence of a current citywide inventory that could be checked against conditions in the field.

The assessment established that reliable data was a prerequisite for the wider system. Existing records first had to be examined, reconciled, and made suitable for shared use.

2. A Shared Citizen Register

A central part of the approach was to identify each person through a shared registration record wherever possible, rather than creating another independent record for each municipal service.

The intended relationship was:

Person → Shared Registration Record → Municipal Transactions

Achieving this required more than assigning a common number. The same person could appear under different name spellings, addresses, incomplete details, historical record formats, or departmental records.

The work therefore involved:

• Reviewing existing records.
• Identifying potential duplicates.
• Matching related records across systems.
• Preserving the integrity of associated transactions.
• Developing a common data model.

This shared-register approach provided a basis for connecting records across municipal services and became an essential part of the developing City Information System.

3. Defining the Technical Requirements

Implementing the shared-register approach required coordinated changes across the supporting infrastructure.

The requirements covered server capacity, storage, backup, client systems, network infrastructure, communication between institutions, data migration, user organization, and technical staffing.

Assessments of the required hardware, network infrastructure, staffing, and technical capacity were prepared and submitted to management.

As these requirements became clearer, the work developed into a municipal information infrastructure project, with several interdependent technical and operational layers.

4. Citywide Field Surveys and the Resident and Property Inventory

Existing computer records alone could not provide a sufficiently reliable picture of the city. They needed to be checked against buildings, individual units, addresses, and actual occupancy or use.

A citywide field survey was planned to collect this information directly.

Drawing on the optical forms used in higher education and centralized examinations at the time, I proposed an optical-form approach to support the efficient digitization of large volumes of survey data.

Following the necessary administrative approvals and municipal council decisions, the forms were prepared and printed at Anadolu University’s printing facility.

Field teams collected information through a census-style survey, recording:

• Buildings.
• Individual units within buildings.
• Addresses.
• Residents and patterns of use.

The survey expanded into a substantial citywide resident and property inventory. It introduced a source of field-based information against which existing municipal records could be assessed and updated.

5. Growing Data Volumes and Server Infrastructure

As the field inventory expanded, the volume of data increased rapidly.

The systems also had to support the retention of historical records, the addition of newly collected information, shared access between municipalities, and the introduction of further municipal applications.

These combined demands placed increasing pressure on server and storage capacity. New server systems were installed and configured to accommodate the growing workload.

The requirement extended beyond processing capacity. Municipalities and institutions at separate physical locations needed dependable, high-speed access to shared information resources.

The architecture consequently developed around a connected sequence:

Field Data Collection → Shared Data Resources → Server Infrastructure → Interinstitutional Connectivity

Supporting systems across separate locations made high-speed fiber connectivity increasingly necessary.

At the time, we did not describe the developing architecture in terms such as stretched clusters, SAN extension, or distributed server and storage infrastructure. However, the work was already moving in that direction: extending server and data resources across separate physical locations and connecting them through a shared, high-speed fiber backbone.

The practical requirement was clear: systems at different sites needed to operate together, with reliable access to common data resources.

6. Legacy Data Preservation and Migration

Preserving the data accumulated through years of municipal operations was a central requirement of the transition.

The existing SAMPAŞ and COBOL-based applications contained records that needed to remain available and usable as the municipality moved to solutions supplied by İztek A.Ş.

The migration work included:

• Examining existing data structures.
• Comparing the legacy and replacement data models.
• Cleaning records.
• Reviewing duplicates.
• Reassessing the relationships between people and registration records.
• Transforming data into the required formats.
• Migrating the data.
• Checking the integrity of the transferred records.

The objective was to produce data that could be matched, related, and used across the new municipal applications while preserving its historical value.

7. Shared Data and Enterprise Applications

The replacement environment introduced DB2 databases and Java-based enterprise applications.

This supported the intended use of common underlying data resources across municipal departments.

The working model was:

Shared Data → Enterprise Applications → Municipal Departments → Municipal Services

Information increasingly became a shared institutional resource, with relationships that could support several municipal processes.

8. Planning Fiber Infrastructure During ESTRAM Construction

By early 2002, roads along the ESTRAM routes had been closed and major civil construction was underway.

By that stage, the field surveys had intensified, data volumes had grown, new server systems had been installed, and the need for high-speed communication between institutions had become clear.

The ongoing excavation provided an opportunity to prepare fiber routes while the roads were already open. This would support future communications requirements without relying on another round of excavation along the same routes.

The City Information System and municipal communications requirements were therefore considered during the civil works.

Preparations included:

• Fiber cable ducts.
• Route crossings.
• Underground access chambers.
• Connection points.
• Above-ground field cabinets at selected locations.

These works established physical routes that could support the developing network and allow subsequent expansion.

9. The Intermunicipal Fiber Backbone

The prepared routes enabled municipalities and institutions at different locations to be connected through fiber links.

My direct work covered both the backbone and the local infrastructure required to connect servers and users to it:

• Fiber cable installation.
• Fusion splicing.
• Fiber termination.
• Link testing.
• Media converters.
• Nortel switches and hubs.
• NetWare-based local network distribution.
• Copper network cabling.
• Cable containment.
• Internal building networks.
• Server connections.
• Client connections.

This infrastructure provided the communications links needed for geographically separate institutions to access shared information systems.

The fiber backbone connected the server, data, application, and user layers of the developing City Information System.

10. Fiber Infrastructure for ESTRAM Communications and Signaling

ESTRAM also required fiber connectivity for its operational communications and signaling systems.

The physical routes and ducts prepared during the civil works could accommodate this requirement. Separate fiber cables were installed for ESTRAM, and the relevant fibers were placed under ESTRAM’s own use and control.

The shared physical corridor therefore supported two distinct requirements:

• Municipal data communications for the City Information System.
• ESTRAM operational communications and signaling.

The systems benefited from the same civil infrastructure, while responsibility for the use and management of their fibers remained separate.

This formed part of a coordinated approach to planning city infrastructure for several operational systems.

11. Management Information System

As the server, data, and communications infrastructure developed, the work extended into the operational processes of municipal departments.

We examined the information and business rules associated with citizens, taxpayers, properties, assessments, collections, transactions, dates, rates, and legislation.

A significant challenge was that municipal business rules changed over time. Amendments to laws, regulations, and official notices could affect rates, calculation methods, effective dates, and the treatment of particular periods.

The applications therefore needed to account for the rule applicable at the date of a transaction.

Thousands of possible cases were examined in relation to:

• Effective date ranges.
• Rate changes.
• Legislative changes.
• Transaction types.

Translating these requirements into software behavior was a substantial part of the MIS work.

12. Geographic Information System

The next major stage involved linking municipal administrative information to the physical city.

The NetCad-based GIS work focused on establishing relationships between mapped features and the corresponding municipal records.

The intended information chain was:

City → Cadastral Block and Parcel → Building → Individual Unit → Registration Record → Citizen or Taxpayer → Municipal Transactions

One practical result was the ability to select an individual unit or a related geographic feature on the map and access its associated MIS information.

This provided a direct connection between spatial information and municipal administration.

13. MIS/GIS Integration

MIS and GIS were treated as complementary information layers describing the same city.

The MIS contained people, taxpayers, transactions, assessments, and administrative processes. The GIS represented locations, parcels, buildings, individual units, and other physical features.

The integration work established relationships between these layers so that a mapped property could lead to the relevant registration, person, and municipal transaction records.

This enabled users to examine the physical city and its administrative information within a connected information environment.

The developing relationship was:

Geographic Location → Parcel → Building → Individual Unit → Registration Record → Citizen or Taxpayer → Municipal Transactions

14. Preliminary Work on Land Registry and Cadastre Integration

As the MIS/GIS relationships developed, official ownership and cadastral records became a further area for investigation.

There was a need to relate municipal information about people, properties, parcels, buildings, and individual units to the corresponding official records.

Discussions were held with the relevant institutions to assess data integration possibilities. Preliminary discussions also addressed information sharing within the applicable institutional responsibilities.

This remained preparatory work. It explored how the City Information System could connect with information held by other public institutions.

15. An Integrated Systems Approach

The scope required several technical and operational layers to work together:

• Electrical and physical infrastructure.
• Cabling and fiber optics.
• Network equipment.
• Servers, storage, and backup.
• Databases and enterprise applications.
• Legacy systems and data migration.
• MIS and GIS.
• Field survey data.
• Legislation and municipal business rules.
• User workflows.

The project developed around the relationships between these layers:

Physical Infrastructure → Communications → Servers and Data → Enterprise Applications → MIS/GIS → Municipal Services

Installation decisions, data structures, application requirements, and departmental processes all influenced one another. Coordinating them was a central part of the work.

16. My Role and Direct Contributions

My responsibilities covered several disciplines and changed as the project developed.

In systems and data analysis, my work included:

• Assessing existing applications and data problems.
• Developing the shared-register approach.
• Defining technical requirements.
• Reporting hardware and staffing needs.
• Developing the field survey model and optical-form method.
• Supporting the citywide inventory.
• Reviewing legacy systems.
• Cleaning and reconciling records.
• Carrying out data migration.

In infrastructure and communications, my work included:

• Installing and configuring server systems.
• Configuring servers and clients.
• Developing network arrangements.
• Planning fiber routes.
• Working on cable ducts, access chambers, and field cabinets.
• Installing, splicing, terminating, and testing fiber.
• Working with Nortel equipment, media converters, switches, and hubs.
• Supporting NetWare infrastructure.
• Installing copper cabling and internal building networks.

In applications and integration, my work included:

• Working with the DB2 data environment and Java-based enterprise applications.
• Supporting MIS development.
• Working with GIS and NetCad applications.
• Establishing relationships between MIS and GIS data.
• Translating legislation and municipal business rules into software requirements.
• Participating in preliminary Land Registry and Cadastre integration work.
• Testing systems and supporting commissioning in the field.

This was one of the most extensive systems integration assignments in my career, bringing hardware, networks, communications, data, enterprise applications, and geographic information into the same municipal environment.

Development Across 1998–2004

The work developed through a series of connected stages:

1. 1998 — Initial assessment: Examination of municipal applications, legacy data, duplicate registration records, and data integrity problems.
2. Shared registration and field inventory: Development of the common-register approach and collection of building, unit, address, resident, and usage information through optical forms.
3. Data and server expansion: Installation of server capacity to support increasing data volumes, legacy data migration, and the DB2/Java application environment.
4. 2002 — ESTRAM civil works: Preparation of ducts, access chambers, route crossings, and field cabinets for the fiber infrastructure.
5. Communications and application integration: Development of the intermunicipal backbone, MIS, NetCad-based GIS, and relationships between administrative and geographic records.
6. Further integration planning: Preliminary work on links to Land Registry and Cadastre information.
7. 2004 — End of my project period: Conclusion of my involvement in this phase of the work.

From Separate Applications to a Connected City Information Infrastructure

The starting environment consisted of separate municipal applications, fragmented datasets, duplicate registration records, limited information sharing, and administrative records with few direct links to the physical city.

The work introduced a shared-register approach, field-based inventory data, cleaned and migrated records, expanded server capacity, fiber connectivity, and relationships between MIS and GIS.

The intended result was an information environment in which locations, properties, people, and municipal transactions could be understood through their relationships, supported by shared data and communications infrastructure.

Technical Significance

The significance of the 1998–2004 work lies in the methods and infrastructure developed during the period.

At a time when national identity-based matching and interinstitutional digital services were less established, the work addressed several requirements that remain central to city information systems:

• Reconciling citizen records through a shared-register approach.
• Producing field-based resident and property information.
• Preserving legacy records during migration.
• Establishing shared institutional data resources.
• Increasing server capacity to accommodate growing workloads.
• Connecting municipalities and institutions through fiber.
• Planning physical routes with future communications needs in mind.
• Relating municipal administrative records to geographic features.
• Exploring further information sharing between public institutions.

These activities formed an early City Information System initiative in Eskişehir, with data, servers, communications, applications, geographic information, and field infrastructure developed as parts of the same system.

2004 — End of My Involvement

My involvement in the project ended in 2004, after six years of work spanning municipal data, physical infrastructure, communications, enterprise applications, and geographic information.

The experience established a practical foundation for working across municipal data, physical city infrastructure, enterprise systems, and geographic information. It also strengthened my ability to evaluate a complex institutional system through the relationships between its technical components and the services it needed to support.