Development of Corridor Performance
Benchmarking Dashboards
SJ Rabe
orcid.org/0000-0002-0229-2663
Dissertation submitted in fulfilment of the requirements for the
degree Master of Engineering in Computer and Electronic
Engineering at the North-West University
Supervisor:
Prof AJ Hoffman
Examination November 2018
Student number: 22820302
TABLE OF CONTENTS
1 INTRODUCTION ... 1 1.1 Chapter Overview ... 1 1.2 Background ... 1 1.2.1 Key Fundamentals ... 1 1.2.2 Current Problems ... 4 1.2.3 Potential Causes ... 4 1.3 Research Proposal ... 6 1.3.1 Problem Statement ... 6 1.3.2 Research Scope ... 6 1.4 Research Objectives... 7 1.4.1 Primary Objectives ... 7 1.4.2 Secondary Objectives ... 7 1.5 Research Motivation ... 7 1.6 Research Methodology ... 7 1.7 Beneficiaries of Research ... 8 1.8 Dissertation Layout ... 9 1.9 Chapter Summary ... 10 2 LITERATURE STUDY ... 11 2.1 Chapter Overview ... 112.2 Overview of Trade Corridors ... 11
2.4 Key Trade Corridor Players and Requirements ... 13
2.4.1 Cargo Owners ... 13
2.4.2 Clearing and Forwarding Agents ... 14
2.4.3 Shipping Lines ... 15 2.4.4 Ports ... 16 2.4.5 Border Posts ... 16 2.4.6 Inland Transportation ... 17 2.4.7 Public sector ... 19 2.4.8 General public ... 20 2.4.9 Future Considerations ... 21
2.5 Data Analysis Techniques ... 21
2.5.1 Operational Flow Graphs ... 22
2.5.2 Relating data to operations ... 22
2.5.3 Measurement calculation ... 23
2.5.4 Measurement presentation ... 25
2.6 Trends and Events in Technology... 25
2.6.1 Cloud Computing Adoption ... 25
2.6.2 Open Source ... 26
2.6.3 Big Data and IoT ... 26
2.6.4 RFID ... 27
2.6.5 The Digital Divide ... 28
2.7 Corridor Performance Benchmarking Dashboard Requirements ... 29
2.9 Cloud Providers ... 31
2.9.1 Potential Cloud Providers ... 31
2.9.2 Services Comparison ... 32
2.9.3 Regional Availability ... 33
2.9.4 Cost Comparison ... 34
2.9.5 Conclusion ... 34
2.10 Development Languages and Tools ... 35
2.10.1 Potential Solutions ... 35 2.10.2 Comparisons ... 35 2.10.3 Conclusion ... 39 2.11 Data Storage ... 40 2.11.1 Possible solutions ... 40 2.11.2 Cost Comparison ... 41 2.11.3 Technical Comparisons ... 41 2.11.4 Conclusion ... 42 2.12 Communication ... 43 2.12.1 Possible solutions ... 43 2.12.2 Conclusion ... 44 2.13 Infrastructure ... 45
2.14 Commercial Business Intelligence Software ... 49
2.14.1 Possible Solutions... 49
2.14.2 Feature Comparison ... 49
2.14.5 Possible Solutions... 56
2.14.6 Conclusion ... 56
2.15 Map Provider Services ... 57
2.15.1 Possible Solutions... 57 2.15.2 Conclusion ... 57 2.16 PDF Rendering Libraries ... 58 2.16.1 Possible Solutions... 58 2.16.2 Conclusion ... 59 2.17 Future Considerations ... 60
2.17.1 IoT and RFID Integrations ... 60
2.18 Chapter Summary ... 62
3 CORRIDOR PERFORMANCE DASHBOARD IMPLEMENTATION ... 63
3.1 Design Approach ... 63
3.1.1 Domain-Driven Design ... 63
3.1.2 Detailed Domain Model ... 65
3.2 Design and Implementation ... 69
3.2.1 Overview ... 69 3.2.2 Design Advantages ... 69 3.2.3 Design Disadvantages ... 70 3.2.4 Alternatives ... 70 3.2.5 Data API ... 71 3.2.5.1 Overview ... 71
3.2.5.3 Application Hosting Solution ... 72
3.2.5.4 Business Logic ... 73
3.2.5.5 Public Interfaces ... 76
3.2.6 Web Application ... 82
3.2.6.1 Project Template ... 82
3.2.6.2 Dashboard Design Overview ... 85
3.2.6.3 Application Framework ... 85
3.2.6.4 Component Based Design. ... 86
3.2.6.5 Stateful Components ... 88
3.2.6.6 Component Approach Drawbacks ... 88
3.2.6.7 State Containers ... 89
3.2.6.8 Project Layout... 89
3.2.6.9 User Interface ... 91
3.2.6.10 Visualisation Support ... 92
3.2.6.11 Interactive GIS Map Support ... 94
3.2.6.12 PDF Rendering Support ... 96
3.2.6.13 Software Features ... 98
3.2.7 Authentication and Authorization ... 100
3.2.7.1 Encrypted Communication ... 100
3.2.8 Testing ... 104
3.2.8.1 Testing Frameworks ... 104
3.2.8.2 Testing Demonstration ... 104
3.2.9 Operations and Maintenance ... 106
3.3 Chapter Summary ... 108
4 CORRIDOR PERFORMANCE DASHBOARD EVALUATION ... 109
4.1 Overview ... 109 4.2 Reliability ... 109 4.2.1 Fault Detection ... 109 4.2.2 110 4.2.3 Fault Recovery ... 110 4.2.4 Fault Prevention ... 110 4.3 Security ... 111 4.3.1 Threat Detection ... 111 4.3.2 Threat Resistance ... 112 4.3.3 Threat Reaction ... 112 4.4 Modifiability ... 113 4.4.1 Modular Design ... 113 4.4.2 Uniform Implementation ... 114 4.4.3 Reduced Coupling ... 115 4.5 Portability ... 116 4.5.1 Cross-platform Design ... 116
4.5.2 Responsive User Interface ... 117
4.6 Functionality ... 117
4.6.1 Visualisation ... 117
4.7 Variability ... 118 4.7.1 Cloud Configuration ... 119 4.7.2 Software Configuration ... 119 4.8 Subsetability ... 120 4.8.1 Component Independence ... 120 4.8.2 Service independence ... 121 4.9 Conceptual Integrity ... 121 4.9.1 Open Standards ... 122
4.10 Overall User Experience ... 122
4.10.1 Single Page Application ... 122
4.10.2 Minimalistic Design ... 124 4.10.3 Usage Context ... 124 4.11 Performance ... 125 4.11.1 Load Testing ... 125 4.11.2 Resource Scaling ... 127 4.12 Chapter Summary ... 127
5 CONCLUSIONS AND RECOMMENDATIONS ... 129
5.1 Development Concerns of a Performance Benchmarking Dashboard ... 129
5.1.1 Data Availability ... 129
5.1.2 Data Quality ... 129
5.1.3 Clear Responsibilities ... 130
5.1.4 Iterative Development ... 130
5.2.1 Domain-Driven Design ... 130
5.2.2 Task Responsibility ... 131
5.3 Cloud Infrastructure Benefits ... 131
5.3.1 Reduced Cost ... 131
5.3.2 Automation ... 131
5.3.3 Open-Source ... 132
5.4 Future Work ... 132
BIBLIOGRAPHY ... 133
ANNEXURE A: OPEN-SOURCE TOOLS AND TECHNOLOGIES ... 144
LIST OF TABLES
Table 2-1: Global Public Cloud Provider Market Share, 2017-2018 (Millions USD) ... 31
Table 2-2: Top 10 most popular database engines in November 2019 ... 40
Table 2-3: Cost comparison of potential database solutions ... 41
Table 2-4: Technical comparison of potential database solutions ... 42
Table 2-5: Chart features of notable business intelligence products ... 50
Table 2-6: GIS features of notable business intelligence products ... 50
Table 2-7: Access and reporting features of notable business intelligence products ... 52
Table 2-8: Cost comparison of notable business intelligence products ... 53
Table 2-9: Annual cost of notable business intelligence products ... 55
LIST OF FIGURES
Figure 2-1: Geographical map of Dar es Salaam Corridor. ... 12
Figure 2-2: Flow diagram illustrating a simplified vertical supply chain. ... 22
Figure 2-3: Flow diagram illustrating the relationship between data and operations. ... 23
Figure 2-4: Flow diagram illustrating the relationship between data and measurements. ... 24
Figure 2-5: Screenshot illustrating a service comparison of the top cloud providers ... 32
Figure 2-6: Screenshot of the October 2018 TIOBE Index ... 35
Figure 2-7: Screenshot of the October 2018 PYPL Index ... 36
Figure 2-8: Screenshot of most used languages according to Stack Overflow Survey ... 37
Figure 2-9: Screenshot of most used web frameworks according to Stack Overflow Survey ... 38
Figure 2-10: Screenshot of most used frameworks according to Stack Overflow Survey ... 38
Figure 2-11: Linux Foundation survey respondents using Node.js in some capacity. ... 39
Figure 2-12: Screenshot of a GraphQL query and result. ... 44
Figure 2-13: Screenshot of the Compute Engine dashboard. ... 46
Figure 2-14: Screenshot illustrating an app.yaml file. ... 47
Figure 2-15: Screenshot illustrating a dispatch.yaml file. ... 47
Figure 2-16: Screenshot of the Google App Engine URL specification. ... 48
Figure 2-17: Example of a Leaflet map from the website. ... 58
Figure 2-18: Screenshot of PDF render example from the pdfmake website ... 60
Figure 2-19: Photo of a Picollo GPS tracking system with RFID temperature sensors ... 61
Figure 3-1: Simplified Diagram of the Domain Model ... 64
Figure 3-3: Diagram showing the main components within the data API. ... 71
Figure 3-4: Screenshot of a routing example in the express documentation. ... 73
Figure 3-5: Diagram illustrating the purpose of ORM software. ... 73
Figure 3-6: Screenshot of a Sequelize object definition. ... 75
Figure 3-7: Screenshot of the database table created by Sequelize. ... 76
Figure 3-8: Screenshot of the swagger editing tool ... 77
Figure 3-9: Screenshot of swagger endpoint implementation in Node.js server. ... 78
Figure 3-10: Screenshot of the GraphiQL tool interface with an example query ... 80
Figure 3-11: Screenshot of the web application project structure ... 82
Figure 3-12: Screenshot of the template browser in Visual Studio ... 84
Figure 3-13: Diagram showing the main components of the web application ... 85
Figure 3-14: Screenshot of a ReactJS component ... 86
Figure 3-15: Diagram illustrating complex nesting. ... 87
Figure 3-16: Diagram illustrating the application component structure ... 89
Figure 3-17: Screenshot of an example GraphQL query file. ... 90
Figure 3-18: Screenshot showing an example where Axios was used. ... 91
Figure 3-19: Screenshot from Semantic UI React documentation of button colours. ... 92
Figure 3-20: Screenshot of a placeholder bar chart definition. ... 92
Figure 3-21: Screenshot of visualisations in web application. ... 93
Figure 3-22: Screenshot of customised visualisations in web application. ... 93
Figure 3-23: Screenshot of a saved chart opened in Windows 10. ... 94
Figure 3-26: Screenshot of PDF report rendering page in web application. ... 96
Figure 3-27: Screenshot of PDF document with an embedded chart. ... 97
Figure 3-28: Screenshot of PDF document in Adobe Acrobat Reader DC. ... 97
Figure 3-29: Screenshot of the performance dashboard home page ... 99
Figure 3-30: Screenshot of web application Profile page showing notifications. ... 100
Figure 3-31: Screenshot showing the use of HTTPS in the performance dashboard ... 101
Figure 3-32: Screenshot of vulnerability test results from pentest-tools.com ... 101
Figure 3-33: Screenshot of Google Cloud Platform security scan results. ... 102
Figure 3-34: Screenshot of web application cookies. ... 103
Figure 3-35: Screenshot of test results in the command line terminal. ... 105
Figure 3-36: Screenshot of code coverage report generated by jest. ... 106
Figure 3-37: Screenshot from the Cloud SQL database management page. ... 107
Figure 3-38: Screenshot from Gmail of an automated notification. ... 107
Figure 4-1: Screenshot of monitoring tools in a cloud environment. ... 109
Figure 4-2: Screenshot showing traffic splitting in the cloud environment. ... 110
Figure 4-3: Screenshot showing error logs in the cloud environment. ... 111
Figure 4-4: Screenshot showing error notifications in the cloud environment. ... 113
Figure 4-5: Screenshot showing results after running a lint script. ... 114
Figure 4-6: Screenshot showing an example of reduced coupling. ... 115
Figure 4-7: Screenshot of the performance dashboard in a mobile aspect ratio. ... 116
Figure 4-8: Screenshot of the data API aap.yaml file ... 118
Figure 4-11: Screenshot of an English language file in the web application. ... 122
Figure 4-12: Screenshot of the performance dashboard and auditing tool. ... 123
Figure 4-13: Screenshot of the performance dashboard for a limited user. ... 124
Figure 4-14: Screenshot from Loadium results for the web application. ... 125
Figure 4-15: Screenshot of the GCP dashboard during the load test. ... 126
Figure 5-1: Screenshot of the performance dashboard in Opera. ... 157
Figure 5-2: Screenshot of the performance dashboard in Google Chrome. ... 157
Figure 5-3: Screenshot of the performance dashboard in Mozilla Firefox. ... 158
Figure 5-4: Screenshot of the performance dashboard in Microsoft Edge. ... 158
Figure 5-5: Screenshot of the performance dashboard in Apple Safari. ... 159
1 INTRODUCTION
1.1 Chapter Overview
Trade corridors can be defined as a culture of trade agreements and treaties, statutes, delegated legislation and customs that govern and guide trading relationships [1]. Trade corridors are in essence a large group of entities that work together to transport and deliver goods across a large geographical area which can involve multiple countries and companies in the process.
Small logistics operations are mostly understood well and can be managed efficiently. As operations grow to the size of trade corridors, understanding and management of the entire corridor can become daunting very quickly. In this chapter, the goal is to define the motivations behind the development of corridor performance benchmarking dashboards.
1.2 Background
To create a system that can effectively aid people in managing a logistics operation the fundamental components of logistics needs to be understood. Logistics deals with the management of the flow of goods or materials from the point of production to the point of consumption and in some cases even to the point of disposal. Logistics is, in itself, a system. It is a network of related activities with the goal of managing the orderly flow of material and personnel within logistics channels [2].
1.2.1 Key Fundamentals
The two factors that determine if a company prospers are customer satisfaction and growth [3]. Essentially this means that companies should keep their customers satisfied and aim to grow at a reasonable pace.
In this research, the focus is primarily on customer satisfaction and eliminating overhead costs since these aspects are heavily influenced by the logistics operations of a company. By improving each of the components of customer satisfaction, the cost of logistics operations can be reduced. The concept of customer satisfaction can be summarised in 8 components:
Product: The majority of products need to be packaged properly for efficient transportation as well as inventory and warehousing. Ensuring that products are delivered in a way that facilitates customers to use it easily is a key factor in customer satisfaction.
Logistics: Choosing the correct transportation channels and diminishing distances between production and consumption in one of the largest factors to consider and can result in significant cost-savings regarding local and global transportation.
Quantity: The right quantity involves balancing the amount of inventory held with the cost of holding that inventory including capital tied up in inventory, variable storage costs and obsolescence. A lack of inventory would lead to lower customer satisfaction, whereas too much inventory could lead to unnecessary storage expenses.
Quality: Product quality is one of the largest factors when it comes to customer satisfaction since it is often used to compare similar products. Despite the importance of quality, it is frequently sacrificed to compensate for problems that can occur such as delays, defects, degeneration or downfalls.
Location: Customers are willing to pay more for a product that is located close to them than travelling to pay less. This behaviour especially takes place when customers want to save time and transportation cost. Configuring an optimal distribution network to position products as close to as possible to customers is a key component of customer satisfaction.
Time: Ensuring a product is available on the market at the right time is important to increase sales. If a product is sold when there is no need for it, there is no spending power or the product cannot be used due to seasonal reasons the attempt to generate sales will fail.
Customer: Customer desires and behaviours are dynamic and product sales need to be able to adapt. Instantaneous data analysis is important to understanding and forecasting demand-oscillations and intensive collaboration with suppliers can aid their preparations to alleviate potential shortages or overproduction.
Cost: It has never been easier to acquire high-quality products inexpensively than now since products are offered globally. If products are equal or identical, the deciding factor is typically cost. Lowering cost has a direct impact on the profit from every product sold since it is related to all business activities.
All of these components within customer satisfaction are dynamic. The rate at which components change varies greatly, but they do change over time. The goal is to try and optimise these components and maximise customer satisfaction as a result.
This research is focused on logistics and cost since those aspects are relevant to the transportation and distribution of most physical goods. Improvements in those aspects of customer satisfaction would be a benefit to most companies and consumers.
The key fundamental activities in a logistics operation include [2]: 1. Customer Service
2. Demand Forecasting / Planning 3. Inventory Management
4. Logistics Communications 5. Materials Handling
6. Order Processing 7. Packaging
8. Parts and Service Support
9. Plant and Warehouse Site Selection 10. Procurement
11. Return Goods Handling 12. Reverse Logistics
13. Traffic and Transportation 14. Warehousing and Storage
From this list it should be clear that even within a simple logistics operation there are multiple disciplines involved that have vastly different challenges and requirements. In many operations not all of these activities are handled by the same entity, but instead by separate entities that specialise in one or multiple of these activities. Each of these entities interacts with each other but can have different operational and technology solutions. Competing entities that specialise in the same activities could also be using different technology solutions.
The goal of a corridor performance benchmarking dashboard is to gather information from all these different disciplines and quantify their performance so that improvements or setbacks can be measured. The corridor performance benchmarking dashboard aims to provide a more holistic view of the entire logistics process so that each player involved in the activities is more aware of how they are impacted and how their actions impact the system as a whole.
1.2.2 Current Problems
The systems approach states that all functions or activities need to be understood regarding how they affect and are affected by other elements and activities with which they interact [2]. If activities are considered in isolation how those activities affect (or are affected by) other activities cannot be fully understood. In the context of logistics, this means that each entity needs to understand its role within the larger system and be able to play that role optimally. They should also understand the roles of other entities within the system and how their operations are affected by (or affects) the operations of other entities.
Currently, corridor entities invest more of their effort in optimising their operations and less in their interactions with the operations of other entities they engage with within the industry. The result is that inefficiencies manifest within the interactions between entities and not within the operations of entities themselves.
A simple example would be the interaction between cargo transporters and a border post. Transporter vehicles typically depart to the border post without notice and expect to be serviced upon arrival. The border post has no insight into the amount of traffic it can expect, and as a result, cannot be certain the operations will be able to accommodate the expected traffic. The result of this exchange is that the border post ends up trying to accommodate traffic increases beyond the capacity it can handle and the transporter vehicles experience unforeseen delays. If the border post is able coordinate with transporters to ensure the number of vehicles at the border post at any given time does not exceed the operational capacity then both parties benefit as a result.
The purpose of a corridor performance dashboard is to highlight these inefficiencies by collecting data from all relevant entities along the corridor. Once the inefficient areas are identified, and their impact can be quantified, possible solutions can be developed to streamline the interactions between entities along the entire logistics corridor.
1.2.3 Potential Causes
Performance benchmarking based on dashboards is not a new concept and has been used in different industries for decades at this point. It is however rare to find a performance benchmarking dashboard for an entire industry. Before attempting to develop such a solution, it needs to be understood why these types of solutions do not already exist.
The first potential cause that could prohibit the creation of a corridor performance dashboard is a lack of data. If data is not being collected at a granular enough level that would enable the
creation of a dashboard, then extracting measurements for a performance dashboard would not be possible. As the world continues to migrate to digital solutions the concern of insufficient data should diminish over time. With companies progressing toward paperless operations, more data is becoming available for developing better metrics and benchmarking solutions. Solutions such as RFID technology can aid in collecting data that could otherwise not be collected.
Another potential cause that could explain the lack of corridor performance dashboards is that data is being collected at a sufficient level of detail, but entities choose not to share it or are unable to share it. Coordinating every entity across an entire corridor is a significant challenge as it requires all of them to provide data to a centralised system. Some entities likely cannot supply data in an electronic form or via an electronic data interchange. Convincing all the entities along a corridor that there is value in participating during the development of a dashboard of this scale would require a large amount of negotiating. Since there is typically no entity that has control over the entire corridor, finding funding for such a project is another likely reason that these types of solutions are not common. The most likely entity that would be interested in funding such a project would be a governmental entity since they would enjoy the oversight over their entire portion of the corridor as well as in neighbouring countries.
Each year a large number of surveys are completed to try and better understand the desires and needs of the logistics industry. Two of these surveys which are relevant to this study are the State of Logistics Survey as well as the Third Party Logistics results and findings. The first survey monitors the economic efficiency of the South African logistics industry and is published yearly [4]. According to the study, the Logistics Performance Index (LPI) of South Africa is ranked 20th out of 160 countries. Despite South Africa performing well the performance of corridors in and around the country perform worse since the efficiency of a corridor relies on all the countries involved.
The second survey is an international survey that tries to understand the needs and challenges of Third-party logistics providers. Most third-party logistics providers operate at an international level since production and distribution is typically spread across multiple countries and continents. In the survey participants are asked which capabilities they want from IT systems. The capabilities 3PL’s desire most from IT systems are [5]:
Transport management systems for planning.
Electronic data interchanges (EDI).
Visibility of orders, shipments, inventory, etc.
Warehouse and distribution centre management.
Web portals for booking, order tracking, etc.
The capabilities on this list seem to validate the idea that an adequate amount of data is not being captured since there is a desire to capture operational data related to planning and scheduling. It also seems to validate the lack of data sharing capabilities since 68% of respondents requested EDI's.
If data is collected at an acceptable level of detail and made available by entities across the corridor, another potential cause could be that there is no motivation to invest in analysing such large datasets. Given the amount of effort involved in integrating and transforming data sets from all entities in the corridor, there would need to be substantial benefits from implementing a corridor performance dashboard. To provide benefits to data providers, metrics that they consider valuable would need to be determined and presented in a way they can understand and use effectively. Knowing what to measure is just as important as the act of measuring. If the metrics currently considered to be the appropriate measurements are incorrect or incomplete, the development of a dashboard might not seem like a sound investment to data providers.
1.3 Research Proposal 1.3.1 Problem Statement
Investigate the current needs of performance benchmarking dashboard software for transport corridors. Design, implement and evaluate a proof of concept solution to satisfy the needs of corridor stakeholders.
1.3.2 Research Scope
The goal of this research is to investigate and understand the needs that should be addressed with a corridor performance benchmarking dashboard. Next, investigate the relevant software solution landscape within South Africa as well as internationally and determine any major trends within the industry.
Define key requirements and outcomes that a corridor performance benchmarking dashboard needs to satisfy. Design and implement a proof of concept corridor performance benchmarking dashboard solution by incorporating modern software best practices commonly found in the software industry today.
1.4 Research Objectives 1.4.1 Primary Objectives
The main objective of this research is to better understand the requirements of a corridor performance benchmarking dashboard. Once the requirements are understood, the architecture of the system needs to be designed and a proof of concept corridor performance benchmarking dashboard needs to be implemented for industry partners involved with the project. Additional changes or iterations that could improve the design need to be defined based on the experience gained from implementing a performance dashboard solution for industry partners.
1.4.2 Secondary Objectives
Discuss the method of analysis used to produce results and present key findings if the industry partner is comfortable with sharing the results.
1.5 Research Motivation
Currently, players in the logistics industry understand and perform their roles fairly well, but do not perform as well within the context of the entire corridor. To further improve corridor performance, solutions require coordination between multiple entities to streamline their interactions with each other. A higher level of coordination requires their systems, data and operations to align and work similarly to a single owner supply chain. Convincing entities throughout the entire corridor that there is potential value to be gained from a higher level of cooperation is just as important as facilitating the coordination with technical solutions.
The primary motivation for this research is to understand how to design and implement corridor performance dashboards. Developing ways to define, extract and present better metrics that entities in the corridor find useful for operations and root-cause analysis is another goal that motivates this research. By providing more comprehensive and useful solutions, we hope to help entities along the corridor to quantify inefficiencies related to time and money and motivate them to pursue further improvements in their operations and the corridor as a whole.
1.6 Research Methodology
Throughout the research, a combination of qualitative and quantitative methodologies is used. Due to the lack of objective, quantified measurements the needs of entities along the corridors are based on qualitative, subjective perceptions. By combining a large number of entity perceptions across the corridor as well as recommendations from industry experts, we hope to understand the underlying requirements of a corridor performance dashboard better.
The development of a corridor performance dashboard will provide quantified measurements which are expected to encourage more accurate corridor management. These quantitative results are to be used as a baseline for performance within the corridor to compare to future values and measure performance changes.
Software requirements will be determined from corridor entity needs and architecture of the system will be designed according to the engineering process. Possible software services and solutions are identified, aggregated and compared to a set of defined requirements in a technology survey in order to measure the viability of each solution. Other quantitative aspects include determining the technical requirements of a potential solution to each problem, such as the required performance of the solution and ensuring each solution could scale to support the data collection and processing requirements.
An appropriate software development lifecycle model will be used to implement a proof of concept system which is tested according to documented industry standards as well as standards provided by the Institute of Electrical and Electronics Engineers (IEEE).
1.7 Beneficiaries of Research
By developing a corridor performance dashboard, we aim to provide objective measurements for all entities along the corridor. The first beneficiary of corridor performance dashboards is road transporters. Visibility of operations at ports, border posts and customs office would enable transporters to actively evaluate routes between locations and assist in selecting the most optimal routes to use.
Cargo owners and freight agents benefit from a corridor performance dashboard by having visibility across the entire corridor, allowing them to monitor the status of goods better and account for any problems occurring before goods are affected. Suppliers can better coordinate with clients if they have visibility over product demands to ensure supply more closely meets demands.
Public sector entities such as ports, border posts, customs offices and weighbridges also benefit from a corridor performance dashboard. By having visibility over the corridor, facilities can monitor the amount of traffic they receive and better prepare for any fluctuations since logistical operations tend to be seasonal with increased demand during holiday periods. Monitoring the historical performance of different facilities would allow the public sector to compare the performance of similar facilities. These historical measurements should help determine if there are potential for improvements among any of the facilities.
Given how uncommon corridor performance dashboards are there could be other beneficiaries that gain from having visibility over the entire corridor. By implementing a proof of concept dashboard additional benefits and beneficiaries might become apparent which are difficult to conceive of without practical implementation.
1.8 Dissertation Layout
This first chapter describes the motivations and methodologies of this research. This chapter also considers potential reasons why corridor performance dashboards are not common across all corridors.
Chapter two describes trade corridors in more detail to provide a background to the problem this research aims to explore. This chapter defines requirements for a proof of concept corridor performance dashboard as determined through collaboration with industry partners and by reviewing industry expert consultations done prior to the project. The analysis techniques used to extract key performance indicators from the data are discussed. A technology survey is done to compare different solutions and determine viable options for the project.
Chapter three addresses the design of the dashboard software to meet the requirements documented in chapter two, while taking into account the availability of suitable technology of investigated in the literature study.
In chapter four the different evaluations are described and applied to the proof of concept system to ensure that it can satisfy requirements. Chapter four helps identify any short-term issues in the design that might lead to the dashboard not performing as required. This chapter helps to define a roadmap for further improvements to the system over time. This chapter also discusses the overall user experience considerations made to make the complexity of the data and results easier to understand.
Chapter five discusses the conclusions and recommendations from developing a corridor performance dashboard solution.
1.9 Chapter Summary
In recent years companies have been investing in business intelligence and incorporating data collection and utilisation into management practices. The result of this is IT systems that provide large amounts of data both in volume and variety. Companies developed proprietary reporting tools to better understand the state of operations with less effort and time investment. All of these advancements in data utilisation have allowed companies to improve their operations continuously.
In the logistics industry there is, however, a limit to the efficiency a company can achieve in isolation. Since a large portion of their operations is dependent on other entities in the logistics value chain, inefficiencies often exist in the interactions between entities. These inefficiencies are difficult to quantify since different value chain entities have different levels of visibility and data capture capabilities.
Corridor performance dashboards aim to provide corridors and their stakeholders with a means to quantify current and historical corridor performance and perform root-cause analysis. This study documents the process used in designing and implementing a corridor performance dashboard prototype.
2 LITERATURE STUDY
2.1 Chapter Overview
This chapter describes how trade corridors are structured and the numerous players involved in making trade corridors function. The key stakeholders of trade corridors are discussed next and an overview is provided of the project upon which this dissertation is based. The methods that will be used to calculate performance indicators for the dashboard are briefly summarised. These analysis methods provide a generalised solution to generating measurements and more specific details will depend on industry demands and cooperation.
Recent trends and events within the software industry are also briefly discussed including cloud computing, open source software, big data and internet-of-things (IoT). The potential uses of RFID technologies and the benefits it could provide within a trade corridor are also discussed. Finally we briefly discuss the differences in the ways users from developed and developing countries access the internet and how this impacts the development of software solutions for developing countries.
2.2 Overview of Trade Corridors
Landlocked countries are countries with very little or no shoreline which results in these countries having inherent trading disadvantages. The majority of the freight in the world is transported between nations via ships. Landlocked countries are therefore dependent on their neighbouring countries with ports (referred to as transit neighbours) to handle their international freight [6]. Trade corridors define overland routes where agreements are in place between landlocked countries and their coastal neighbours to transport their cargo to and from ports. This relationship between countries can introduce many issues such as infrastructure provisioning and maintenance, compensation, cross-border driver travel and insurance [6].
2.3 Project Overview
This study is based on a project in collaboration with the Ministry of Works, Transport and Communication of The United Republic of Tanzania which involves the acquisition and customisation of a corridor performance monitoring system. Figure 2-1 shows a zoomed-in section of the image presented in [7]. The corridor consists of road and rail modes of transport. Road and trail modes branch from the port into a northbound section and a southbound section. Trips with the Dar es Salaam port as an origin are considered import (or inbound) trips. Trips with the Dar es Salaam port as the destination are considered export (or outbound) trips.
Figure 2-1: Geographical map of Dar es Salaam Corridor.
An important part of this corridor performance monitoring system is the corridor performance dashboard. The purpose of the dashboard is to showcase all the key performance indicators (KPIs) for the corridor and be used to establish baseline performance benchmarks for the corridor. Once a baseline is established, the dashboard will allow users to periodically measure corridor performance to see what effects operational changes (operational, regulatory or otherwise) are having on corridor performance.
This section describes the requirements stated in the terms of reference (ToR) for the project as well as the data expected from corridor stakeholders for the project. The project is structured so that the described sections will be implemented as data is made available by corridor stakeholders. Regardless if data is available or not, the dashboard needs to be able to support both data available during initial development as well as data that becomes available in the future. The ToR primarily describes the business and performance requirements of the project such as the different types of KPIs and reports the system needs to be able to generate as well as other operational obligations to ensure the system continues to operate for the lifetime of the project. Any technical specifications for the project such as software and technology selection
for achieving the business requirements are the responsibility of the various software development partners involved in the project.
2.4 Key Trade Corridor Players and Requirements
Trade corridors consist of several stakeholders that each plays a role in the overall logistics operation. These include both governmental agencies and private sector companies. In some cases, different roles might be performed by the same company. The roles played by the most prominent stakeholders are described in the sections below.
2.4.1 Cargo Owners
Cargo owners are the main clients of the entire trade corridor. They manufacture or acquire the goods being transported along the corridor. Cargo owners employ the services of other players along the corridor by outsourcing their logistics operations and by interacting with governmental players such as customs to ensure the business they conduct is within the law. Some cargo owners might handle the transportation of goods themselves (referred to as a first-party logistics model or 1PL), but it has become a common practice throughout the industry to use a second party logistics model (2PL) or a third party logistics model (3PL). In a 2PL configuration, the cargo owner contracts an asset carrier to execute transportation or logistics tasks [8]. In a 3PL configuration, the management of subcontracting the transport and storage of goods is outsourced to a third party. This party negotiates and manages the supply chain on behalf of the cargo owner.
The main motivation for the creation of a corridor monitoring system is to attract more cargo owners to the trade corridor. The primary requirement for cargo owners from the corridor performance dashboard is to be able to receive reports with regards to how the corridor is performing. The reports expected from this project can be divided into five main categories:
Time-Related Reports: These reports primarily describe how long specific operations take along the corridor as well as the duration to cover the entire corridor. The reports also describe delays that occur in the corridor such as the wait times of ships, trucks and trains at specific steps in supply chains.
Cost-Related Reports: Cost reports primarily describe the financial expenses associated with the corridor. The reports describe the cost of transportation services such as road transporters and shipping lines as well as charges of facilities along the corridor such as ports and border posts.
Security and Safety Reports: The goal of security and safety reports is to identify any high-risk locations along the corridor where crime or other incidents occur. These reports are closely related to cost but describe unintended expenses or damages as opposed to the operating expenses described in cost-related reports.
Infrastructure Reports: These reports describe the condition of corridor infrastructures such as roads and railways. This information could be important to some cargo owners when considering different solutions to their logistics problems.
Miscellaneous Reports: Any reports that could not be classified in one of the previous sections are classified as miscellaneous.
2.4.2 Clearing and Forwarding Agents
Clearing and forwarding agents (CFAs) allow manufacturers to outsource the majority of their logistics operation to a party with the expertise of creating and managing complex logistics operations. The roles of clearing and forwarding agents include [9]:
Perform customs procedures on behalf of the manufacturer.
Ensure that all procedures are compliant with current legislation.
Facilitate the movement and storage of cargo locally and internationally.
Manage licences and insurance of goods.
By outsourcing the management of the logistics value chain, a manufacturer can focus on product production and rely on their third-party logistics partner (most commonly a CFA) to get product shipments to customers and retailers reliably and cost-effectively. The corridor performance monitoring system needs to be able to capture information from participating clearing and forwarding agents in the four countries involved in the project. The data that needs to be captured from clearing and forwarding agents where possible includes:
Name, size and packaging for the cargo.
Details about the cargo owner.
Origin and destination information.
Details regarding transportation methods.
Schedule of the goods such as arrival and release times.
Details regarding cost, including import and export duties paid.
The data described above will be used to contribute to the reports available on the system. Since clearing and forwarding agents typically run the supply chain on behalf of the cargo owner, the majority of the reports intended for cargo owners will be used by clearing and forwarding agents as well. Time-related reports are available to primarily monitor the performance of ports and border posts since those are the areas where clearing and forwarding agents are the most involved. Clearing and forwarding agents will be expected to submit cost estimates for various scenarios which will be refined into anonymised industry benchmarks. These types of industry benchmarks will be available as part of the cost related reports.
Security and Infrastructure reports are primarily aimed at the facilities that provide the data but might be useful for clearing and forwarding agents if they want to compare the current supply chain with possible alternatives. The data supplied by clearing and forwarding agents are incorporated into miscellaneous reports such as reports related to the total amount of cargo that passed through the corridor. Miscellaneous reports are mostly intended for agencies involved with monitoring the corridor with the goal of increasing utilisation, but these reports might provide value to clearing and forwarding agents not apparent during design.
2.4.3 Shipping Lines
Shipping lines are large international corporations that transport cargo along supply chains spanning multiple continents. Due to the size of shipping lines and the role they play the rest of the supply chain is typically dependent on their schedule and performance. Due to the nature of how ships operate any delays a ship experiences immediately impacts the supply chain. Cargo can only be loaded and unloaded at a port which means there are limited methods available to mitigate ship delays while the ship is at sea. Solutions to this problem typically involve excessive cargo surplus kept as a buffer if a delay occurs [6]. The corridor monitoring system needs to capture these delays and monitor their frequency and effect on the corridor. Data required from shipping lines include:
Summary of the anchorage process including operation times and causes of delays.
Summary of the ship berthing process including operation times and causes of delays.
Details regarding cargo such as name, size, origin, destination and owner.
Clearing and forwarding agent or shipper details.
This data will be used in time-related performance measurements for port operations such as the anonymised anchorage and berth durations of ships at different ports. This data will also be used to determine industry-wide averages regarding ocean and port charges.
2.4.4 Ports
If shipping lines are responsible for facilitating the majority of international cargo transport, then ports play a key role in transferring cargo from land-based transport solutions to freighter ships and vice versa. Monitoring and improving performance around ports can potentially provide industry-wide benefits. The majority of the data required from ports are similar to the data required from shipping lines. By collecting data from both parties, the corridor performance monitoring system could validate delays and highlight any inconsistencies between the data sets. Data required from ports include:
Dates and durations of maritime operations including anchorage and berth times.
Dates and durations of port operations including cargo discharge and loading times.
Dates and durations of customs operations including cargo details and release times.
Other cargo details such as CFA details, owner details, origins and destinations.
Cost-related information including port charges for different countries.
Security-related information such as port crime records.
The data described above will be used in the same time-related reports described for shipping lines and will provide an additional perspective on operations. This data will also be compared with rail and road transporter data to determine the turnaround times of vehicles (trucks and trains) at ports. By consolidating port operational data and transporter data, the behaviour of vehicle operators should become more apparent. Determining if vehicle operators spend more time at ports than operations require is one example of a measurement that is only possible by combining these data sets. Other uses of the data from ports include the comparison of cost and security for different ports.
2.4.5 Border Posts
In the case of landlocked countries, the majority of goods being imported by land will need to cross country borders at some point. Border posts are specific locations on the borders between countries where the majority of traffic travels between the two countries. Similar to ports, border posts create a high concentration of cargo that needs to flow through a small number of facilities. In the context of African trade corridors, the border posts are notorious for long and
Research has shown that long delays are not a major concern for the industry since long delays only result in a longer duration supply chain overall and do not impact the frequency at which cargo can be delivered [10]. Improving the predictability of delays would have a much larger impact on supply chains. Predictable delays allow for just-in-time supply chains with minimal buffers of extra cargo to combat unpredictability.
In the case of the Dar es Salaam corridor, large amounts of traffic at border posts come from the neighbouring countries using the Dar es Salaam port for imports and exports. The concern regarding these border posts is whether the current infrastructure is sufficient to handle all the traffic if run efficiently or if additional infrastructure is required. To answer this question the operations of border posts need to be monitored and the data used to look for inefficiencies. The data required from border posts include:
Cargo-related details such as the name, volume, value, permits, origin, destination and owner.
Border post operational information such as date and time of submissions and releases.
Cargo cost-related information such as duties, taxes, fees, charges and tariffs collected.
Details about involved parties such as the CFA, vehicle and driver.
Reasons for cargo delays including suspensions, rejections and amendments.
General information about procedures such as pre-clearance, appeals, bonds and penalties. This data will be used to generate reports regarding time vehicles and cargo spends at different border posts. Reports regarding the costs at different border posts will also be generated from this data set. These reports are more intended to help the management of facilities improve their operations than to provide insight for cargo owners since border posts are often a mandatory step for supply chains on the trade corridor with few or no alternatives.
2.4.6 Inland Transportation
Inland Transportation is the most expensive and time-consuming component in the trade corridor. Shipping lines are also a form of transportation but are excluded from this section since they operate outside the trade corridor. The transportation section of the project focuses mainly on road vehicles and their drivers as well as trains and their operators.
Railways throughout Africa has seen significantly less utilisation when compared to road transportation and is almost exclusively used to transport heavy unrefined minerals which in the case of Tanzania are natural resources such as cement and timber [11]. In contrast, the majority of containerised goods are transported using the road network.
One of the key challenges in the road transport industry is infrastructure. Since the late 1990’s the main trunk roads that connect major cities have been improved which have resulted in significant road transport improvements. Detailed information is required from road transporters, truck drivers and railway companies to benchmark and monitor the performance of transport sections of the trade corridor. Data required from railway companies include:
Operational information such as transit times, departure times and arrival times.
Geographical information such as routes, departure locations and arrival locations.
Cargo-related details such as the name, volume, value, origin, destination and owner.
Cost-related information such as quotations for transporting different kinds of goods.
Third party details such as involved clearing and forwarding agents.
Rail transport has historically proven to be a very dependable and predictable method of transport but requires large quantities of cargo to be cost-effective. Rail transport has been trending downwards in Tanzania since the early 2000s, and as a result, the majority of goods have shifted to road transport [11]. Since road transport has become such a critical component of African trade corridors, data collection efforts for road transport are included in this project. The data requested from road transport operators include:
Operational information such as transit times, departure times, arrival times and turnaround times.
Geographical information such as routes, departure locations and arrival locations.
Cargo-related details such as the name, volume, value, origin, destination and owner.
Cost-related information such as quotations for transporting different kinds of goods.
Third-party details such as involved clearing and forwarding agents.
Trip-related information such as the duration spent at cities, weighbridges, border posts, police stops and roadblocks.
The project also includes the provisioning and deployment of 100 mobile devices that can communicate road trip information to the main monitoring system remotely via GSM technology. These devices will be used by truck drivers to record their journeys in an attempt to better document what is happening along the corridor. The data expected to be collected from these devices include:
Cities, weighbridges, police roadblocks, border posts that the driver visited while on the route specified above.
Reasons for delays at any of the places mentioned above.
Capturing more detailed information regarding the cause of delays will provide additional insight into how these delays can be mitigated in the future. By combining driver reported data with data made available by road transport operators, a far more complete picture of the trade corridor could be constructed.
2.4.7 Public sector
Public sector entities are primarily concerned with regulation and law enforcement. These entities are also the primary cause of delays since their work of inspecting corridor users is disruptive. The data collected from these entities will be used to determine if the practices currently in place are excessive, appropriate or lacking. The first entity that can provide details regarding the infrastructure of the trade corridor is the road authorities since they are responsible for managing the road infrastructure. Data requested from road authorities include:
The status and classification of infrastructure along the corridor including roads, bridges and underpasses.
Infrastructure maintenance and implementation schedules for the corridor.
Disaster recovery, risk management and risk mitigation procedures for the corridor.
Any additional information about infrastructure reliability.
The next public sector entity from which information will be requested is the traffic police. Traffic police ensure compliance of vehicles on the road and will provide the following information:
Accident reports with details about the truck, driver, company, cargo, location, time and cause of the accident if possible.
Traffic offence reports that include the same details as accident reports.
Records about crimes being committed along the corridor.
Information regarding road accessibility such as restrictions on certain roads at certain times of day for trucks.
Any additional information related to the safety and security of roads such as a security strategy for road safety.
if cargo is allowed to cross country border based on the declared good and if necessary and inspection of the cargo for any incorrectly declared or illegal contents. The information provided by customs will primarily consist of historical declarations handled at every customs office. These declarations contain information about:
Details related to the declaration such as the clearance plan, customs regime, orgin country, destination country and customs offices used.
Details about how each declaration was processed as it passed through the customs process including any verification, inspections, amendments and other steps involved.
The last public sector entity that data will be requested from is weighbridges. Weighbridges work alongside traffic police to ensure that trucks comply with axle weight regulations. Collecting data regarding how compliant vehicles are at different weighbridges will help officials determine locations that need additional policing. By focusing primarily on the worst performing locations, the largest improvement should be possible without excessive resource spending across all the weighbridges. The data that will be requested from weighbridges includes:
Operational details about the weighbridge such as the name and locations of stations, charges at each station and the weighing capabilities of each station.
Scale calibration records to verify that the scales are providing accurate results.
Records of trucks that have been weighed including axle configuration and other truck details as well as cargo details.
The data described above is not strictly needed to measure the performance of the corridor since the results of these operations will be reflected in time and cost measurements of transporter data. This data does, however, provide much-needed detail about the causes of delays and additional costs that would be invaluable in root-cause analysis. Empirical measurements of what has happened and is currently happening are only really useful if the causes of those measurements can be determined and verified. The data from this section will help to identify those causes.
2.4.8 General public
The trade corridor can be viewed as a complex system and the corridor monitoring system as the feedback mechanism that informs the management of this complex system. Introducing excessive delays on a specific route could cause general traffic to divert to different routes and impact the performance of those routes indirectly. This complex system involves the general
public to some degree and feedback from the general public also needs to be incorporated. Data to be collected from the general public includes:
Complaints related to entities along the corridor including transporters, police officers, customs officers, immigration officers or any other entity within the corridor.
Feedback and recommendations on the corridor monitoring system to ensure that the metrics being monitored are correct and valuable.
Social media can also be used as a tool to engage with the general public and in doing so get more feedback. Some of the requirements described for social media in the corridor monitoring system include:
Increasing the awareness, conversions and loyalty of the public and partners.
Advertising and content sharing targeted at specific demographics.
Engaging with partners and transferring that engagement to the website.
The feedback received from the public will primarily be used to aid in the management and development of the corridor monitoring system.
2.4.9 Future Considerations
The corridor monitoring system requires that potential future technologies that might be introduced into the trade corridor be considered during the design. The likely technologies specified to be supported in the foreseeable future include:
GIS Software
CCTY solutions
Improved data collection solutions, such as RFID.
2.5 Data Analysis Techniques
The majority of the analysis for this project is done within the main corridor monitoring system. The dashboard only performs very basic aggregation and statistical calculations depending on the required metrics. This section briefly describes the process used within the main monitoring system to produce individual results.
2.5.1 Operational Flow Graphs
The first step in the analysis is to gain an understanding of what the end user wants to measure and how much of those desired measurements are possible from the data currently being collected in their systems. The process typically involves the creation of a flow diagram that tries to capture operations at an acceptable level of detail. Figure 2-2 shows a simplified version of a typical supply chain. Each node represents a specific task that needs to be performed within the supply chain. The arrows (also referred to as edges) represent how the different tasks are related to each other.
There are no fixed criteria for defining tasks, but in the case of a logistics supply chain, it seems appropriate to define nodes around each entity responsible for the task. Each block can also be divided into more nodes through an iterative process if more granular levels of detail are required. A single node could also branch into multiple other nodes.
Figure 2-2: Flow diagram illustrating a simplified vertical supply chain.
An example in the context of the above diagram would be to have a second edge from Manufacturing to an additional Rail Transportation node with another edge to Border Operations. The result would be that there are two pathways from Manufacturing to Border Operations. The first path would be through Road Transportation and the second path through Rail Transportation.
2.5.2 Relating data to operations
The next step in the process is to identify which values in the available datasets can be used to measure the performance of a specific task. A common example is using timestamps to measure how long a specific task took to complete. In Figure 2-3 a subset of the full flow diagram in Figure 2-2 is shown.
From available data, the start and end conditions for each task can be defined. An example might be using GPS data to determine when a vehicle enters and exits a geo-fence surrounding
a border post. Using the timestamps recorded when the vehicle entered and exited the area can provide an estimation of how long the vehicle was at the border post.
Figure 2-3: Flow diagram illustrating the relationship between data and operations.
This definition is only one way to determine how long operations at the border post took. Using data from the border post itself might reveal a different result. If the vehicle spent additional time just inside the geo-fence after completing operations at the border post, the border post might appear to be slower than it actually is. Comparing GPS based timestamps with timestamps in the system of the border post could potentially reveal these types of behaviours that would otherwise remain obfuscated if only one data set was available.
The definitions of when a task starts and ends can be based on any set of criteria as long as the definitions themselves are clearly described. Knowing what is being measured and how it is being measured is critical if different measurements from different sources measure the performance of the same task. If the measurement definitions are unclear, it becomes difficult to validate task performance with multiple data sets and to determine the root cause of poor performance.
2.5.3 Measurement calculation
After the start and end conditions of each task are defined, each key performance indicator (KPI) can also be defined. A key performance indicator is a measurable value that determines the progress towards a specific business objective [12]. KPIs can be defined for the simplest tasks or the company as a whole. Similar to the task definitions, each KPI must be clearly defined including what it means when the KPI changes, how the KPI is measured and what can be done to influence the KPI. Other aspects about the KPI that need to be defined include the people responsible for improving the tasks measured by the KPI, acceptable performance levels and the frequency at which KPI results will be produced and reviewed.
Figure 2-4 illustrates the relationships between the measurements being made, the data used for those measurements and the underlying operational tasks being measured. Data Entry A
previous examples these might be timestamps from GPS or the border post systems. Measurement A uses those data values to calculate a measurement for that task. Measurement A could be a variety of measurements depending on what needs to be monitored. One measurement could be the average amount of time spent at the border post by each vehicle. Another measurement could be the total number of vehicles processed per hour.
Depending on who is using the measurement it might have varying levels of value to the user. Road transporters might consider the first measurement more valuable since they can incorporate the time vehicles will spend at a border into their planning. The second measurement might not be valuable to road transporters at all. On the other hand, the border post might find the second measurement more valuable since they can use it to measure if operational changes increase the number of vehicles they can service per hour.
Figure 2-4: Flow diagram illustrating the relationship between data and measurements.
For the corridor performance dashboard, tasks are defined in a similar fashion as described in Figure 2-4. Each step that cargo goes through along a route is defined as a separate step. These steps include port and border post operations, road or rail transportation, activities within cities, sections of road, and other locations of interest such as weighbridges and police stops. All the measurements required for the dashboard are derived from these tasks.
The main corridor performance system produces individual results for every task such as the time spent by a specific vehicle at a specific location. Those individual results are then queried and combined to produce the appropriate measurement such as the average time spent by vehicles at a location. The corridor performance dashboard needs to be able to perform these basic aggregations when needed since the same data set could be used to produce different measurements. Some of these aggregations are performed by the main corridor performance system, but the majority are handled by the dashboard solution.
2.5.4 Measurement presentation
Presenting data is the primary purpose of the corridor performance dashboard. The requirements in the TOR do not specifically dictate how performance measurements should be presented to users in this project. Through various discussions with stakeholders, it was decided that the dashboard should be able to support some of the most commonly used visualisation methods. These visualisation options include:
Result Tables Line charts Bar charts Pie charts Box plots Histograms Geographical Maps
These visualisation requirements are most likely going to change and be iteratively refined as users provide feedback. The chosen visualisation solution needs to be flexible enough to change how a data set is visualised with minimal effort.
2.6 Trends and Events in Technology 2.6.1 Cloud Computing Adoption
Cloud-based systems have seen major adoption in developed nations since cloud providers first started offering services around 2002. Researchers from a cloud industry research team surveyed 786 technical professionals and noted that 94% of respondents use cloud solutions [13]. Developing countries, however, have seen slower adoption rates compared to the developed world. According to a report by the United Nations some of the key barriers contributing to slow cloud adoption include [14]:
Availability and quality of cloud-related infrastructure.
Cost considerations.
Inadequate legal and regulatory frameworks to address data protection and privacy. Despite these challenges the main benefits cloud solutions could offer are [14]:
Cost savings.
