For Camtek, the DWH story began almost 20 years ago, with a customer's request to develop a file transmission interface for the operation AVL. The question then arose to create a custom data warehouse. The interface between softwares implies to set up a communicating model according to the specifications of the manufacturer/publisher. Indeed, subtleties can be important (for example, some people talk about "car", others prefer "service"). There are also different scopes of action. The idea is to create a pivot format for all the data: with a structuring for the input and the necessary parameters for the output flows. By taking all the data related to the transport offer, the DWH thus becomes the structured data base available to communicate with all the installed devices.

​

In 2000 (the first softwares for public transport date back to the mid-1990s), Camtek chose to start from a reference data model for public transport (Transmodel), to talk about Transport and not IT (we can say that it was a UX orientation). With this common document base with its customers, Camtek favors a relational database, open source, with a standardized model of input data for downstream distribution.

​

The input and output sources are multiple, diverse, and evolving. Plugins are developed for loading data from rising devices, with structuring in a pivot format. And, to consider the variety of sources (Hastus, Okapi, HubVeolia, Excel...), dedicated plugins ensure an upload in the standard DWH model. An update, an evolution, or a change of the source (for example, from Hastus to Okapi) will only require an update of the plugin, and thus a short development time, considering the application rules, behaviours, and specificities of the user client system. Thus, for the ticketing plugin, Camtek has identified 8 different behaviours, with an update required every quarter (on average). Upward compatibility is a determining factor. Indeed, each new Excel version requires reformatting all the macros, and the same goes for the leading softwares for public transport.

​

The output plugins have the task of creating data files to feed the devices, depending on the dialogue modalities and the environment. Updates are developed, for the same reasons as for the bottom-up plugins. Thus, when the DWH is implemented, all the data of the transport offer is integrated at our client's, the data is structured, qualified multi-sources and available for all the devices. The client knows and controls his data: quality, consistency, accessibility, and availability (no more re-entries). Security is ensured: the DWH is based on a client-server architecture, with a resource database called by a chain command under Windows. The Windows environment is favoured (again, a UX approach) to suit the standards of the transport sector.

​

Another advantage of the data available and structured in the DWH is the visualization. The data is directly operational, particularly for the processes required by the Marketing department (such as time sheets, pole time sheets, etc.), or for the operation office with service sheets, the generation of activity indicators and reporting. DWH is therefore a proven solution, with significant productivity gains. Performance + Quality + Agility = DWH.