Bis dat, qui cito datDelivered promptly,delivered twice
Case Studies
Selected Case Studies
The Case Studies below present selected projects from my many years of professional and technical work. They were chosen because they provide sufficient functional and technical depth to show the problem, the solution and the value of custom software development clearly. They are not a complete project catalogue. Where reliable public documentation exists, links to independent external sources are included.
Case Study 1
CDB200Q — THE CORPORATE DATABASE
Enterprise Distribution, Sales & Marketing Support Platform
Client: JTI HellasSector: Distribution networks and field operationsFocus: Market & Distribution Network Management · Field Execution · Sales Data · Workflow · Reporting · Data IntegrationPeriod: 1994–2026Type: Long-lived custom enterprise platform
AT A GLANCE
NEED
Integrate market structure and the distribution network with market breakdown, profiling and segmentation, product and merchandising information, promotion-activity planning and field-execution tracking, agreements and contracts workflow, sales-data collection, targets and reporting.
SOLUTION
A central enterprise platform that modelled the market as a shared information environment, linking geography, vendors and distribution relationships, products, territories and personnel, visits and actions, and sales and targets data.
VALUE
A long-lived enterprise system developed from the ground up in 1994 and evolved in production through 2026, allowing the same business information to support market analysis, field execution, Sales & Marketing support and management reporting.
THE CHALLENGE
In an extensive distribution network, a true picture of the market cannot be derived from a single data set. It requires the geographical and commercial structure of the market to be related to manufacturers, importers, distributors, wholesalers and retailers, products, territories and the people responsible for them, field activities and actual sales data.
The requirement, therefore, was not simply for a CRM or a sales database. It was for a unified operational environment capable of representing the market accurately and connecting Sales, Marketing, Distribution and Field Operations through the same coherent data set.
When I took on the project in 1994, experience already existed from an earlier Corporate Database. CDB200Q, however, was developed from the ground up as a new system, using that business knowledge while redesigning the data model, applications and overall functional architecture.
THE SOLUTION
CDB200Q, ‘The Corporate Database’, evolved into a central enterprise platform for managing commercial presence, the distribution network and field operations.
At its core was a unified relational model connecting different but interdependent areas of the business operation:
The significance of this model was that the same business entities were not duplicated across independent application ‘islands’. Vendors, geographic areas, products, territories, personnel, visits, activities and sales transactions represented different views of the same market and could be related to one another.
DATA-STRUCTURE DIAGRAM
The diagram below presents the main areas of the data model and their relationships in a modern visual form.
Overview of the CDB200Q data model.
MARKET BREAKDOWN AND DISTRIBUTION NETWORK
CDB200Q represented both the geographical and the commercial structure of the market.
The distribution network could include manufacturers, importers, distributors, major outlets, wholesalers and retailers, organised at different levels and by vendor type. It also maintained supplied areas, supply relationships, profiles and profile history, together with marketing possibilities for different points in the market.
An outlet or other market entity was therefore more than a customer record. It could be viewed simultaneously as part of a specific geographic area, a member of a distribution relationship, a commercial profile and a target for specific sales or marketing activities.
ORGANISATION, TERRITORIES AND FIELD RESPONSIBILITY
The organisational structure was directly connected to the market structure.
Company departments and personnel were linked to districts and territories, while territories corresponded to geographic areas and market entities. This made it possible to represent who was responsible for each part of the market, which points belonged to each territory and which activities were planned or executed there.
The geographical, commercial and organisational dimensions were not independent classifications. They were connected within the same operational model.
PRODUCTS & MERCHANDISING
Products were not treated as simple codes.
The product model included brands, styles, pack types, attributes, attribute values and change history, together with merchandising-related information.
This allowed the same market, sales and field-activity information to be analysed not only by vendor or area, but also by different product dimensions and commercial characteristics.
FIELD OPERATIONS, VISITS & ACTIONS
Field work was an integral part of the same information model.
Each visit could be linked to a specific field user, vendor, products, visit actions, action types and remarks. Retailer profiles and actual field activity were therefore not separate applications.
Promotions and other field activities could be planned centrally, assigned to the appropriate users and territories, executed in the field and monitored centrally.
As the mobile applications evolved, first through HHTs and later through laptops and other offline clients, field users could keep the required subset of central information locally, work without continuous connectivity and synchronise results with the central system.
SALES DATA, TARGETS AND DISTRIBUTION FLOWS
CDB200Q collected and related sales and distribution information from different sources.
The sales model linked source and target vendors, products, geography, transaction types and time periods. It supported sales statistics, distributor and wholesaler sales, targets, and the import of data from external sources.
Sales data was therefore not simply a reporting data set. It was connected to the real structure of the distribution network, the products and the market areas.
FROM DATA TO INFORMATION
A core objective of the system was to turn large volumes of operational data into useful business information.
CDB200Q included configurable reporting and ad-hoc analysis mechanisms, allowing different market dimensions to be combined dynamically. Geography, vendors, products, territories, periods, activities and sales could all serve as shared dimensions of analysis.
The central data model therefore served both as an operational environment and as a foundation for management information.
AGREEMENTS, CONTRACTS AND WORKFLOW
As the system evolved, agreements, contracts, obligations, approvals, follow-ups and related workflows were incorporated into the same information environment.
Linking them to the existing market entities, territories, personnel and activities meant that commercial agreements were not treated as isolated administrative documents, but as part of the company's overall relationship with the market.
INTEGRATION WITH THE WIDER CORPORATE ENVIRONMENT
During its long production life, CDB200Q integrated with ERP, BI and other corporate systems, supporting imports, exports, data feeds, migrations, reconciliation and data cleansing.
The architectural principle remained that a custom enterprise system should not operate in isolation. It should work with the wider information environment while retaining the domain-specific functionality that gives it its purpose.
CONTINUOUS EVOLUTION AND CONTROLLED MODERNISATION
CDB200Q was developed from the ground up in 1994, building on business experience gained from previous systems, and continued to be developed and supported in production through 2026.
Over those decades, the market, organisational requirements, field processes, technology platforms and the wider corporate IT environment all changed.
The system followed these changes through functional extensions, migrations, integrations and controlled modernisation, without losing the business knowledge embedded in the software.
This longevity is not simply a historical detail. It reflects a different technical requirement from the initial delivery of a project: long-term software ownership, continuous development, production support and the safe evolution of a mission-critical enterprise system.
WHY IT MATTERS
CDB200Q was not simply a CRM, sales database, field application or reporting system.
Its core architectural idea was that the market could be modelled as a shared set of connected business entities:
Sales, Marketing, Distribution, Field Operations and Management Reporting could all operate on top of this shared model, using the same information from different business perspectives.
Its long production life also shows that the value of an enterprise application lies not only in its initial design and development, but in its ability to adapt, integrate and evolve as the organisation it supports changes.
Case Study 2
ICMANAGER
Imports Cycle, Supply Planning & Excise Management System
Unified management of a complex import cycle in which forecasting, orders, shipments, bonded stock, taxation and cash flow are interdependent.
SOLUTION
A specialised ERP companion that modelled the entire chain from supply planning through excise management and future cash requirements.
VALUE
An example of deep domain modelling for processes that a generic ERP usually covers only in fragments.
THE CHALLENGE
Managing imports in an environment with a special tax regime is not simply a matter of orders and warehouse management. Every factory order affects future shipments and imports. Imports affect bonded stock; releasing that stock creates tax liabilities; those liabilities are linked to letters of guarantee and ultimately translate into specific future cash requirements.
The challenge, therefore, was to treat this entire cycle as one business model rather than as a series of disconnected spreadsheets or modules.
THE SOLUTION
ICManager was designed as a specialised ERP companion for the full import cycle. Its core connected three areas that are often handled separately:
Orders & Import Planning
Forecasting, order placement, factory shipments, partial fulfilments, cancellations and over-fulfilments, balances and closing.
Excise & Taxation Management
Calculation and forecasting of excise duties, management of tax stamps (banderoles) and linkage to letters of guarantee.
Bonded & Free Stock Management
Parallel monitoring of bonded and tax-paid/free stock, with actual, planned and forecast movements.
FROM FORECASTING TO FUTURE CASH REQUIREMENTS
One of ICManager's strongest features was that it did not stop at recording what had already happened. The system could create 12-month import plans using available sales and stock data, factory and shipping parameters and warehouse constraints.
Finance and Supply could therefore see not only the current position, but also the financial consequences of future decisions.
SPECIALISED DOMAIN MODELLING
The taxation layer was particularly demanding. ICManager tracked the quantities and cost of tax stamps, their relationship to orders and imports, and the lifecycle of letters of guarantee. Changes in imports, bonded stock and tax liabilities were not treated as independent events, but as interrelated changes within the same operational model.
DESIGNED AROUND EXCEPTIONS
In real life, orders are not always fulfilled as planned. The system had to handle partial shipments, cancellations, over-fulfilments, different working calendars, changes to arrival dates, returns, stock adjustments, losses and damages, and changes to operational parameters.
The value of the forecasting model lay precisely in its ability to be revised as the real import cycle evolved, rather than remaining an isolated planning spreadsheet.
INTEGRATION, NOT ERP REPLACEMENT
ICManager was not designed to replace the existing ERP. It covered specialised processes that a generic ERP has difficulty modelling in depth and could draw operational data from other corporate systems.
That pattern remains relevant today: custom software alongside an ERP when critical business knowledge sits in processes that do not fit well into a standard package.
WHY IT MATTERS
ICManager is a clear example of domain-specific enterprise software. Its strength lies not in a single function, but in integrating the chain:
It shows how a complex, regulated and interdependent business process can be translated into a coherent software model.
FUNCTIONAL-CYCLE DIAGRAM
The diagram below summarises key stages of the import cycle, from order planning and order placement through bonded/free stock, banderoles and letters of guarantee.
Wholesaler Integration & Daily Sales Data Collection Platform
Client: Athanassiou S.A.Sector: Distribution networks and Data IntegrationFocus: Data Acquisition · ETL · Master Data · Validation · Network IntegrationDevelopment: 2007Type: Custom Data Integration platform
AT A GLANCE
NEED
Daily collection of reliable sales, returns and stock data from a wholesaler network using different systems, formats and coding schemes.
SOLUTION
A configurable data hub for acquisition, mapping, validation, exception handling, normalisation, centralised storage and secure redistribution of data.
VALUE
A clear example of integrating heterogeneous data sources without requiring replacement of the local information systems.
THE CHALLENGE
The objective was the systematic daily collection of sales, returns and stock data from an extensive wholesaler network. The challenge was that the network did not operate on a shared information infrastructure.
Each wholesaler could use a different commercial application or warehouse system, different product codes, export formats, encodings and layouts. The solution could not require replacement of the local systems or rely on manual consolidation of files.
THE SOLUTION
A configurable Distribution Network Data Hub was developed to receive, process, validate and normalise incoming data, store it centrally and route it onwards.
The core principle was:
The wholesaler does not adapt to the system. The system adapts to each wholesaler.
The processing architecture can be described as:
Wholesaler Systems → Data Reception → Format Recognition → Staging → Product Mapping → Validation → Exception Handling → Normalisation → Central Storage → Distribution.
CONFIGURABLE DATA RECEPTION
A separate processing profile could be maintained for each wholesaler, containing information about format, encoding, parsing rules, product mappings and expected submissions.
This allowed one central application to onboard different network members progressively without requiring a common ERP or a common local IT system.
MASTER DATA AND PRODUCT MAPPING
A critical element was the central product catalogue and the mappings for each wholesaler. Local product codes were converted to common central codes, while new or unknown codes could remain pending until the mapping was resolved.
Mapping was treated as an ongoing operational process rather than a one-off conversion.
DATA QUALITY AND EXCEPTION MANAGEMENT
The real engineering challenge was not simply to get files into the system. It was to know which data could be trusted.
The system detected and managed:
unknown product codes,
changes to source formats,
missing submissions or periods,
invalid or inconsistent records,
processing failures,
records requiring manual review.
Problematic data could remain in a controlled pending state rather than causing the entire submission to be lost. The system also supported reprocessing and completeness monitoring by wholesaler and date.
ONE NORMALISED MODEL, MULTIPLE DISTRIBUTION PATHS
After validation, the data was stored in a common normalised model. From there, different subsets and formats could be produced and routed automatically to the appropriate business recipients.
The model therefore changed from:
many independent files + manual consolidation
to:
Independent wholesalers → Common Data Acquisition Layer → Normalised central data → Business recipients.
SECURE WEB DATA EXCHANGE
The architecture included a secure Web layer for electronic data submission, organised storage of incoming files, sender identification, feedback and secure delivery of processed data sets.
It is not presented as a complete wider partner portal. The documented and material element of this Case Study is the Web-enabled data exchange that supported the Data Hub.
WHY IT MATTERS
The project combined:
heterogeneous data ingestion · configurable ETL · master-data mapping · data-quality control · exception workflows · centralised storage · secure data exchange · automated redistribution.
Based on the available historical evidence, it represents an early production-scale example of automated daily sales-data collection from a heterogeneous distribution network.
Its value today as a reference lies in showing how a common data layer can be built over a fragmented ecosystem of legacy and commercial systems without requiring their replacement.
Case Study 4
IAEN / DIGILIB
Digital Library & Full-Text Information Retrieval System
Organisation: Historical Archive of Greek Youth / Institute for Neohellenic Research, National Hellenic Research FoundationSector: Digital Culture and ResearchFocus: Digitised Content Processing · Digital Library · Full-Text Search · Information RetrievalDelivery: Web & CD-ROMDevelopment: 2003Initial digital material: 34 books, approximately 18,500 pages
AT A GLANCE
NEED
Turn a large collection of digitised historical publications into genuinely searchable and usable research material.
SOLUTION
A Digital Library / Information Retrieval environment combining searchable text and full-text retrieval with the original digitised page, for both Web and CD-ROM delivery.
VALUE
34 books and approximately 18,500 pages were published as a unified digital corpus, combining access to content with preservation of the original source.
THE CHALLENGE
The Historical Archive of Greek Youth (IAEN), a research and publishing programme of the General Secretariat for Youth hosted at the National Hellenic Research Foundation and funded by the General Secretariat for Youth, had over many years built an important corpus of scholarly publications on the history of childhood and youth. The next step was not simply to scan the pages, but to turn them into a genuinely useful digital research resource.
A collection of scanned pages preserves the image of the books, but on its own does not provide effective scholarly access. A database, searchable text, indexing and an application layer were needed to connect search results back to the original page.
THE SOLUTION
DigiLib was developed for the project as a custom Digital Library / Information Retrieval environment for the Web and CD-ROM. The work included adapting the digitisation data, creating the database and developing the search and presentation applications.
The initial digital edition contained 34 books and approximately 18,500 pages.
FROM DIGITISATION TO DIGITAL LIBRARY
The system was organised around two parallel representations of the material:
Searchable-text layer
For full-text searching and locating relevant passages.
Original-edition layer
For direct return to the actual digitised page of the book.
The logic was:
Digitised Books → Structured Text → Search Index → Search Results → Original Page.
This was particularly important for historical and humanities material, where the original page, typography and publication context form part of the source itself.
SEARCH AS A RESEARCH TOOL
Access was not limited to browsing from book to book. Researchers could formulate queries, locate relevant text across the entire corpus and move directly to the corresponding source.
The public IAEN presentation describes the digitised corpus as suitable both for straightforward use and for ‘complex search queries’.
ONE CONTENT BASE, TWO DELIVERY CHANNELS
The same corpus was made available both on the Web and as a standalone CD-ROM. This required the search and presentation logic to work across different delivery environments while sharing the same information base.
PRESERVING THE SOURCE, ENHANCING ACCESS
DigiLib balanced two goals:
faithful preservation of the original edition,
new retrieval capabilities that did not exist in the printed medium.
The digital page preserved the source. Searchable text and indexing added a new layer of access. Users could move between structured/searchable information and the original document.
WHY IT MATTERS
DigiLib is an early and clear example of the chain:
Digitised Material → Content Processing → Searchable Corpus → Information Retrieval → Digital Publication.
It connects software development, Digital Humanities and information retrieval, and shows how a historical corpus can be transformed into a digital research environment without losing its connection to the original source.
PUBLIC REFERENCES
National Hellenic Research Foundation / IAEN, public presentation of the CD-ROM, 34 books and 18,500 pages:
EMNE/Mnimon: Bibliography of the History of Modern Hellenism, 1973–1982
Organisation: Society for the Study of Modern Hellenism / Mnimon journalSector: Digital Humanities and BibliographyFocus: Bibliographic Database · Information Retrieval · Digital PublishingDevelopment: 2007Bibliographic corpus: approximately 12,500 books and articles
AT A GLANCE
NEED
Turn a curated scholarly bibliography of approximately 12,500 books and articles into a standalone digital research tool.
SOLUTION
A bibliographic database and search/navigation application with multiple criteria and different bibliographic views, delivered as a standalone CD-ROM edition.
VALUE
An example of digital publishing in which structured scholarly information becomes an accessible information-retrieval environment without losing its bibliographic structure.
THE CHALLENGE
The Society for the Study of Modern Hellenism had, over a number of years, compiled the ‘Bibliography of the History of Modern Hellenism 1973–1982’, a large, curated scholarly corpus of approximately 12,500 books and articles.
The objective was to turn this bibliographic work into a standalone digital research tool that historians and researchers could use without specialised cataloguing software.
THE SOLUTION
A bibliographic database and standalone search/navigation application were developed for CD-ROM. The application transformed the curated scholarly bibliographic data set into an accessible information-retrieval environment.
The chain was:
Curated Bibliographic Data → Data Processing → Structured Database → Search & Retrieval Layer → Digital Publication.
MULTIPLE WAYS TO ACCESS THE BIBLIOGRAPHY
The application supported both index-based navigation and searching with selected criteria and logical combinations.
Searchable elements included:
statement of responsibility,
title,
publisher,
year of publication,
place of publication,
series,
subject,
journal of publication,
record provenance,
words in the content.
The bibliography therefore functioned as an information-retrieval system for research use rather than as a static electronic list.
DIFFERENT VIEWS FOR DIFFERENT USERS
Results could be presented as:
a column/index view for rapid overview,
an ISBD view for a readable bibliographic format,
a UNIMARC view for the detailed structured record.
The same corpus could therefore serve both historians/researchers and users with bibliographic or library expertise.
A STANDALONE DIGITAL RESEARCH EDITION
The final digital product combined the database, the search/navigation application and user instructions on a standalone CD-ROM, allowing it to be reproduced and distributed as a complete scholarly publication.
PUBLICLY DOCUMENTED DEVELOPMENT CONTRIBUTION
Mnimon has a rare advantage as a Case Study: the development contribution is documented not only in professional records.
A public publication of the National Hellenic Research Foundation explicitly states:
‘Application development and IT support: Avgerinos Markopoulos’.
The public EMNE record also confirms the title, the year 2007, approximately 12,500 entries, and the sponsors: the Ministry of Culture and the Stavros S. Niarchos Foundation.
WHY IT MATTERS
Unlike IAEN, where the emphasis is on full-text retrieval across digitised books, Mnimon focuses on structured scholarly information:
It is a clear Digital Humanities example in which a large, curated scholarly data set is transformed into an accessible research tool without losing its bibliographic accuracy and structure.
PUBLIC REFERENCES
National Hellenic Research Foundation, named reference to the development contribution:
Organisation: Ionian UniversitySector: Academic Libraries and Knowledge SystemsFocus: Digital Libraries · Thematic Portals · Information IntegrationDevelopment: 2005–2007Programme: ‘Upgrade and modernisation of the Ionian University library system’ / EPEAEK
AT A GLANCE
NEED
Integrate library services, electronic resources, thematically organised content and user services within a common academic environment.
SOLUTION
A Web-based information environment with Thematic Portals, content publishing, search, authentication and integrations, together with a separate Student Portal.
VALUE
An example of knowledge integration in which librarians, academic services and distributed information resources were connected through a unified access environment.
THE CHALLENGE
The Ionian University Library operated a range of electronic services and resources: OPAC, electronic subscriptions, reference services, information resources, academic content and e-learning systems.
The problem was that users had to know where each piece of information was located and which service to use. The goal of the Ionian University Portal (IUP) was to create a unified information environment bringing together library services and organising selected electronic resources into Thematic Portals.
THE SOLUTION
IUP was designed not simply as the Library's website, but as a Web-based integration and knowledge-access platform.
It combined:
Content Management → Thematic Portals → Library Services → Search → User Authentication → External Information Sources.
The application was based on an open-source Web/CMS architecture and adapted to the University's requirements. It included content publishing, thematic sections, news and announcements, forums, access to library services and mechanisms for different categories of users.
THEMATIC PORTALS
A central feature was the Thematic Portals. Librarians could select, evaluate, classify and publish electronic resources by subject area, so users did not have to search the Web indiscriminately.
The logic was:
Open Web Resources → Librarian Selection & Evaluation → Subject Classification → Thematic Portal → Academic User.
In this way, the Library acted as an active curator of digital information rather than simply a catalogue of physical material.
AUTHENTICATION AND PERSONALISED ACCESS
IUP supported different categories of users, including students, teaching and research staff, librarians, administrators and visitors, with different access rights.
The evolving architecture included LDAP integration and the goal of a unified authentication/SSO model with other university services. The approach was to maintain, as far as possible, a unified user directory and common access model across an otherwise heterogeneous application environment.
SEARCH ACROSS DISTRIBUTED INFORMATION
A later step was the creation of a more unified search environment, allowing users to search content across different areas of the Portal and, where technically feasible, include results from external digital-library sources.
The planned evolution included integrations with bibliographic and digital-library platforms, so that IUP could operate more as a common information space than as a collection of links to separate systems.
A SEPARATE STUDENT PORTAL
Alongside the library-oriented IUP, a separate Student Portal was developed in PHP-Nuke. It was not simply an authenticated section of IUP, but a separate application focused on the organised online delivery of university information and services to the student community.
OPEN-SOURCE PLATFORM, CUSTOM FUNCTIONALITY
The project is a good example of using an open-source platform as a practical foundation, with custom development where genuine differentiation was required: roles, thematic structures, content organisation, authentication, search and integrations.
The approach can be summarised as:
Use the platform where it fits; develop custom functionality where differentiation is required.
PROGRAMME AND PRODUCTION CONTEXT
IUP was developed within the wider project ‘Upgrade and modernisation of the Ionian University library system’, funded through the Greek Ministry of Education / EPEAEK programme.
Public documentation shows that the Thematic Portals had already been implemented and presented in scholarly work in 2005, that an extension of their software functionality was tendered in 2006, and that IUP remained in real use at least until 2012.
WHY IT MATTERS
IUP demonstrates a different form of integration from the enterprise projects. Here the challenge was not commercial transactions, but the integration of distributed knowledge resources and user services.
Together with IAEN and Mnimon, IUP forms a strong body of experience in Digital Libraries, Digital Humanities, academic information systems and knowledge access.
PUBLIC REFERENCES
E-LIS, ‘IUP: presentation of the Ionian University Library thematic portals’, 2005:
