quanti cation of smes' work environment, happiness, and productivity, using a microservices …...

Universidade de Coimbra

Faculdade de Ciências e Tecnologia

Quanti�cation of SMEs' work

environment, happiness, and

productivity, using a

Microservices Architecture

Daniel Fernandes Lopes

Thesis submitted for the degree of Master of Science

in Physics Engineering

September 2015

Universidade de Coimbra

Faculdade de Ciências e Tecnologia

Quanti�cation of SMEs' work

environment, happiness, and

productivity, using aMicroservices Architecture

Daniel Fernandes Lopes

Thesis submitted for the degree of Master of Science

in Physics Engineering

Under the supervision of:

Jorge Landeck, University of Coimbra

Rafael Jegundo, Whitesmith

September 2015

Abstract

On a study performed by Sierra-Cedar HR Systems in 2014, only 12% of

organisations adopted some form of HR analytics. On the same study it was

concluded that Quanti�ed Workplaces out-perform other organisations - they

see higher levels of �nancial performance, as well as positive HR and Return

on Equity (ROE) outcomes [1]. Currently, most of the data-driven companies

are only focused on the data provided by consumers - data-driven decisions are

made practically only in product development, marketing, and pricing - or data

provided by time tracking software installed on employees computers [1].

With the current state of the art, there's potential to build tools that quan-

tify collective behaviour at an organisation on a real-time basis, thus providing

insights that can help improving processes and practices that enable to achieve

organisational goals. Tools that can be part of a framework for designing a strat-

egy and preparing the business to execute it with iterative and adaptive Agile

methodologies, rather than a biennial or triennial major initiative.

This master thesis work consists in building a platform to achieve such goals.

Its challenges are: continuous collection, processing, and storage of SME's pro-

ductivity, happiness, and o�ce environment metrics; using a Microservices Ar-

chitecture, that is modular for easy attachment and decoupling of services and

devices; integration with Internet of Things devices, with the goal of measur-

ing physical environmental quantities; building a data visualization platform to

display the collected data for analysis.

At the end, the built platform was able quantify and display various variables

related with productivity, happiness, and o�ce environment, providing valuable

information to the company at which the platform was applied - Whitesmith. The

platform and its parts were praised by various people from the Quanti�ed Self

and Data Science communities, such as Ernesto Ramirez from Quantifedself.com,

and Dan Kador from Keen IO.

Keywords: Quanti�ed Self; Quanti�ed Workplace; Internet of Things;

Service Oriented Architecture; Microservices Architecture

Resumo

Num estudo feito pela Sierra-Cedar HR Systems em 2014, apenas 12% das orga-

nizações adotaram alguma forma de recolha de dados relacionados com recursos

humanos. No mesmo estudo foi concluido que as Quanti�ed Workplaces têm

melhores resultados que outras organizações [1]. Atualmente, a maioria das em-

presas data-driven estão apenas focadas em dados provenientes dos consumidores

- i.e. a nível do desenvolvimento de produto, marketing, e preços - ou em dados

proveninentes de software de monitorização do tempo.

Através do atual estado da arte, há potencial para criar ferramentas que quan-

ti�cam em tempo real o comportamento coletivo de uma organização, e conse-

quentemente providenciar informação relevante também ele em tempo real. O

uso destas ferramentas possibilita melhorar os processos e práticas que permitem

atingir os objetivos organizacionais, usando metodologias iterativas e adaptativas

Agile, ao invés de grandes iniciativas bianuais e trianuais.

O trabalho executado nesta Tese de Mestrado tem como objectivo a aplicação

destes conceitos na construção de uma plataforma que permite atingir este tipo

de metas. Os seus desa�os são: coleção, processamento, e armazenamento con-

tinuado de dados relativos à produtividade, felicidade, e ambiente no escritório

das PMEs; uso de uma arquitetura orientada a microserviços, que seja modular

para fácil acoplamento e dissociação de serviços e dispositivos; integração com

dispositivos da Internet of Things, com o objetivo de medir grandezas físicas;

construção de uma plataform de visualização de dados para representação dos

dados recolhidos para análise.

No �nal, a plataforma construida foi capaz de quanti�car e representar várias

variáveis relacionadas com a produtividade, felicidade, e ambiente no escritório,

providenciando informação relevante à empresa na qual esta plataforma foi in-

stalada - Whitesmith. A plataforma e as suas partes foram elogiadas por várias

pessoas pertencentes às comunidades de Quanti�ed Self e Data Science, como por

exemplo Ernesto Ramirez da Quanti�edself.com, e Dan Kador da Keen IO.

Keywords: Quanti�ed Self ; Quanti�ed Workplace; Internet of Things ;

Service Oriented Architecture; Microservices Architecture

Acknowledgements

Agradecimentos

Esta minha Tese de Mestrado marca o �nal de um caminho longo, demarcado

por todas as boas vivências e, mais que tudo, todas as pessoas com que me cruzei

neste meu percurso escolar.

Obrigado a Coimbra, à Universidade de Coimbra, e a tudo o que destas fazem

parte, por me proporciarem um conjunto de aprendizagens que foram muito para

além das salas de aula.

Obrigado ao professor Jorge Landeck, pelo conteúdo e discussões das suas

aulas, e pela liberdade que me proporcionou enquanto orientador académico.

Obrigado ao Big, Carlos, Manuel, e Abílio. Obrigado ao Laurens, Paulo, e

Ramesh. Obrigado ao Gonçalo, Johny, Rui, e Neto. Obrigado a todos eles por

serem os enormes amigos que são, e por todas as vivências que experienciámos.

Obrigado ao Veloso, Peruzzi e David, por durante 6 anos partilharem comigo

um telhado, e várias peripécias.

Obrigado ao Rafael por ter sido meu mentor, e toda con�ança depositada,

durante todos estes anos. Obrigado por haver sempre algo mais para aprender

contigo.

Obrigado à jeKnowledge e todos os que desta �zeram parte. Convosco eu

aprendi e cresci imenso. Convosco eu descobri o que queria ser quando fosse

grande.

Obrigado a todos os que da Whitesmith fazem parte, por não me fazerem

pensar duas vezes sobre com quem quero trabalhar e continuar a crescer.

Obrigado ao Marcelo por alegrar os meus dias e me fazer uma pessoa melhor.

Obrigado ao meu cunhado e sobrinho. Obrigado à minha irmã por me apoiar

incondicionalmente em todas as minhas escolhas e tudo o aquilo que sou.

Obrigado aos meus pais por serem, de longe, o maior exemplo de trabalho,

esforço, e dedicação que eu conheço.

Every man I meet is my superior in some way. In that, I learn of him.

� Emerson

Contents

List of Figures 15

List of Abbreviations 19

1 Introduction 211.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.1.2 Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.3 Thesis Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3.1 Whitesmith . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3.2 Core Premises . . . . . . . . . . . . . . . . . . . . . . . . . 241.3.3 Data Collection and Processing . . . . . . . . . . . . . . . 251.3.4 Support Components . . . . . . . . . . . . . . . . . . . . . 26

2 State of the Art 272.1 Quanti�ed Self . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Quanti�ed Workplace . . . . . . . . . . . . . . . . . . . . . . . . . 292.3 Workplace Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1 Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.2 Illuminance . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.3 Telecommute . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.4 Software Development Performance . . . . . . . . . . . . . 352.3.5 Happiness . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.6 Microservices Architecture . . . . . . . . . . . . . . . . . . 392.3.7 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . 47

3 The Platform 513.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.1 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.2 Company Info Services . . . . . . . . . . . . . . . . . . . . 53

13

14 CONTENTS

3.2.3 Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2.4 Data Processing Services . . . . . . . . . . . . . . . . . . . 55

3.2.5 Data Visualisation . . . . . . . . . . . . . . . . . . . . . . 58

4 Implementation 61

4.1 Languages and Frameworks . . . . . . . . . . . . . . . . . . . . . 61

4.2 Cloud Hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.3 Error Logging and System Logging . . . . . . . . . . . . . . . . . 62

4.4 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.5 Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.6 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.6.1 Data Processing Microservices and Data Sources . . . . . . 63

4.6.2 Company Info Microservices . . . . . . . . . . . . . . . . . 70

5 Results 73

5.1 Productivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1.1 Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.1.2 Single Project . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 Happiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.1 Short Term . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.2 Long Term . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3 O�ce Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6 Conclusion and Future Work 85

6.1 Final Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.2 Community Validation . . . . . . . . . . . . . . . . . . . . . . . . 87

6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

List of Figures

1.1 Diagram representing the Quanti�ed Workplace work�ow [2]. . . . 23

2.1 YoY evolution of raised funding and number of deals in the Quan-ti�ed Self sector [13]. . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Equal loudness curves in Phons [24]. . . . . . . . . . . . . . . . . 312.3 Weighting curves in dB. A-wheighting (blue), B (yellow), C (red),

and D-wheighting (black) [26]. . . . . . . . . . . . . . . . . . . . . 322.4 The 1931 CIE photopic luminosity function. The horizontal axis

is wavelength in nm. The vertical axis is the standard luminosityfunction (which is dimensionless) [33]. . . . . . . . . . . . . . . . . 34

2.5 Experiment II results from the research of Andrew J. Oswald, Eu-genio Proto, and Daniel Sgroi, University of Warwick. Those ex-posed to the randomised happiness treatment in the laboratoryhave higher productivity. Uses the timed mathematical-additionstask of Niederle and Vesterlund 2007. Here the happiness treat-ment is a comedy movie clip in the laboratory. (95% con�denceintervals) [46] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6 Experiment IV results from the research of Andrew J. Oswald, Eu-genio Proto, and Daniel Sgroi, University of Warwick. Individualswith a recent Bad Life Event (BLE) have lower productivity. Usesthe timed mathematical-additions task of Niederle and Vesterlund2007. Here a bad life event is bereavement or family illness. (95%con�dence intervals) [46] . . . . . . . . . . . . . . . . . . . . . . . 38

2.7 Example of a Monolithic application [50]. . . . . . . . . . . . . . . 402.8 Example of a MSA-based application [50]. . . . . . . . . . . . . . 422.9 Example of communications between microservices [52]. . . . . . . 432.10 By using the API Gateway, �ne-grained requests from a desktop

client are simply proxied to the corresponding service, whereaseach coarse-grained request from a mobile client is handled by ag-gregating the results of calling multiple services [50]. . . . . . . . . 44

2.11 Three dimension scale cube [50]. . . . . . . . . . . . . . . . . . . . 462.12 IoT communication options. . . . . . . . . . . . . . . . . . . . . . 49

15

16 LIST OF FIGURES

3.1 Architecture overview. The blue boxes represent the services builtfor this project, and the green boxes represent third party services.The arrows represent the data �ow. . . . . . . . . . . . . . . . . . 52

3.2 Example of a Trello Board with Trello Lists and Cards. . . . . . . 543.3 Mike scheme, with data �ow represented by arrows. . . . . . . . . 563.4 Quantum scheme, with data �ow represented by arrows. . . . . . 563.5 Presence scheme, with data �ow represented by arrows. . . . . . . 573.6 Qalendar scheme, with data �ow represented by arrows. . . . . . . 573.7 Trello Quanti�er scheme, with data �ow represented by arrows. . 573.8 Github Quanti�er scheme, with data �ow represented by arrows. . 583.9 Shrinq scheme, with data �ow represented by arrows. . . . . . . . 59

4.1 Quantum scheme, with data �ow represented by arrows. . . . . . 644.2 Mike scheme, with data �ow represented by arrows. . . . . . . . . 644.3 Adafruit TSL2561 spectral responsivity diagram [66]. . . . . . . . 654.4 Quantum scheme, with data �ow represented by arrows. . . . . . 654.5 Presence scheme, with data �ow represented by arrows. . . . . . . 664.6 Qalendar scheme, with data �ow represented by arrows. . . . . . . 664.7 Github Quanti�er scheme, with data �ow represented by arrows. . 674.8 Shrinq question 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.9 Shrinq question 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.10 Shrinq question 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.11 Shrinq scheme, with data �ow represented by arrows. . . . . . . . 694.12 Trello Quanti�er scheme, with data �ow represented by arrows. . 71

5.1 Number of �nished tasks per week per project, over a period of 8weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Number of encountered software bugs per week per project, over aperiod of 8 weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3 Number of git commits per week per project, over a period of 8weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4 Dashboard - Productivity projects overview. . . . . . . . . . . . . 745.5 Number of �nished tasks per week on a single project, over a period

of 8 weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.6 Number of encountered software bugs per week on a single project,

over a period of 8 weeks. . . . . . . . . . . . . . . . . . . . . . . . 755.7 Average days from Bugs and Next Up to Live - Average number of

days, per week, that new tasks take from their appearance on theBugs list until it's �nished; average number of days, per week, thatnew tasks take from their appearance on the Next Up list, untilthey are �nished. Data from a period of 8 weeks. . . . . . . . . . 75

LIST OF FIGURES 17

5.8 Average days from previous list to next list - Average number ofdays, that tasks take on each list, per week, over a period of 8weeks. The lists are: Next Up, In Progress, Code Review, InternalQA, Acceptance, Live. . . . . . . . . . . . . . . . . . . . . . . . . 76

5.9 Number of git commits on a single project, over a period of 8 weeks. 765.10 Number of lines of code added per week on a single project, over

a period of 8 weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . 765.11 Number of lines of code deleted per week on a single project, over

a period of 8 weeks. . . . . . . . . . . . . . . . . . . . . . . . . . . 765.12 Dashboard - Productivity single project overview. . . . . . . . . . 775.13 Company happiness average per day, over a period of 30 days. . . 775.14 Relative di�erence between the current week's happiness average,

and the happiness average of the homologous period from last week. 785.15 Number of responses given to the "How happy are you today?"

question, per value, per day. . . . . . . . . . . . . . . . . . . . . . 785.16 Relative di�erence between the current week's number of responses

given to the "How happy are you today?" question, and the thenumber of responses given to the same question on the the homol-ogous period from last week. . . . . . . . . . . . . . . . . . . . . . 78

5.17 Remote vs Non-Remote Happiness Average - Happiness average ofemployees working remote and employees working non-remote, perday, over a period of 30 days. . . . . . . . . . . . . . . . . . . . . 79

5.18 Why people are happy - Answers given to the question "What wasthe main reason?", when answering "=)" for the "How happy areyou today?" question, for a period of 30 days. . . . . . . . . . . . 79

5.19 Why people are sad - Answers given to the question "What wasthe main reason?", when answering "=(" for the "How happy areyou today?" question, for a period of 30 days. . . . . . . . . . . . 79

5.20 Responses given to the "What is blocking you from doing yourwork? What suggestions do you have to make something better(project, company, etc)?" question, in the last 7 days. . . . . . . . 80

5.21 Dashboard - Happiness short term overview. . . . . . . . . . . . . 805.22 Company happiness average per month, over a period of 9 months. 805.23 Relative di�erence between the current month's happiness average,

and the happiness average of the homologous period from last month. 815.24 Number of responses given to the "How happy are you today?"

question, per month. . . . . . . . . . . . . . . . . . . . . . . . . . 815.25 Relative di�erence between the current month's number of re-

sponses given to the "How happy are you today?" question, andthe the number of responses given to the same question of thehomologous period from month. . . . . . . . . . . . . . . . . . . . 81

18 LIST OF FIGURES

5.26 Why people are happy - Answers given to the question "What wasthe main reason?", when answering "=)" for the "How happy areyou today?" question, for a period of 3 months. . . . . . . . . . . 82

5.27 Why people are sad - Answers given to the question "What wasthe main reason?", when answer "=(" for the "How happy are youtoday?" question, for a period of 3 months. . . . . . . . . . . . . . 82

5.28 Dashboard - Happiness long term overview. . . . . . . . . . . . . 825.29 Noise - Relative noise in the o�ce per hour, for a period of 30 days. 835.30 People - People at o�ce per hour, for a period of 30 days. . . . . 835.31 People - Illuminance at o�ce per hour, for a period of 30 days. . . 835.32 Events - Events per day over a period of 30 days. . . . . . . . . . 845.33 Dashboard - O�ce Environment overview. . . . . . . . . . . . . . 84

List of Abbreviations

CFL Compact Fluorescent Lamps

CIE Commission Internationale de l'Éclairage International Commission onIllumination

HR Human Resources

HTTP Hypertext Transfer Protocol

IEEE Institute of Electrical and Electronics Engineers

IoT Internet of Things

KPIs Key Performance Indicators

LAN Local Area Network

MSA Microservices Architecture

NFC Near Field Communication

REST Representational State Transfer

SI International System

SME Small Medium Enterprises

SOA Service Oriented Architecture

SPL Sound Pressure Level

WAN Wide Area Network

YoY Year Over Year

19

Chapter 1

Introduction

This section presents the context of this Master Thesis. It explains its motivation,importance, and goals, and �nishes with the de�ned scope of work.

1.1 Motivation

1.1.1 Context

If you can not measure it, you can not improve it.

� Lord Kelvin

Companies are always in the search of improving their performance. They doit by applying di�erent theories to their various variables such as processes, tools,company culture, company structure, and workplace conditions.

Normally they approach this change as an initiative � i.e. a one-o�, top-downmovement outside the �ow of daily work, which might or might not produceimprovement [2].

But there are various challenges with this approach [2]:

• Companies don't have practical systems to monitor the health and e�ec-tiveness of the majority of their practices.

• When companies do have systems to monitor their practices, the results ofsuch measurement tend to take an ample period of time to be published (Ex:quarterly auditorships). Thus conditioning the velocity and e�ectiveness ofhow companies can adapt and change their practices.

• To have a noticeable impact, changes applied on organisations need to beon a series of expensive high-impact projects, where a pre-de�ned model isimposed.

21

22 CHAPTER 1. INTRODUCTION

Organisations are lacking systems that can monitor their health, and e�ec-tiveness of their organisational structures and practices on an ongoing basis. Or-ganisations are lacking the tools for improving their performance in short andfrequent iterations, done by �ne measurement of multimodal variables, which canthen be crossed to provide insightful knowledge in constant and frequent feedbackloops.

1.1.2 Convergence

The term Quanti�ed Self was proposed in 2007 by Gary Wolf and Kevin Kelly,both editors from Wired Magazine [3]. They described Quanti�ed Self as "acollaboration of users and tool makers who share an interest in self knowledgethrough self-tracking" [3].

The practice consists in the collection of data about own's self "in termsof inputs (Ex: food consumed, quality of surrounding air), states (Ex: mood,arousal, blood oxygen levels), and performance (mental and physical)" [4], thusresulting in the increase of self-awareness and knowledge about what can beimproved on themselves [3].

Even though the term is relatively recent, there are records of people quanti-fying their daily life for many years in the past. For example, Benjamin Franklinfamously tracked 13 personal virtues in a daily journal to push himself towardmoral perfection [5]. He shared this insight in his autobiography: "I was sur-prised to �nd myself so much fuller of faults than I had imagined, but I had thesatisfaction of seeing them diminish." [5].

But recently - with the technology advancements, price falls, and the rise of theInternet of Things [6], - data collection has not only become cheaper and moreconvenient, but is also allowing non-specialised individuals to quantify metricsthat were impossible before.

The movement has evolved and, due to the appearance of specialised sensorsand apps on smartphones and smartwatches directed to self-quanti�cation [7] [8],it's now reaching mass-market [7].

What few have tried to achieve yet, is to explore the application of technolo-gies and principles of the Quanti�ed Self on organisations [1]. There are severalchallenges, as described on the previous section, that can be solved by creatingsystems that monitor organisations' health and practices on an ongoing basis -the Quanti�ed Workplace.

This is what sets the vision for this work: we want to create the foundationsfor a framework of organisational health measures. A framework informed bytheory and company goals, that can guide ongoing change in an agile, iterativeway, and evaluate the success or failure of change actions against a desired futureoperating state.

1.2. PROJECT 23

We believe that organisations should have a management system for ongoingchange actions that puts control in the hands of teams who want to improvetheir area of operations. But rather than o�ering a single �xed methodology, thisapproach enables people and organisations to assess and assimilate new theoriesand models that emerge in a way that allows comparison between them and, mostimportant of all, consistent measurement of progress and results.

Figure 1.1: Diagram representing the Quanti�ed Workplace work�ow [2].

1.2 Project

In this section we translate the proposed vision into an actionable project. Wealso de�ne the scope of this master thesis in concrete goals.

1.2.1 Goals

The general goals for this project are:

• Measure organisations health and performance on an ongoing basis, by col-lecting data from di�erent range of sources

• Have a system that can easily integrate new data sources.

• Provide teams insightful, near real-time, metrics about their performance,which can be then translated into actionable items.


1.3 Thesis Scope

This Master Thesis focuses on the following scope:

• A microservices based architecture for data collection on SMEs,modular for easy attachment and decoupling of future services and devices.

• Continuous data collection, processing, and storage of SME's work-place metrics

• Integration with Internet of Things devices, with the goal of measur-ing physical environmental quantities.

• A data visualisation platform to make the collected data available foranalysis.

1.3.1 Whitesmith

This Master Thesis was performed at Whitesmith. All produced work was donetaking into account Whitesmith's tools, processes, and o�ce environment.

Whitesmith is a software and hardware development SME, founded in 2012.The company builds web, mobile and IoT products for startups and media com-panies, particularly in the UK, Australia, and USA. Whitesmith also has productsof their own such as:

• Qold - a cold-chain monitoring system

• Unplugg - an energy monitoring platform

Whitesmith has a distributed team - currently, its employees work from dif-ferent places of Portugal and Brazil, with the majority working from its maino�ce in Instituto Pedro Nunes, Coimbra, Portugal.

1.3.2 Core Premises

All the developed work was done taking the following assumptions about thecollected and processed data at the company which it's applied:

• Data is used to focus on measuring quality, not quantity.

• Individual data is only used to gather insights about teams.

• All data is directly related with the work performed at the company.

• Every employee knows which data is being collected.

1.3. THESIS SCOPE 25

1.3.3 Data Collection and Processing

With the goal of measuring organisations' health and performance, we need tobuild speci�c individual services to collect and process data. The chosen variablesto be quanti�ed for this project took into account the following criteria:

• Variables that employees at Whitesmith have commented to be a�ectingtheir performance.

• Variables that science has proven to a�ect employees performance, andwhich research is documented in the State of the Art chapter of this MasterThesis.

• Ensure that the chosen variables cover the three categories: O�ce Environ-ment, Happiness, and Productivity.

Some variables - as temperature - were already being measured by alreadybuilt devices, and are going to be later integrated with the system, but outside thescope of this project. Other variables - as humidity - were not seen as impactfulon the the company's performance, and due to the natural time constraints fordeveloping this project, were left o� for future work.

By taking these considerations, at the beginning of the project we set the goalof collecting and processing data about the following variables:

• O�ce environment

� O�ce sound levels

� O�ce luminosity levels

� Employees at the o�ce

� Company activities

• Happiness

� Organisation Happiness

• Productivity

� Number of completed tasks

� Number of defects

� Code produced

� Time a given step of task takes in the context of the process

The importance of collection of data about each variable is better describedin the State of the Art chapter of this Master Thesis.


1.3.4 Support Components

To be able to cross and visualise data, other components were necessary to bebuilt:

• Data Visualisation

� Dashboard for data visualisation

• Company Info

� Platform to store and manage employees information

� Platform to store and manage projects information

Chapter 2

State of the Art

2.1 Quanti�ed Self

The current Wikipedia entry for quanti�ed self describes it as "a movement toincorporate technology into data acquisition on aspects of a person's daily lifein terms of inputs (Ex: food consumed, quality of surrounding air), states (Ex:mood, arousal, blood oxygen levels), and performance (mental and physical)." [4].

This is not a new idea. Humans have since a long time been interested in mea-suring their activities with the goal of increasing the awareness of their actions,and then improve their performance by taking into account that information.For example, athletes and coaches have been making detailed notes on nutrition,training sessions, and other elements for years [9].

But new technologies are making it simpler than ever to gather and anal-yse personal data. The size and cost of sensors are much smaller than before -accelerometers, which measure changes in direction and speed, used to cost hun-dreds of dollars but are now cheap and small enough to be routinely includedin smartphones [7]. This makes it much easier to take the quantitative methodsused in science and business and apply them to the personal sphere. Now muchof the data-gathering can be automated, and the record-keeping and analysis canbe delegated to a host of simple apps and gadgets.

People are taking advantage of the current technology to track metrics thatcan go from health (blood analysis, weight, and frequency of migraines), up tomore diverse type of metrics such as the number of hours they sleep, the food theyeat, and their sports performance [10]. These people are an eclectic mix of earlyadopters from di�erent areas such as, �tness, technology, personal-development,hacking, and even patients su�ering from a wide variety of health problems [10][11]. They share the belief that gathering and analysing data about their everydayactivities can help them improve their lives [3].

Self quanti�cation is becoming a common practice - according to a studymade in 2013 by Pew Research, about 69% of US adults track at least one health

27

28 CHAPTER 2. STATE OF THE ART

metric [12]. This goes hand-in-hand with the increasing number of Quanti�ed-Self solutions in the market, and with increased funding raised for this sector - ona year-over-year basis, investments on Quanti�ed Self startups has jumped 165%while YoY deal activity has accelerated over 40% [13].

Figure 2.1: YoY evolution of raised funding and number of deals in the Quanti�edSelf sector [13].

The movement captured the attention of entrepreneurs, who have iterated ontop of homemade solutions, and built products for the mass markets: nowadayswe have several personal activity and health trackers such as Fitbit1, Jawbone2,and more recently the Apple Watch3. These track various elements such as stepstaken, distance traveled, calories burned, hours and quality of sleep, perspiration,skin temperature, and heart rate. There are also solutions being built for otherverticals. An example is the automobilistic industry, where new devices givethe user the ability to acknowledge new information about their car's usage andhealth4 - this opens the possibility for, in the future, ask insurance companiesfor more adequate insurance plans by providing them the collected data. Othercompanies are developing platforms - as TicTrac5 - that aggregate the data frompeople's various trackers in just one place. These meta-trackers, or aggregators,aim to �nd hidden insights in all the collected data, that ultimately might helpusers improve their lives.

1https://�tbit.com/2https://jawbone.com/3http://www.apple.com/watch/4https://www.automatic.com/5https://tictrac.com/

2.2. QUANTIFIED WORKPLACE 29

2.2 Quanti�ed Workplace

The Quanti�ed Workplace serves the idea of applying Quanti�ed Self to compa-nies. The origin of the term is uncertain, but it has been mentioned several timesin several articles through the internet and newspapers. A Quanti�ed Workplaceis one that invests in technologies to quantify collective behaviour at an organisa-tion, thus providing knowledge that can help improving processes and practicesthat enable to achieve organisational goals [14] [15]. Quanti�ed Organisationssupport an environment of data-driven decision making [14] [15].

Neither data-informed management or workplace monitoring are new ideas:Management accounting emerged during the �rst half of the 20th Century [16].It requires the design of the right balance of appropriate metrics to guide per-formance and secure organisational alignment in conjunction with the associ-ated strategy. Workplace monitoring has been becoming normal, especially inblue-collar professions such as logistics and delivery, where telemetry technolo-gies track employees' physical locations, and in the hospitality and retail sectors,where closed-circuit cameras are common [17].

But these methodologies and technologies have been applied to gather a nar-row set of metrics. Specially for an era where more information than ever can begathered from software and hardware, and sensor prices are on a all time low [6].

Even in companies that are more data driven, the current state of organisationquanti�cation are either focused on the data provided by consumers - data-drivendecision is made practically only in product development, marketing, and pricing-, or data provided by time tracking software installed on employees computers -which, in general, can't provide much more information than the time spent oneach application or task [1].

There's now potential for developing tools and processes that can take advan-tage of the current state of the art to provide insightful real-time knowledge toteams and organisations - the Quanti�ed Workplace.

Now it's possible to not only measure the inputs of employees (Ex: timespent coding), but also their outputs (Ex: number of code lines produced). Wecan measure and collect all kinds of physical quantities (Ex: temperature, light,sound, and humidity) that a�ect employees productivity, and their states (Ex:happiness, stress.).

There are few companies currently trying to achieve this: in the 2014-2015survey made by Sierra-Cedar HR systems, only 12% of the organisations in theirsurvey adopted some form of HR analytics. On the same study they concludedthat Quanti�ed Workplaces out-performed other organisations [1]. They sawhigher levels of �nancial performance, as well as positive HR and Return onEquity (ROE) outcomes [1].

Google, Procter & Gamble, and Harrah's are some of the companies thatare applying analytics approach in addressing human resources needs. They're


gathering all types of data, and always iterating their processes for optimisationof their employees performance and happiness [18].

Some companies - such as Qount Us6 and Quanti�ed Organisation7 - arebuilding products that can be installed and adapted to di�erent organisations,to quantify their performance and happiness, each one with their particularities.These are on a very preliminary state, and not much has been achieved in this�eld yet.

With the current state of the art, there's potential to build tools that cansupport broad organisational objectives, by providing real-time insight to teamsand entire organisations. Tools that can be part of a framework for designing astrategy and preparing the business to execute it with iterative and adaptive Agilemethodologies, rather than a biennial or triennial major initiative, which resultscan only be known several months later. Tools that focus on empowering individ-ual teams and managers, with decentralisation and openness to information that,at the end, can result in bene�ting both individuals, teams, and organisations.Those using it are the Quanti�ed Workplaces.

2.3 Workplace Metrics

At the workplace, there are several factors that have impact on employees pro-ductivity and happiness, and consequently on an organisation's health and per-formance. To build workplace data collection services, we must be aware of theimpact that those have, and the adequate methodologies for measuring them.

Measuring an organisations' performance should take into account both in-puts (Ex: time spent working) and outputs (Ex: number of features delivered).But since workplace variables tend to in�uence each other in many ways, somevariables can be both inputs and outputs. Taking that into account, for thisproject we decided to divide metrics in three main categories:

• Environment - these take not only into account the physical quantitiesrelated with the workplace (Ex: noise, luminosity), but also activities thathave impact on how people interact (Ex: company activities).

• Productivity - measurement of productivity must be suited for the organ-isation being quanti�ed, and its work processes.

• Happiness - which is based on the collection of each employees happinesslevels.

6https://qount.us7http://www.quanti�edorganisation.com/

2.3. WORKPLACE METRICS 31

2.3.1 Noise

Noise is one of the most common complains among o�ce workers - speciallytoday, where more and more companies adopt the open-o�ce design to increaseteamwork, communication and productivity [19]. One downside of open-spacesis the augment of noise levels [20].

Some studies have found that the prolonged exposure to noise tends to in-crease the rate of illnesses (Ex: elevated blood pressure) and stress [20]. Morespeci�cally, in a study made on groups of software developers, it was found thatsoftware developers working at noisy environments tend be less happier with theirwork, and to work late during the week [21].

In part, that's because higher o�ce noise levels tend to be a cause for highernumber of interruptions. And, after resuming work from an interruption, it takesa programmer an average of 10-15 minutes to restart the previous task. [22]

Audible sound consists of pressure waves, and one of the ways to quantifythe sound is to state the amount of pressure variation relative to atmosphericpressure caused by the sound. Noise is de�ned as any unwanted sound, thatdisturb people or make it di�cult to hear wanted sounds [23]. This means thatnoise is a subjective measure that depends not only on the sound pressure, butalso on its psychological perception.

The intensity of sound has Pascals (Pa) as the o�cial SI unit, but decibels (dB)or Amplitude RMS - which are not SI units - are commonly used [23]. There'sno SI unit for noise measurement, but the Phon, the Sone, and more commonlythe dBA, are used for this purpose [23]. All of these noise measurement unitstake into account sound pressure and frequency - this is because human hearingsensitivity varies with frequency [23].

Figure 2.2: Equal loudness curves in Phons [24].


By de�nition, the number of phon of a sound is the dB SPL (Sound PressureLevel) of a sound at a frequency of 1 kHz that sounds just as loud - each equalloudness curve shown in 2.2, can be referenced to the decibel level at 1000 Hz.So, if a given sound is perceived to be as loud as a 60 dB sound at 1000 Hz, thenit is said to have a loudness of 60 phons [23].

When making practical assessments of the sound level, as a part of a generalsurvey of ambient sound levels, the type of measurement which is usually made isthat of the sound levels in dBA, also known as A-weighting. A-weighting �lter iscommonly used to emphasise frequencies around 3-6 kHz where the human ear ismost sensitive, while attenuating very high and very low frequencies to which theear is insensitive. The aim is to ensure that measured loudness corresponds wellwith subjectively perceived loudness [23]. A-frequency-weighting is mandated bythe international standard IEC 61672 to be �tted to all sound level meters [25].

Figure 2.3: Weighting curves in dB. A-wheighting (blue), B (yellow), C (red),and D-wheighting (black) [26].

2.3.2 Illuminance

There are studies indicating that light illuminance, light switching frequency, andlight exposure time in the workplace tend to have a big impact on the employeesproductivity and mood. These are also the variables that tend to distinguishDaylight from Arti�cial Light [27].

Daylight, as solar light, is relatively continuously distributed in light frequen-cies. Arti�cial Light sources such as a tungsten or halogen bulb, which use aheated metal to produce light, have also a relatively continuous spectrum acrossa limited range of frequencies [28]. But for example, the light peak from the


tungsten bulb is centered around longer wavelengths/lower frequencies than theDaylight distribution, and is yellower and of a lower colour temperature [28].

Arti�cial sources which excite phosphors with one wavelength of light to causethem to emit light at other wavelengths, produce light in a number of relativelysharp frequency peaks with gaps between with less or no light - the resultant"white" is a phantasm of the brain. These peaks of wavelength are arranged suchthat the eye and brain system combines them to produce "white" light. Thismethod is used on �uorescent lights, CFL (compact �uorescent), and PhosphorLEDs. Similar results occur when a gas is excited electrically or thermally soit emits light with sharply de�ned frequencies or when multiple mono-colouredLEDs are used.In terms of light frequency, on contrary to Daylight, some typesof Arti�cial Light such as incandescent light bulbs have a unperceived �ickering(at twice the 50Hz or 60Hz of the AC frequency) [28].

Even though this phantasm and �ickering cannot be perceived by the visionpart of our brain, some studies defend that Arti�cial Light has di�erent impactin the human body than day light has. On a study performed by the scientistMirjam Muench, it was concluded that "Compared to the afternoon, people whohad DL (Daylight) were signi�cantly more alert at the beginning of the evening,and subjects who were exposed to AL (Arti�cial Light) were signi�cantly sleepierat the end of the evening." [29]. This is related to the fact that our cortisollevels drop signi�cantly under arti�cial or poor lighting conditions [29] - a steroidhormone produced by the human body that's responsible for regulating varioushuman functions.

Also, according to various studies, arti�cial light with a strong blue componenta�ects human circadian cycles and the human hormonal system, which can resultin diseases ranging from sleep disorders to immune system disorders [30] [31].These results also suggest that higher colour temperature light increases the cen-tral nervous system activity [30] [31].

Illuminance can be measured in the lux SI unit - which consists in the luminous�ux per unit area. It is a measure of how much the incident light illuminates thesurface, wavelength-weighted by the luminosity function to correlate with humanbrightness perception [32].


Figure 2.4: The 1931 CIE photopic luminosity function. The horizontal axis iswavelength in nm. The vertical axis is the standard luminosity function (whichis dimensionless) [33].

The luminosity function, or luminous e�ciency function, describes the aver-age spectral sensitivity of human visual perception of brightness. It's based onsubjective judgments of which of a pair of di�erent coloured lights is brighter,to describe relative sensitivity to light of di�erent wavelengths. It should not beconsidered perfectly accurate in every case, but it is a very good representation ofvisual sensitivity of the human eye and it is valuable as a baseline for experimentalpurposes [32].

2.3.3 Telecommute

Telecommuting - also known as remote work - is a signi�cant workplace inno-vation that allows an increasing portion of employees to work from home orother location remote from the central workplace. This has become an increas-ingly common practice, with many employers allowing their employees to workremotely [34] [35].

Although telecommuting can blur the boundary between work and non-workactivities, it has bene�ts for both the telecommuter and their employer: im-proved productivity, job satisfaction, savings of o�ce space, increased �exibility,improved employee morale, and employee acquisition and retention [34] [35].

In part this is due to making it possible for employees to avoid potentiallystressful commutes, to the ability to choose to work at places that are quieter andmore interruption-free than their o�ces, and overall �exibility of choice [34] [35].

But it's not clear if telecommute has the same positive e�ects at every com-pany - how a�ects organisations' productivity, happiness, code quality, noise,


and other variables of the workplace. This can be achieved by registering theemployees telecommuting times, and crossing this information with other data.

Nowadays, there are di�erent forms of automating the functionality of theold punch card - a mechanical (or electronic) timepiece used to assist tracking ofthe hours worked by an employee. Some examples of automatic and frictionlessmethods to register employees presence at the o�ce are: NFC tags, computervision systems equipped with facial recognition, or by querying LAN/WLANnetwork for nearby devices.

NFC is is the set of protocols that enables smartphones and other devices toestablish radio communication with each other by touching the devices togetheror bringing them into proximity to a distance of typically 10 cm or less [36]. TheNFC tag system requires the implementation of a NFC reader at the o�ce, andgive each employee a NFC tag. The hardware is relatively inexpensive, but theadoption of such system requires the change of behaviour on every employee, byasking them to pass their NFC tag every time they enter and exit the o�ce.

Facial recognition through computer vision systems, at the level of identifyingeach individual is currently hard to build from ground up [37], making it neces-sary acquire the technology from third parties. This makes this option the leastfeasible.

The later option - query the network for nearby devices - is, in a world ofpersonal smartphones and personal computers, one of the most practical methodsof registering employees presence at the o�ce. This can be done using MACAddresses as a key for employee identi�cation.

MAC Addresses (Media Access Control Address) are unique identi�ers as-signed to network interfaces for communications on the physical network segment,used as a network address for most IEEE 802 network technologies, includingEthernet and WiFi [38].

2.3.4 Software Development Performance

Software development performance can be grouped into two main categories:subjective performance and objective performance. Subjective performance as-sessment can be de�ned as an evaluation method that re�ects the opinion ofthe people involved, and it's usually achieved through questionnaires to the in-volved individuals. In contrast, objective performance includes more quanti�ablemeasures such as cost, quality, productivity, predictability, and responsiveness,and can usually be automated to a certain extent. While subjective perfor-mance assessment has the advantage of easy data collection, it has di�cultieswith standardisation since the project evaluation is dependent on the person'sjudgment. [39] [40]

Examples of subjective KPIs [39] [40]:


• Process performance - a performance metric for the software developmentprocess that can be described by the (1) learning that occurs during thecourse of the project, (2) the degree to which management controls theproject, and (3) the quality of the interactions between the team and usersduring the development process.

• Product performance - a metric that captures the performance of the �n-ished product and can be described by the (1) technical performance of thesoftware, (2) the degree to which the software conforms to user needs, and(3) the degree to which the software is �exible in supporting new productsand changing user needs.

Each software organisation have their own engineering and management practices,with di�erent methodologies, tools, and levels of complexity. The measurementof software development performance needs to be adapted accordingly to eachorganisation's practices.

Examples of objective KPIs [41] [42]:

• Responsiveness - Based on the time a given step of task takes in the contextof the process. Ex: Time a bug takes to be �xed.

• Throughput - It can consist in the number of completed user stories, numberof added lines of code, or number of Git commits, in a given time period.

• Predictability - Based on throughput variability. (The standard deviationof throughput.)

• Costs - The money costs associated with the project development.

• Maturity - Based on the number of defects. The more defects the softwarehas, the less mature it is.

Because software development performance measurement have di�erent impli-cations to di�erent organisations, is often recommended using both subjective andobjective performance measures [39] [40]. Some reasons why using only objectivemeasurements may not work are [43] [44]:

• Some programmers can focus on hard problems and have little throughput,but deliver high value.

• Some programmers can produce much bug tracker tra�c by being exces-sively �ne-grained, and bring ine�ciency to the team.

• Some programmers may not produce much code, but spend a good portionof their time teaching and helping other team members.


• Some programmers may deliver numerous checklist points with tasks, butaggressively externalise much of the work.

• Some programmers may work fewer hours than their counterparts, but de-liver high throughput and value.

• Objective measurements may bring arguments about whether bugs arecaused by development or by poor quality analysis.

• Objective measurements may incentive developers to game the system (Ex:producing less code equals to a lower number of bugs).

• Objective measurements may incentive developers to avoid collaboration,since that's going to a�ect their personal results.

These issues can be clogged by doing both objective and subjective mea-surements, and by focusing the KPIs on the team instead of on the individual.Subjective measures help, for example, to understand the quality of the inter-actions inside the team, the impact of each individual on the project, and howvarious of the processes can be improved. By focusing on the teams instead ofon the individual, we discourage gaming the system on an individual level, andincentive collaboration [43] [44].

2.3.5 Happiness

Until recently, the concept of the happy-productive worker has often been rel-egated as an unsubstantiated claim made only by practitioners. In the recentyears, psychologists have addressed this topic, by realising a di�erent set of ex-periments which have showed evidence of the correlation of employees happinesswith their performance, and thus, companies' results. This is leading organisa-tions to recognise that the greatest competitive advantage in the modern economyis a positive and engaged workforce.

Isen and Reeve (2005) show that positive events induces subjects to changetheir allocation of time towards more interestingly challenging tasks, and despitethis, the subjects retain similar levels of performance in the less interesting tasks[45]. This suggests that individuals become better able to undertake repetitivetasks as they become happier.

More recently, on a study made by Andrew J. Oswald, Eugenio Proto, andDaniel Sgroi from the University of Warwick [46], it was performed three dif-ferent styles of experiment. Here, the randomly selected individuals that weremade happier, have approximately 12% greater productivity. They also foundthat those who had a solid reason to be unhappy, such as a recent bereavement,were less productive than their happier counterparts. They concluded that lowerhappiness is systematically associated with lower productivity.


Figure 2.5: Experiment II results from the research of Andrew J. Oswald, EugenioProto, and Daniel Sgroi, University of Warwick. Those exposed to the randomisedhappiness treatment in the laboratory have higher productivity. Uses the timedmathematical-additions task of Niederle and Vesterlund 2007. Here the happinesstreatment is a comedy movie clip in the laboratory. (95% con�dence intervals) [46]

Figure 2.6: Experiment IV results from the research of Andrew J. Oswald, Eu-genio Proto, and Daniel Sgroi, University of Warwick. Individuals with a recentBad Life Event (BLE) have lower productivity. Uses the timed mathematical-additions task of Niederle and Vesterlund 2007. Here a bad life event is bereave-ment or family illness. (95% con�dence intervals) [46]

There are a variety of methodologies to measure people's happiness. Most ofthem use multi-item happiness measures. Some tap into the cognitive componentof happiness (i.e., judgments of life satisfaction) and others assess the a�ective


component (i.e., the experience of frequent positive emotions and relatively infre-quent negative emotions). For example, the popular Satisfaction With Life Scalesurvey gets into the cognitive component by asking respondents �ve questionsabout their feelings regarding their lives (Ex: "In most ways my life is close tomy ideal."). While the A�ect Balance Scale survey gets into the a�ective compo-nent by inviting people to report how frequently they have experienced variouspositive and negative emotions over the last 30 days. [47]

The simplest method is a single item that has been posed to hundreds of thou-sands of representatively sampled people in many countries: "Taken all together,how would you say things are these days would you say you are very happy, prettyhappy, or not too happy?" [47].

These methodologies can be applied under di�erent sampling types - the threecommon types of sampling are event contingent, interval contingent, and signalcontingent. The event contingent is where the participant makes reports duringa certain type of event - for example, after committing code to git, or openingthe computer for the �rst time in the morning. Interval contingent is when theparticipant makes recordings at the end of large intervals, like at the end of theday. Signal contingent sampling is where participants get random prompts torecord data - this helps avoiding memory biases. [48]

The higher the frequency of the questionnaire, the more we need to take intoaccount its length and di�culty of answer input - questionnaires with a higherresponse time have lower response rate. This means that we not only need tochoose the few questions that can provide us with higher return of knowledge, butalso make sure the interaction with the questionnaire is the shortest and more�uid possible. [48]

2.3.6 Microservices Architecture

A software application can adopt di�erent architecture patterns. Service OrientedArchitecture and Microservices Architecture have been discussed and adoptedby several companies in the last decades, emerging as a reaction against thetraditional monolithic architecture. [49]

Monolithic Architecture

Monolithic architecture - a traditional approach to enterprise software - are singleapplications that package all the their server-side components into a single unit.Monolithic applications are single-programs with many responsibilities. [49] [50]

If we pick the example of an online store, the monolith app will have a compo-nent that manages the product catalog, a component that manages the customers'accounts, and other that manages the orders.


Figure 2.7: Example of a Monolithic application [50].

Monolithitic Architecture has advantages and disadvantages, which are de-scribed below. These can be better understood when put in perspective withSOA and MSA.

Advantages of the Monolithic Architecture are [49] [51] [52]:

• Ease of development, due to support from various IDEs.

• Ease of testing, due to dependency on only one application.

• Ease of deployment, due to dependency on only one application.

Disadvantages of the Monolithic Architecture are [49] [51] [52]:

• Harder to maintain, as all components are more coupled to each other.

• High cost of deployments, in the case of complex applications - a change ina single component requires the test, build, and deployment of the entireapplication.

• Di�culty in the adoption of new technologies - the trial and adoption ofnew technologies often requires rewriting the entire application.

Microservices Architecture

MSA emerged from SOA. [53] SOA is an architectural pattern in computersoftware design, where logical and business functions are partitioned into self-contained units of software that may list several discrete services/operations.These application components provide services to other components via a commu-nications protocol, typically over a network. The principles of service-orientationdesign stress the separation in units of software partitioned into operational ca-pabilities, each designed to solve an individual concern - these units qualify asservices. [53] [54]

Although no industry standards exist to de�ne what composes an SOA, someprinciples are widely accepted as the core of what SOA represents. For example,Microsoft's Don Box "four tenets of service-orientation" are [55]:


• Boundaries are explicit

• Services are autonomous

• Services share schema and contract, not class

• Service compatibility is based on policy

SOA surged with the promise to include increased return on investment, or-ganisational agility and interoperability as well as a better alignment betweenbusiness and IT. It builds heavily on earlier design paradigms and enhances themwith standardisation, loose coupling, and business involvement [55].

But due to the inconsistent application of the SOA term by IT product ven-dors, the SOA concept gained di�erent meanings for di�erent people, and thustranslating into di�erent practices when applying this architecture pattern [56].This common manifestation of SOA has led some advocates to create MSA - aterm that more crisply de�nes this architectural style. For some advocates, MSAis very distinct from SOA, making them reject the SOA label entirely. Othersconsider microservices to be a specialization of SOA, or even the correct imple-mentation of SOA. [49] Well known sites such as eBay, Amazon.com, Groupon,and Net�ix have been evolving from a monolithic architecture to MSA [50].

MSA can be de�ned as an approach for developing a single application asa suite of small services, each running in its own process and communicatingwith lightweight mechanisms, often an HTTP resource API. These services arebuilt around business capabilities and should be independently deployable byfully automated deployment machinery. There is a bare minimum of centralizedmanagement of these services, which may be written in di�erent programminglanguages use di�erent data storage technologies. [50]

As we see, SOA and MSA are very similar in various ways. But MSA contrastswith SOA on parts such as: the used communication mechanisms; the practiceof automatic deploys, and; the use of di�erent, non-proprietary, technologies foreach service. MSA also tends to di�erentiate from SOA in the size of each service- MSA's services are typically more partitioned, and thus smaller, than SOA'sservices. [57] [53] [58]


Figure 2.8: Example of a MSA-based application [50].

On the following paragraphs, some of the represented facts can be applied toboth SOA and MSA, but for a question of abstraction, we will refer only to MSA.

Figure 2.8 represents the architecture of the example application, in the casewe apply MSA. The represented application includes exactly the same logicalservices as the original monolith.

CommunicationWhile in a monolithic application components call one another via regular

method calls, in a MSA di�erent services run in di�erent processes. Consequently,services must use an inter-process communication (IPC) to communicate. Syn-chronous or asynchronous communication can be used. Responses are typicallyreturned in HTML/JSON/XML format [52].

Synchronous communication can be done through a HTTP-based mechanism,usually REST. This is easy to implement, and it's �rewall friendly so it worksacross the Internet. The drawbacks of HTTP are that it doesn't support otherpatterns of communication such as publish-subscribe; both the client and theserver must be simultaneously available, which is not always the case since dis-tributed systems are prone to partial failures; and, the HTTP client needs toknow the host and the port of the server, which is not trivial in cloud deploy-ment that uses auto-scaling. The later can be solved by using a service discoverymechanism, such as Apache ZooKeeper or Net�ix Eureka. [50]

Asynchronous message-based mechanism can be achieved for example througha AMQP-based message broker - an open standard application layer protocol formessage-oriented middleware. The message broker bu�ers the messages until theconsumer is able to process them, making the producers totally unaware of theconsumers - they can just send it into a message bus and possibly, in one moment


in time, a service can start listening. This makes a service discovery mechanismnot necessary. One of the drawbacks is the fact that we are adding anothercomponent to the system and thus adding complexity. [50]

Figure 2.9: Example of communications between microservices [52].

Another issue in MSA communication, is the fact that often - for example fordisplaying a web page - a large number of calls to the di�erent services is required.This is ine�cient and results in a poor user experience. When this happens, anAPI gateway can be introduced. The API gateway will be responsible to handlethe communication between the client and the services, by proxying or aggre-gating requests, and by using a cache mechanism. This way, the communicatione�ciency is optimized, and the details of the microservices are encapsulated with-out impacting the clients - for example, two microservices might be merged, andother microservice might be partitioned into two or more services, with only theAPI gateway needing to be updated to re�ect these changes. [50]

Monit and MetricsIn MSA speci�cally, proper monitoring is critical, as parts of the system can

fail without clear and immediate evidence. We have to ensure that all processesstay up, don't run out of disk space, don't deadlock, and stay performant. Thereare several tools on the market, such as Sentry8 and Logentries9, that can providethat information. [52]

Advantages of the Microservice Architecture are [50] [52] [49] [59][51]:

• Maintainability - Since every code base maintains a reduced amount oflogic, it is easier to understand the code base and correct the �aws in theexisting functionality. Loose coupling also contributes to this aspect sincea) modi�cations to their code base have low or no impact to the remaining

8https://getsentry.com/9https://logentries.com/


Figure 2.10: By using the API Gateway, �ne-grained requests from a desktopclient are simply proxied to the corresponding service, whereas each coarse-grained request from a mobile client is handled by aggregating the results ofcalling multiple services [50].

services; and b) development can be organized around multiple small teams,with each team responsible for a single service or a collection of relatedservices that can be developed, deployed and scaled independently of all ofthe other teams.

• Extensibility - Which is related to the Maintainability of the system. Pro-moting loose coupling between services and high cohesion per service al-lows its extension to be performed without impacting the existing systemfunctionality, either by creating a new service (which bene�ts from loosecoupling) or by extending the functionality of an already existing service(which bene�ts from high cohesion).

• Scalability - Each service can be deployed independently of other services.Horizontal scalability becomes possible on a per-service basis, meaning thatit is possible to run more instances of the services that need more resources,while running fewer instances of the services that have a reduced resourceconsumption. Vertical scalability comes from delegating the state data man-agement to an external service, reducing the amount of consumed resourcesper interaction.

• Ease of deployment of new versions of services - Each service can be deployedindependently of other services on a frequent basis.


• Fault Isolation - A problem in one service tends to a�ect only that serviceand the actions related with it. Other services will continue to handle non-related requests normally. In comparison, the monolithic architecture has asingle point of failure, where an error can bring the entire application down.

• Ease of adoption of new technologies - When developing a new service, it'spossible to choose the most adequate technology to best deliver the businesscase. Plus, due to the small code base, it tends to be practical to rewritethe service using the new technology.

Disadvantages of the Microservice Architecture are [50] [52] [49] [59][51]:

• Distributed system complexity - While the code bases of each service areeasier to understand and maintain, how the whole application is distributedand communicates gains a di�erent level of complexity. Once we have a dis-tributed system, we have to consider a whole host of concerns that we didn'tbefore - network latency, fault tolerance, message serialisation, unreliablenetworks, asynchronicity, versioning, varying loads within our applicationtiers etc. To absorb this impact, a high-level of automation of applicationdeployments and cloud management is necessary.

• Operational overhead - Where a monolithic application might have beendeployed to a small application server cluster, we now have tens of sepa-rate services to build, test, deploy and run, potentially in a polyglot set oflanguages and environments.

• Increased memory consumption - The microservices architecture replacesN monolithic application instances with NxM services instances. If eachservice runs in its own VM (or equivalent), which is usually necessary toisolate the instances, then there is the overhead of M times as many VMruntimes.

Application Scalability

Applications can be scaled using di�erent practices. In the book The Art ofScalability, a three dimension scalability model is used to represent these - thescale cube [50].

The X-axis represents the approach of scaling an application by running mul-tiple identical copies behind a load balancer.

The Z-axis, similarly to the X-axis, represents the scaling with server thatreplicate the code, with the major di�erence that each server is responsible foronly a subset of the data (Ex: payment, orders, products). A component in thesystem is responsible to route each request to the appropriate server.


Figure 2.11: Three dimension scale cube [50].

The Y-axis represents scaling in terms of functional decomposition. Here,the application is split into various services, each one responsible for a di�erentfunctionality (as products, orders, payments).

While Monolithic applications are usually scaled through the X-axis, and insome case through the Z-axis, a MSA application scales through the Y-axis.

Adopting a microservice architecture should not be undertaken lightly - aswe seen, there are several advantages and disadvantages. When developing the�rst version of an application, often we do not have the problems that the MSAapproach solves. Some practitioners defend that applications should �rst be de-veloped using a Monolithic approach, being MSA adopted at a later stage - itgets the development faster, and it lowers the costs of making boundaries' errorsor changes. Others defend the adoption of the MSA approach at the beginningof the application's life - not only because the later our application adopts MSAthe more di�cult the process is going to be, but also because there are otheradvantages of MSA, such as the ability to use di�erent technologies that best suitthe responsibility of the di�erent services. [50] [60]

However at which stage MSA is adopted, for applications that need to scale,it is usually the right choice [50]. It's usually the right choice if, on complexapplications, we want that new team members to quickly become productive, ifthe application must be easy to understand and modify, if we want to practicecontinuous deployment, and if we want to take advantage of the emerging tech-nologies (frameworks, programming languages, etc) [51]. In sum, MSA o�ers aclearer and better de�ned approach on setting up an architecture built aroundservices, with the promise of providing better agility, return of investment, inter-operability, and better alignment between business and IT, to the organisation


which the application �ts into.

2.3.7 Internet of Things

The Internet of Things (IoT) is the highly distributed network of physical objectsor "things" embedded with electronics, software, sensors, and connectivity toenable objects to exchange data with human beings or connected devices withoutrequiring human-to-human or human-to-computer interaction. IoT has evolvedfrom the convergence of wireless technologies, micro-electromechanical systems(MEMS) and the Internet. The connection of physical things to the Internetmakes it possible to access remote sensor data, giving the ability to measure,infer, and understand environmental indicators, and to control the physical worldfrom a distance. The mash-up of captured data with data retrieved from othersources, gives rise to new synergistic services that go beyond the services thatcan be provided by an isolated embedded system. [61]

IoT is opening tremendous opportunities for a large number of novel applica-tions that promise to improve the quality of our lives. Applications of IoT rangefrom various �elds and systems such as [62]:

• Internet connected cars;

• Wearable devices including health and �tness monitoring devices, watches,and even human implanted devices;

• Smart meters;

• Home automation systems and lighting controls;

• Smartphones which are increasing being used to measure the world aroundthem; and

• Wireless sensor networks that measuring weather, �ood defenses, tides andmore.

The the number and variety of devices that are collecting data is inscreasingrapidly. A study by Cisco estimates that in 2010 the number of Internet-connecteddevices exceeded the human population, and that by 2020 there will be 50 billionInternet-connected devices [62].

Attributes

IoT systems must take into account di�erent attributes. Many of these emergefrom the limited form-factors and power available to IoT devices, others comefrom the way in which IoT devices are manufactured and used. They can bedivided in the following categories [61] [63]:


• Cost-e�ectiveness - Determined by the a�ordability of the system.

• E�ciency - Described in terms of power and data management of the dif-ferent devices connected to the system.

• Quality of Service (QoS) - A performance management technique for theprioritization of di�erent data tra�c from devices - heterogeneous smart de-vices with limited bu�er capacity need e�ective bu�er management schemeand di�erentiated service priorities to provide preferential treatment to de-lay sensitive tra�c.

• Connectivity and communications - De�ned by how each device communi-cates and is connected to other devices and network - from communicationprotocols to the system architecture.

• Scalability - The ability to scale from a small deployment to a very largenumber of devices, and the ability to scale the server-side out on small cheapservers.

• Manageability - While many IoT devices are not actively managed, this isnot necessarily ideal. In many cases it should be possible to perform remoteactions such as disconnecting devices, update the software, and enabling ordisabling certain hardware capabilities.

• Security and Privacy - De�ned by how immune the architecture is to outsideattacks. It integrates various issues such as authentication, encryption, etc.

Architecture and Communications

The Internet of Things domain encompasses an extremely wide range of tech-nologies, from stateless to stateful, from extremely constrained to unconstrained,from hard real time to soft real time. The communication among these devicesas well as with related services, it is frequently done in a wireless, autonomic andad-hoc manner, and is expected to happen anytime, anywhere. In addition theservices become much more �uid, decentralized and complex. [64] Architecture inthis context is de�ned as a framework for the speci�cation of a network's physicalcomponents and their functional organization and con�guration, its operationalprinciples and procedures, as well as data formats used in its operation. [64]

The communications between devices and the Internet or to a gateway includemany di�erent models [62]:

• Direct Ethernet or Wi-Fi connectivity using TCP or UDP

• Bluetooth Low Energy

• Near Field Communication (NFC)


• Zigbee or other mesh radio networks

• UART or serial lines

• SPI or I2C wired buses

Figure 2.12: IoT communication options.

There are multiple potential protocols for communication between the devicesand the cloud. The three most well known potential protocols are [62]:

• HTTP/HTTPS (and RESTful approaches on those)

• MQTT

• Constrained Application Protocol (CoAP)

HTTP is well known, with many libraries that supporting it. Because it isa simple text-based protocol, many small devices such as 8-bit controllers canpartially support the protocol. The larger 32-bit based devices can utilize fullHTTP client libraries that properly implement the whole protocol. Communica-tions based on HTTP are ine�cient and costly - both in terms of network tra�cas well as power requirements. [62]

MQTT is a publish-subscribe messaging system based on a broker model.It was invented in 1999 to solve issues in embedded systems and SCADA. Theprotocol has a very small overhead (as little as 2 bytes per message), and wasdesigned to support lossy and intermittently connected networks. MQTT wasdesigned to �ow over TCP.One important aspect with IoT devices is not just forthe device to send data to the cloud/server, but also the reverse. This is one ofthe bene�ts of the MQTT speci�cation: because it is a brokered model, clients


connect an outbound connection to the broker, whether or not the device is actingas a publisher or subscriber. This usually avoids �rewall problems, because thisapproach works even behind �rewalls or via NAT. [62]

The Constrained Application Protocol (CoAP) is a protocol from the IETFthat is designed to provide a RESTful application protocol modeled on HTTPsemantics, but with a much smaller footprint and a binary rather than text-based approach. CoAP is a more traditional client-server approach rather than abrokered approach. CoAP is designed to be used over UDP. CoAP has a narrowadoption, and has a less simpler connectivity over �rewalls and NAT networks,when compared with MQTT and HTTP. [62]

Internet of Things technology appear complex for variety of reasons. Thereis legitimate heterogeneity in the used networking technology and applications.This variation is necessary and useful, as for instance di�erent applications andenvironments bene�t from varying networking technology. The range and othercharacteristics of cellular, wireless local area networking, and RFID are verydi�erent from each other, for instance. There are literally thousands of di�erentapplications, and it is natural that they have di�ering requirements on whatparties need to communicate with each other, what kind of security solutions areappropriate, and other aspects. [65]

Thus, a single reference architecture cannot be used as for all possible concreteimplementations. While a reference model can probably be identi�ed, it is likelythat several reference architectures will co-exist in the Internet of Things [64]. Ser-vice Oriented Architectures are a promising approach for building systems giventhese boundary conditions, because they provide a high level of abstraction thatallows to safely hide hardware speci�c details from the developer and to integratecomponents from di�erent vendors [62]. The IoT architecture, like the Internet,will grow in evolutionary fashion from a variety of separate contributions, ratherthan from a grand plan [64].

Chapter 3

The Platform

In this chapter the platform components and architecture are presented. It shouldbe recalled that the goal for this project is to build a platform for the quanti�ca-tion of SMEs' workplaces on an ongoing basis, through a Microservices Architec-ture. The platform needs to be modular, so that it provides ease of integrationwith other services and devices, and thus facilitate the quanti�cation of other vari-ables. The chapter starts by presenting the overall system structure, followingwith a description of each component.

3.1 Architecture Overview

The platform is composed of various components, which are divided in 5 maincategories: Data sources, Data Processing Microservices, Company Info Microser-vices, Data Storage, and Dashboard.

• Data Sources are third-party services (Ex: project management tools), orsensors from IoT devices installed at the workplace (Ex: luminosity sensors).

• Data Processing Microservices are the microservices built with the purposeof processing the received raw data from each data source, and storing theprocessed data on the adequate databases. There are Data Processing Ser-vices which are installed in servers located in the cloud, and others installedin devices located in the o�ce.

• Company Info Microservices were built with the goal of centralising themeaningful data relative to projects and employees. These are frequentlyqueried by other services to adequately identify to which project or userbelongs the correspondent packet of raw data. They both have a userinterface for easy manual data input.

• Data Storage, which consist in two databases, each one with characteristicsthat make them suitable for a speci�c purpose.

51

52 CHAPTER 3. THE PLATFORM

• Data Visualisation, which consists in a Dashboard or visualisation of mean-ingful insights that are a result from processed data.

The Data Processing Microservices, Company Info Microservices, Data Visu-alisation, and part of the Data Sources (sensors), were components built duringthis project. The Data Storage, and the other part of the Data Sources (Third-party Services) already existed before this project.

An overview of the architecture and how each component connects with eachother can be seen in �gure 3.1.

Figure 3.1: Architecture overview. The blue boxes represent the services builtfor this project, and the green boxes represent third party services. The arrowsrepresent the data �ow.

3.2 Components

3.2.1 Data Storage

Aqora

Aqora is a time-series event database, which permits the storage of �oat numericvalues relative to a stream. Each stream corresponds to a variable that tends tooscillate with time.

3.2. COMPONENTS 53

This platform is specially built for the storage of high-frequency time-seriesevents (i.e. every few seconds or minutes), such as temperature or electricityconsumption.

This platform was built by Whitesmith, previously to this project.

Keen IO

Keen IO1 is a time-series event platform, which permits the storage and analysisof various types of data. The event payload can include data in the form of �oat,integer, string, boolean, or array.

Keen IO has a powerful built in analysis and visualisation tools, which permitsthe fast and easy retrieval of some analytics - count, average, sum, etc - aboutthe collected data without the need of processing from our side. For example,Keen IO permits retrieval of the average happiness levels per day, or number ofresponses per month, through its query API.

Keen IO is best suited for low frequency events (i.e. minutely, hourly, andup).

3.2.2 Company Info Services

Projeqts

A platform built with the purpose of centralising the information relative to eachcompany project - Whitesmith is a software development company, meaning thateach project corresponds to a product or service in this area. Every project has itsown Projeqt ID, which serves as the identi�cation key on every company service.

Every time a new project is started at the company, a new project entry iscreated on Projeqts using a manual form. Relevant data such as Name, Descrip-tion, Github repository ID, and Active or Inactive status, is introduced in eachproject entry. This data is then used by other services.

Quem

A platform built with the purpose of centralising the information relative to eachemployee. Every project has its own Quem ID, which serves as the identi�cationkey on every company service.

Every time a new employee starts working at the company, a new employeeentry is created on Quem using a manual form. Relevant data such as Name,Description, Github repository ID and Active or Inactive status, is introduced ineach project entry. This data is then used by other services.

1http://keen.io


3.2.3 Data Sources

Trello

Trello2 is a software administrative tool for project management.Each project has its own Trello board. The building blocks of Trello boards

are lists and cards - each card corresponds to a task, and each list corresponds toa state of a card.

Figure 3.2: Example of a Trello Board with Trello Lists and Cards.

Cards are moved through Lists according to their state - through a �ow thattends to be from left to right. For example, cards in the "In Progress" list arecurrently being tackled by the team. Cards in the "Live" list are �nished.

Each card has other information attached besides the name, such as descrip-tion, comments, labels, and people assigned to the card.

Slack

Slack3 is the software communications platform used at Whitesmith.Each employee has its own Slack user account, and each project has its own

Slack group where discussions are performed. Slack also permits users or bots tocommunicate directly to other users.

2http://trello.com3http://slack.com

3.2. COMPONENTS 55

Github

Github4 is one of the most used Git repository hosting services, and the oneused at Whitesmith. Git is a distributed revision control system used in softwareprogramming.

Each project has one or various Github repositories, to which employees cancontribute.

Google Calendar

Google Calendar5 is an online calendar that can be shared with various people.Whitesmith has a Google Calendar directed to company events.

Mike Sensor

Mike measures the sound levels in the o�ce. Mike's sensor is a microphone, built-in a Logitech C270 webcam, that's connected to a Raspberry Pi. It's part of adevice installed at the o�ce.

Quantum Sensor

Quantum measures the illuminance at the o�ce. Quantum's sensor is AdafruitTSL2561 photodiode digital sensor, which is connected to a RaspberryPi. It'spart of a device installed at the o�ce.

Presence Sensor

Presence quanti�es employees attendance at the o�ce (non-telecommuting em-ployees). Is built with a RaspberryPi that queries the local network for currentlyconnected MAC addresses. It's part of a device installed at the o�ce.

3.2.4 Data Processing Services

Mike Processor

Mike processor is responsible to capture the microphone readings, calculate thesound RMS Amplitude, and send those values to Aqora.

Mike processor is also responsible to process stored data on Aqora, returningmetrics that are then stored on Keen IO (Ex: hourly RMS Amplitude average).

w

4http://github.com5http://google.com/calendar


Figure 3.3: Mike scheme, with data �ow represented by arrows.

Quantum Processor

Quantum processor is responsible to capture the Adafratuit TSL2561 photodi-ode's readings, convert those values to lux, and send them to Aqora.

Quantum processor is also responsible to process stored data on Aqora, re-turning metrics that are then stored on Keen IO (Ex: hourly lux average).

Figure 3.4: Quantum scheme, with data �ow represented by arrows.

Presence Processor

Presence processor is responsible to capture the list of MAC Addresses present onthe o�ce's network, identify to which employee belongs the correspondent MACAddress, and send that information to Keen IO.

Presence also communicates with Quem to match the returned list of MacAddresses with the company's employees.

Qalendar

Registers company events scheduled on the company's Google Calendar.Qalendar communicates with Google Calendar to gather the data relative to

the calendar's previous events. The processed data is then sent to Keen IO.All the data relative to the calendar's event can be retrieved through Google

Calendar's API.

3.2. COMPONENTS 57

Figure 3.5: Presence scheme, with data �ow represented by arrows.

Figure 3.6: Qalendar scheme, with data �ow represented by arrows.

Trello Quanti�er

Quanti�es activity on each Trello board correspondent to projects occurring atWhitesmith. Trello Quanti�er collects and stores this data with the goal of mea-suring throughput, responsiveness, and other metrics in the future.

Trello Quanti�er receives data from Trello about every activity occurring atthe company's Trello boards. Trello Quanti�er also communicates with Quem andProjects to match the received activity data with the correspondent employee andproject. If the event is relevant, the processed data is then sent to Keen IO.

Trello Quanti�er is also responsible to perform more complex calculations thatcannot be retrieved from Keen IO, such as responsiveness.

Figure 3.7: Trello Quanti�er scheme, with data �ow represented by arrows.

All the card's data is sent on every event that comes from Trello's Webhooks.


Github Processor

Quanti�es each Github repository that belongs to the organisation, such as thenumber of lines of code added and deleted, and the number of new commits.

Github Quanti�er communicates with Github to gather the statistics relativeto each employee and Github repository. Similarly to Trello Quanti�er, GithubQuanti�er also communicates with Quem and Projects to match the receivedGithub data with the correspondent employee and project. The processed datais then sent to Keen IO.

Figure 3.8: Github Quanti�er scheme, with data �ow represented by arrows.

Shrinq

Quanti�es the level of happiness, by querying every employee through it's softwarecommunication platform - Slack.

Shrink communicates with Slack to send the survey questions to each em-ployee, and receive the correspondent answers. Shrink communicates with Quemto match the received Slack data with the correspondent employee, and with Pres-ence to acknowledge the employees telecommuting status for the current day. Theprocessed data is then sent to Keen IO.

3.2.5 Data Visualisation

Dashboard

The Dashboard is the central point for the representation of the insights extractedfrom the processed data. The Dashboard is accessible by every employee.

The metrics are divided in three main categories:

• Happiness - Metrics relative to employees happiness.

3.2. COMPONENTS 59

Figure 3.9: Shrinq scheme, with data �ow represented by arrows.

• Productivity - Metrics relative to Github and Trello.

• O�ce Environment - Metrics relative to the o�ce environment, such asnoise, illuminance, events, and telecommuting status.

It was not expected for the Dashboard to be rich of insights by the end of thisMaster Thesis - data analysis will be performed by intersecting data from variousdata sources (Ex: productivity vs telecommuting status), which we preferred tofocus on later after this project. Anyhow, the visualisation of retrieved data alongthe development of this project helped steer the right direction for the type ofmetrics to collect and process, and assure the quality of the collected data.

Chapter 4

Implementation

In this chapter we describe the implementation of this platform in more detail.From the languages and frameworks used for this project, to every componentthat was built during the course of this Master Thesis. These include: Data Pro-cessing Microservices, Company Info Microservices, and part of the Data Sources(sensors). In this chapter, Data Sources are described in the same section of thecorrespondent Data Processing Microservice - this applies to Mike, Quantum,and Presence.

4.1 Languages and Frameworks

In this project, di�erent languages and frameworks are used. Cloud-based mi-croservices use Ruby over the Sinatra framework, and Ruby on Rails. Microser-vices built on devices use Python. These languages and frameworks were chosenmostly because of velocity of development on each platform.

4.2 Cloud Hosting

With the exception of the case microservices built on devices, the services usedin this project are hosted on the cloud - both �rst and third-party services. Eachof the �rst-party services are hosted in an individual container server at Heroku- a PaaS cloud hosting service, which stands above the infrastructure of AmazonEC2. The cloud enables the ease of deployment of new microservices, and easeof integration with other services and devices - it gives the system modularity. Italso enables a quick response to performance demand, by e�ortlessly scaling upand down the server instances, thus making it easier to adapt to the company'sneeds in terms of data processing.

61

62 CHAPTER 4. IMPLEMENTATION

4.3 Error Logging and System Logging

Every service performs error logging using Sentry1 - an exceptions data loggerhosted on the cloud. Email alerts are sent every time an error occurs on one ofthe microservices.

Some microservices perform system logging using Logentries2 - a system mon-itoring data logger and analytics hosted on the cloud.

Both of them serve the purpose of general system information and aid duringthe system analysis and debugging.

4.4 Communication

Every service with each other through Hypertext Transfer Protocol (HTTP) -an application-level protocol that is generic, stateless and object oriented, pro-viding a light and fast solution for communication in distributed, collaborativeinformation systems [50].

We use the Representational Status Transfer pattern (REST) - the most com-mon solution for web applications to provide data, due to its simplicity and focuson data state. It provides a powerful but simple tool for integration betweensystems. The used format in the system communications is always json.

Data can be collected either on the instant the event data is created on itsData Source, or at a later instant:

• Some metrics are collected through HTTP POST requests performed byData Sources to the correspondent Processors, at the same instant that thedata is created on the Data Source. This data is immediately processed andsent to its Data Storage platform, as it's received by the Data ProcessingMicroservices.

• Other metrics are collected using background jobs - also called workers -scheduled on its Data Processing Microservices to, on a de�ned frequency,perform HTTP GET requests to the Data Source. This data is immediatelyprocessed and sent to its Data Storage platform.

4.5 Workers

Workers serve the purpose of collecting and processing data on a de�ned fre-quency. On this project, workers are used for collecting and processing batchesof data for situations where it cannot be performed in real-time.

In this project, workers are performed with:

1http://getsentry.com2https://logentries.com/

4.6. COMPONENTS 63

• Heroku Scheduler - an add-on at our hosting provider that allows schedulingof rake tasks.

• Cron - a time-based scheduler used in Unix-like computer operating systemsas Raspbian, the OS installed in our devices.

4.6 Components

4.6.1 Data Processing Microservices and Data Sources

Mike

Mike consists in a data logger device built with a Raspberry Pi and a microphone.The Raspberry Pi has installed Raspbian OS - a Linux based OS - with

PyAudio library. PyAudio provides Python bindings for PortAudio - a cross-platform audio I/O library - for access of the microphone readings of the RMSamplitude.

Mike's microphone has a frequency response from 20Hz to 20 kHz - whichcorresponds to the human hearing range - and it's connected to the RaspberryPi through a USB connection. No type of weight �lter is applied to Mike - as forexample A-Weighting, which would account for the relative loudness perceivedby the human ear. The microphone produces a voltage which is proportional tothe sound pressure. Mike collects this values and calculates the RMS amplitude.

RMS amplitude is de�ned as the square root of the mean of the square of theinstantaneous sound amplitude.

Xrms =2

√1

n(x2

1 + x22 + ...+ x2

n) (4.1)

RMS amplitude vary with the distance from the sound origin - there is adrop of 6 dB per doubling of distance. There are no standards for measuringsound levels. In the case of ambient environmental measurements of backgroundnoise, distance is usually not quoted as no single source is present. In the case ofWhitesmith's o�ce - which has 52 square meters - the farthest that a sound canbe originated from the microphone is approximately 8.4 meters.

As described in the previous chapter, Mike stores data in both Aqora andKeen IO:

Aqora is used for storage of the instantaneous RMS amplitude readings, whichare performed every 0.5 seconds and immediately sent to the database. Thefrequency of every 0.5 seconds is high enough to perform an adequate analysis ofthe ambient sound levels at the o�ce, without exceeding Aqora's storage capacityin the mid-term, or the Raspberry Pi's processing power.

Keen IO is used for storage of hourly RMS amplitude averages, which arecalculated every hour, by processing data on Aqora relative to the previous hour.



Figure 4.2: Mike scheme, with data �ow represented by arrows.

Quantum

Quantum consists in a data logger device built with a Raspberry Pi and a AdafruitTSL2561 digital sensor.

The Raspberry Pi has installed Raspbian OS - a Linux based OS - and alibrary speci�cally calibrated for this sensor, for access to the lux readings.

The Adafruit TSL2561 sensor contains both infrared and full spectrum diodes.Adafruit TSL2561 has a dynamic range from 0.1 to 40,000 lux. The draw ofelectricity current is extremely low - about 0.5mA when actively sensing - makingit very suitable for low power data-logging systems [66]. Adafruit TSL2561 sensoris connected to the Rasperry Pi through I2C interface.

4.6. COMPONENTS 65

Figure 4.3: Adafruit TSL2561 spectral responsivity diagram [66].

Quantum is mounted in the middle of one of the walls of Whitesmith's o�ce.Quantum also stores data in both Aqora and Keen IO:


Aqora is used for storage of the instantaneous lux readings, which are per-formed every 1 second and immediately sent to the database. The frequency ofevery 1 second is high enough to perform an adequate analysis of the ambientilluminance levels at the o�ce, without exceeding Aqora's storage capacity in themid-term, or the Raspberry Pi's processing power.

Keen IO is used for storage of hourly lux averages, which are calculated everyhour, by processing data on Aqora relative to the previous hour.

Presence

Presence consists in a data logger device built with a Raspberry Pi.The Raspberry Pi has installed Raspbian OS - a Linux based OS. A script

makes use of Nmap (Network Mapper) - a security scanner used to discover hostsand services on a computer network, thus creating a "map" of the network [67].


Through Nmap, Presence captures the MAC Addresses that are currentlyconnected to the o�ce's network.

Immediately next to receiving the list of MAC Addresses, Presence queriesQuem to acknowledge to which employee belongs the correspondent MAC Ad-dress. For every employee at the o�ce, an event with its Quem ID is sent to KeenIO.

A worker executes this process every 15 minutes, giving us reasonable granu-larity to measure employees telecommuting status.

Figure 4.5: Presence scheme, with data �ow represented by arrows.

Qalendar

Qalendar is hosted on the cloud, at Heroku's platform. It's built using Rubylanguage, over the Sinatra framework.

Qalendar communicates with Google Calendar to query the events on White-smith's calendar. The retrieved data includes the event's description, place, anddate.

A worker executes this process every day, to query and process the calendarevents from the previous day. This data is immediately sent to Keen IO.

The frequency of querying data every day permits the registration of eventsrapidly enough for analysis and comparison with other metrics (Ex: noise at theo�ce), and at the same time guaranteeing that the event has been scheduled onthe calendar previously to the calendar event.

Figure 4.6: Qalendar scheme, with data �ow represented by arrows.

4.6. COMPONENTS 67

Github Quanti�er

Github Quanti�er is hosted on the cloud, at Heroku's platform. It's built usingRuby language, over the Sinatra framework.

Github Quanti�er communicates with Github to query weekly developmentstatistics relative to each user on each repository. The retrieved data includesnumber of commits, number of lines of code added, number of lines of codedeleted.

For each user's statistics received from Github, Github Quanti�er queriesQuem and Projeqts to acknowledge the Quem ID and Projects ID to which thestatistics belong, respectively. The collected and processed data is immediatelysent to Keen IO.

A worker executes this process every week - the same frequency that thesestats are created and provided by Github.

Figure 4.7: Github Quanti�er scheme, with data �ow represented by arrows.

Shrinq

Shrinq is hosted on the cloud, at Heroku's platform. It's built using Ruby lan-guage, over the Sinatra framework.

Shrinq uses the interval sampling method - is programmed to survey employeesevery day, at the hour preferred by each employee. Shrinq's questions tap intothe cognitive component.

Shrinq was built to make the user experience as simple and �uid as possible,with the goal of increasing the response rate. This way, Shrinq makes a lownumber of simple questions.

For the �rst question we use the most asked question in happiness surveys:"How happy are you today?" The following two questions have the purpose of


better understanding the answer to the �rst: "What was the main reason?";"What is blocking you from doing your work? What suggestions do you have tomake it something better (project, company, etc)?".

Question 1 has three possible answers, values of which range from 1 to 3:

Figure 4.8: Shrinq question 1.

The =( smile corresponds to 1, the =| smile to 2, and the =) smile to 3. Thequestion can be easily and rapidly answered by clicking on the desired option.

The second is also a multiple choice question that users can answer with aclick.


The third is an open answer question, where employees can write down theirthoughts in a more expressive manner. This answer is useful to acknowledgeinformation that is not possible to express on the previous two multiple-choicequestions.

4.6. COMPONENTS 69


For every answer given by each employee, Shrinq communicates with Quemto query the Quem ID of the correspondent employee's Slack account, and withPresence to acknowledge if this employee was telecommuting on the present day.After having this information, an event with the employee's answer, Quem ID,and telecommuting status, is sent to Keen IO.

A worker executes this process every day, at the hour preferred by the em-ployee. This hour is also de�ned on Quem. In case a employee doesn't answerthe survey on the preferred hour, the employee will be again surveyed three hoursafter, also with the goal of increasing response rate.

Figure 4.11: Shrinq scheme, with data �ow represented by arrows.

Trello Quanti�er

Trello Quanti�er is hosted on the cloud, at Heroku's platform. It's built usingRuby language, over the Sinatra framework. Trello Quanti�er analyses activityon each Trello board correspondent to projects occurring at Whitesmith.

Trello Quanti�er has the goal of measuring Throughput, Maturity, and Re-sponsiveness:

• Throughput is based on the number of completed Tasks. Tasks are donewhen its correspondent Card is moved to a Live list on Trello.


• Maturity is based on the number of defects found in the software. For eachdefect found, a card is created on the Bugs list. The more found defects,the lower is the level of maturity of the software.

• Responsiveness, which consists in:

� Number of tasks completed per week.

� The average time per week that tasks from starting until they're con-cluded. (Average Time to Market)

� The average time per week that tasks from starting until they moveto the next List (list which corresponds to the Task state). (AverageTime to Next List)

Trello communicates with Trello Quanti�er using a technology called Web-hooks - user-de�ned HTTP callbacks, which are triggered whenever there is ac-tivity on a Trello board.

When a HTTP callback is received, Trello Quanti�er will �rstly verify if theactivity is relevant - if a new Card was created, or moved to a di�erent List.

In case the data is relevant, Trello Quanti�er will communicated with Quemand Projeqts to acknowledge to which employees the Card is assigned to, and towhich company Project it belongs. After processing, the information is immedi-ately sent to Keen IO. This permits us gather the number of done tasks, whichare used display the throughput and number of completed tasks per week.

To quantify the Average Time to Market, and Average Time to Next List,Trello Quanti�er needs to process the information stored on Keen IO. It does itby gathering from Keen IO the cards information belonging to each Project, andexecute the following calculations:

• Time taken from the current list to the next, in days

• Time taken from the Next Up list to the Live list, in days.

Finishing with the weekly average for each project.Both processes can be visualised in 4.12.

4.6.2 Company Info Microservices

Quem

Quem is hosted on the cloud, at Heroku's platform. It's built using Ruby lan-guage, over the Ruby on Rails framework.

For every new employee at the company, a new employee entry is created onQuem. There, personal employee information is stored such as: Quem ID, Name,Identi�cation Card Number, Date of Birth, Computer MAC Address, Trello ID,Slack User ID, and Github ID.

This information is then used by other services.

4.6. COMPONENTS 71

Figure 4.12: Trello Quanti�er scheme, with data �ow represented by arrows.

Projeqts

Projeqts is hosted on the cloud, at Heroku's platform. It's built using Rubylanguage, over the Ruby on Rails framework.

For every new project at the company, a new project entry is created on Proje-qts. There, project information is stored such as: Projeqt ID, Name, Description,Trello Board ID, and Github Repositories IDs.

This information is then used by other services.

Chapter 5

Results

In this chapter screenshots of the built Data Visualisation Dashboard are shown.The Dashboard is divided in three main categories, correspondent to the cate-gories of the data being collected: Productivity, Happiness, and O�ce Environ-ment. Inside each of those categories, di�erent data views are displayed. All thedisplayed charts on the dashboard are interactive - on data point mouse hover,more information is displayed to the user, such as date, variable name, and vari-able value.

5.1 Productivity

5.1.1 Projects

Figure 5.1: Number of �nished tasks per week per project, over a period of 8weeks.

73

74 CHAPTER 5. RESULTS

Figure 5.2: Number of encountered software bugs per week per project, over aperiod of 8 weeks.

Figure 5.3: Number of git commits per week per project, over a period of 8 weeks.

Figure 5.4: Dashboard - Productivity projects overview.

5.1. PRODUCTIVITY 75

5.1.2 Single Project

Figure 5.5: Number of �nished tasks per week on a single project, over a periodof 8 weeks.

Figure 5.6: Number of encountered software bugs per week on a single project,over a period of 8 weeks.

Figure 5.7: Average days from Bugs and Next Up to Live - Average number ofdays, per week, that new tasks take from their appearance on the Bugs list untilit's �nished; average number of days, per week, that new tasks take from theirappearance on the Next Up list, until they are �nished. Data from a period of 8weeks.


Figure 5.8: Average days from previous list to next list - Average number of days,that tasks take on each list, per week, over a period of 8 weeks. The lists are:Next Up, In Progress, Code Review, Internal QA, Acceptance, Live.

Figure 5.9: Number of git commits on a single project, over a period of 8 weeks.

Figure 5.10: Number of lines of code added per week on a single project, over aperiod of 8 weeks.

Figure 5.11: Number of lines of code deleted per week on a single project, over aperiod of 8 weeks.

5.2. HAPPINESS 77

Figure 5.12: Dashboard - Productivity single project overview.

5.2 Happiness

5.2.1 Short Term

Figure 5.13: Company happiness average per day, over a period of 30 days.


Figure 5.14: Relative di�erence between the current week's happiness average,and the happiness average of the homologous period from last week.

Figure 5.15: Number of responses given to the "How happy are you today?"question, per value, per day.

Figure 5.16: Relative di�erence between the current week's number of responsesgiven to the "How happy are you today?" question, and the the number of re-sponses given to the same question on the the homologous period from last week.

5.2. HAPPINESS 79

Figure 5.17: Remote vs Non-Remote Happiness Average - Happiness average ofemployees working remote and employees working non-remote, per day, over aperiod of 30 days.

Figure 5.18: Why people are happy - Answers given to the question "What wasthe main reason?", when answering "=)" for the "How happy are you today?"question, for a period of 30 days.

Figure 5.19: Why people are sad - Answers given to the question "What wasthe main reason?", when answering "=(" for the "How happy are you today?"question, for a period of 30 days.


Figure 5.20: Responses given to the "What is blocking you from doing yourwork? What suggestions do you have to make something better (project, com-pany, etc)?" question, in the last 7 days.

Figure 5.21: Dashboard - Happiness short term overview.

5.2.2 Long Term

Figure 5.22: Company happiness average per month, over a period of 9 months.

5.2. HAPPINESS 81

Figure 5.23: Relative di�erence between the current month's happiness average,and the happiness average of the homologous period from last month.

Figure 5.24: Number of responses given to the "How happy are you today?"question, per month.

Figure 5.25: Relative di�erence between the current month's number of responsesgiven to the "How happy are you today?" question, and the the number of re-sponses given to the same question of the homologous period from month.


Figure 5.26: Why people are happy - Answers given to the question "What wasthe main reason?", when answering "=)" for the "How happy are you today?"question, for a period of 3 months.

Figure 5.27: Why people are sad - Answers given to the question "What was themain reason?", when answer "=(" for the "How happy are you today?" question,for a period of 3 months.

Figure 5.28: Dashboard - Happiness long term overview.

5.3. OFFICE ENVIRONMENT 83

5.3 O�ce Environment

Figure 5.29: Noise - Relative noise in the o�ce per hour, for a period of 30 days.

Figure 5.30: People - People at o�ce per hour, for a period of 30 days.

Figure 5.31: People - Illuminance at o�ce per hour, for a period of 30 days.


Figure 5.32: Events - Events per day over a period of 30 days.

Figure 5.33: Dashboard - O�ce Environment overview.

Chapter 6

Conclusion and Future Work

The goal of this project was to build an infrastructure to collect workplace dataon an ongoing basis. We took advantage of the current State of the Art ofQuanti�ed Self, Internet of Things, and Microservices Architecture, and appliedit to the workplace - the Quanti�ed Workplace.

In this chapter, the conclusion is discussed from the perspective of the �nalresults and the community validation. In the last section, a vision of the nextsteps for this platform is described.

6.1 Final Result

For this project seven Data Processing Microservices, two Company Info Mi-croservices, three sensors (part of Data Sources), and a Data Visualization Dash-board were built. These communicate with each other and third party servicesunder a MSA, to collect, process, and display insights about Whitesmith. Theinsights are divided in three areas - Happiness, Productivity, and O�ce Environ-ment. This is done automatically on a frequent basis - hourly, daily, or weekly, -contrasting with the current methods used at most companies to measure theirperformance.

The developed architecture permits the easy couple and decouple of Data Pro-cessing Microservices and Data Sources to the platform. These communicate witheach other under a common language, but are each one using the technology thatbest suits the collection and processing of the variables that is responsible for. Thedeveloped architecture also makes it possible to improve the measurement of thecurrent O�ce Environment variables, by extending the mesh of devices for thatparticular variable, without a�ecting the other Data Processing Microservices.On the other hand, the adoption of MSA for this project slowed the developmentof the platform - due to the operations overhead of having multiple microser-vices to develop and maintain by a single person, and due to the complexity ofcommunications between the various �rst and third-party services.

85

86 CHAPTER 6. CONCLUSION AND FUTURE WORK

The central point of data visualization is the Dashboard, which is accessibleby Whitesmith employees only, at http://whitesmith-metriqs.herokuapp.com.

This consummates the scope of work outlined for this project on the �rstchapter:

• A microservices based architecture for data collection on SMEs,modular for easy attachment and decoupling of future services and devices.

• Continuous data collection, processing, and storage of SME's work-place metrics

• Integration with Internet of Things devices, with the goal of measur-ing physical environmental quantities.

• A data visualisation platform to make the collected data available foranalysis.

Even though performing data analysis wasn't the goal for this project, andconsequently limited e�ort being applied on this part, some interesting insightswere already found along the way. For example:

• On the Productivity Projects charts, we notice that Supa project has ahigher throughput than expected, but with considerable �uctuations throughthe weeks.

• On the Productivity Single Project charts, for the case of Supa project -the project represented in the Results Single Project section of this MasterThesis, - we notice that:

� There was a drastic increase of bugs on the week of 5th of Augustrelative to the previous weeks. This was due to the fact that a releasedate for the project was de�ned for following weeks, and thus a higherlevel of testing was taken.

� Bugs are taking much longer to go to Live than other types of tasks.

� The tasks on the Internal QA list are taking more time than expectedon that state.

• On the Happiness Short Term charts we notice that:

� The two main reasons for people feeling happy are related with workand the environment at work.

� The two main reasons for people feeling sad are related with work andtechnicalities.

• On the Happiness Long Term charts we are starting to notice that:

6.2. COMMUNITY VALIDATION 87

� There's a tendency for people working remotely (telecommuters) to bemore happy than people working from the o�ce.

� The same pattern as on the Happiness Short Term charts is emerging:the two main reasons for feeling happy are related with work and theenvironment at work; and the two main reasons for people feeling sadare related with work, and technicalities.

� People have been answering less to Shrinq's survey in the latest months.The hour at which the survey is taken may need to change, or otherincentives should be implemented.

� The happiness average has been lower in the months of March, May,and June of 2015, and getting higher again in the latest months.

• On the O�ce Environment charts we notice that:

� The noise is tendentiously higher on Fridays - the days where we usu-ally have more events or activity in the o�ce.

� The number of people working from the o�ce in the past weeks islower than what is usual at Whitesmith. Probably due to vacationsand people choosing to work remotely during part of August.

6.2 Community Validation

During the development of this project, a internet article describing our process ofmeasuring happiness - using Shrinq - was published. This article grabbed the at-tention of various people from the Quanti�ed Self and Data Science communities.The article was shared on Twitter by 59 people, featured on Quanti�edSelf.com- the o�cial Quanti�ed Self community - and directly praised by several peopleworking at Keen IO1 - a company that already raised $17.8M from ventures asSequoia Capital, 500 Startups, and Amplify Partners [68].

Both Ernesto Ramirez - Program Director of Quanti�edSelf.com - and DanKador - CTO of Keen IO - showed interest in our future publication of the OpenSource version of Shrinq.

Meetings have been held with Keen IO to discuss the data visualization dash-board. Interest was demonstrated by the Keen IO team in the platform, and inpublicizing our dashboard as an unique example of using Keen IO tools.

6.3 Future Work

After this project, there is interest in developing the platform further:

1Josh Dzielak, Dan Kador, Maria Dumanis, Alexandra Meyer, and Maggie Jan

88 CHAPTER 6. CONCLUSION AND FUTURE WORK

• Integration with new devices - No only there are other devices that we caninstall in the o�ce (Ex: humidity sensors), but there is also the opportunityto support wearables/�tness trackers with the platform - devices such asFitbit, Basis, Jawbone, and Apple Watch, that some employees alreadyuse, can be integrated to collect health information such as sleep quality,body temperature and heart rate. This information can later be crossedwith productivity and happiness data already being collected.

• Expand data collection of the current devices - The data collection of somedevices can be expanded to collect more information about the physical vari-ables. For example, Mike could also measure the frequency of the sound atthe o�ce, and Quantum the light spectrum frequency and lamps �ickeringfrequency.

• Data analysis - Insightful knowledge is born from the intersection of datafrom the di�erent data sources. For that, a scienti�c approach of experi-mentation is necessary, to �nd correlations between the collected data, andevaluate which correspond to causations. Application of Arti�cial Intelli-gence to automatically analyse data and gather insights is also a possibilityinside the domain of expertise of Whitesmith.

• Integration with new productivity and communication tools - Developing aout-of-the-box solution, for easy setup at various companies is the �nal chal-lenge for this work. More and more companies are looking for Quanti�edWorkplace solutions for their organisations, and this marks as an opportu-nity for developing a product that could be sold to those companies. Forthat, the platform should be prepared to be able to adapt to the di�erentorganisations and processes. This will require further market research aboutthe needs of the di�erent organisations looking for these solutions, followedby the integration of the tools and processes used by them, by providing anAPI to gather data from the already existent devices in the market.

Bibliography

[1] Sierra Cedar. 2014-2015 HR Systems Survey. Technical Report 17th AnnualEdition, 2014.

[2] Lee Bryant. The Quanti�ed Organisation: can change become rou-tine? Available at https://www.aether.com/quantifiedself. Accessedon 13/08/2015.

[3] Gary Wolf. Quanti�ed Self. Archived from the original https://www.

aether.com/quantifiedself on 26/03/2012. Accessed on 27/08/2015.

[4] Wikipedia. Quanti�ed Self. Available at https://en.wikipedia.org/wiki/Quantified_Self, accessed on 25/8/2015.

[5] Benjamin Franklin. The Autobiography of Benjamin Franklin. Dover Publi-cations, 1791.

[6] Jan Veira Harald Bauer, Mark Patel. The Internet of Things: Sizing up theopportunity. Technical Report December, McKinsey, 2014.

[7] Ming Liu. A Study of Mobile Sensing Using Smartphones. International

Journal of Distributed Sensor Networks, page 11, 2013.

[8] Quanti�edSelf.com. Guide to Self Tracking Tools. Available at http://

quantifiedself.com/guide/, accessed on 25/8/2015.

[9] Dr J. R. Brotherhood. Nutrition and Sports Performance. Sports Medicine,September 1984, Volume 1, 1984.

[10] Gary Wolf. The Data-Driven Life. Available at http://www.nytimes.

com/2010/05/02/magazine/02self-measurement-t.html?_r=0, accessedon 25/8/2015.

[11] Melanie Swan. Emerging Patient-Driven Health Care Models: An Exam-ination of Health Social Networks, Consumer Personalized Medicine andQuanti�ed Self-Tracking. 2009.

89

https://www.aether.com/quantifiedself



https://en.wikipedia.org/wiki/Quantified_Self

https://en.wikipedia.org/wiki/Quantified_Self

http://quantifiedself.com/guide/

http://quantifiedself.com/guide/

http://www.nytimes.com/2010/05/02/magazine/02self-measurement-t.html?_r=0

http://www.nytimes.com/2010/05/02/magazine/02self-measurement-t.html?_r=0

90 BIBLIOGRAPHY

[12] Maeve Duggan Susannah Fox. Tracking for Health. Technical report, PewResearch Center, jan 2013.

[13] Within the internet of things, quanti�ed self startups grab $318m from vcsin the last year, November 2013. Available at https://www.cbinsights.

com/blog/quantified-self-venture-capital/, accessed on 25/8/2015.

[14] Lee Bryant. The Quanti�ed Organisation: people-powered digital transfor-mation, 2015. Available at http://www.druckerforum.org/blog/?p=870,accessed on 25/8/2015.

[15] H. James Wilson. Wearables in the Workplace, 2013. Available at https://hbr.org/2013/09/wearables-in-the-workplace, accessed on 25/8/2015.

[16] Daniel A. Wren. The History of Management Thought. Wiley, 2005.

[17] Suzanne M. Crampton Jitendra M. Mishra. Employee Monitoring: Privacyin the Workplace? 1998.

[18] Harvard Business Review David A. Garvin. How Google Sold ItsEngineers on Management, 2013. Available at https://hbr.org/

2013/12/how-google-sold-its-engineers-on-management, accessed on25/8/2015.

[19] Chris W. Clegg Matthew C. Davis, Desmond J. Leach. The Physical En-vironment of the O�ce: Contemporary and Emerging Issues. Volume 26,2011.

[20] Lorraine E. Maxwell. Noise in the O�ce Worplace. Technical report.

[21] London Ruby developer working conditions Survey Sum-mary. Available at http://lety.co/blog/2014/09/16/

london-ruby-developers-working-conditions/, accessed on 25/8/2015.

[22] Spencer Rugaber Chris Parnin. The Physical Environment of the O�ce:Contemporary and Emerging Issues. 2010.

[23] Audio Engineering Society Glen Ballou. Handbook For Sound Engineers.Taylor & Francis, 2015.

[24] Equal Loudness Curves. Available at http://hyperphysics.phy-astr.

gsu.edu/hbase/sound/eqloud.html#c1, accessed on 04/9/2015.

[25] IEC 61672-1:2013 . Available at https://webstore.iec.ch/publication/5708, accessed on 04/9/2015.

https://www.cbinsights.com/blog/quantified-self-venture-capital/

https://www.cbinsights.com/blog/quantified-self-venture-capital/

http://www.druckerforum.org/blog/?p=870

https://hbr.org/2013/09/wearables-in-the-workplace

https://hbr.org/2013/09/wearables-in-the-workplace

https://hbr.org/2013/12/how-google-sold-its-engineers-on-management

https://hbr.org/2013/12/how-google-sold-its-engineers-on-management

http://lety.co/blog/2014/09/16/london-ruby-developers-working-conditions/

http://lety.co/blog/2014/09/16/london-ruby-developers-working-conditions/

http://hyperphysics.phy-astr.gsu.edu/hbase/sound/eqloud.html#c1

http://hyperphysics.phy-astr.gsu.edu/hbase/sound/eqloud.html#c1

https://webstore.iec.ch/publication/5708

https://webstore.iec.ch/publication/5708

BIBLIOGRAPHY 91

[26] A-weighting. Available at https://en.wikipedia.org/wiki/A-weighting,accessed on 04/9/2015.

[27] SCENIHR (Scienti�c Committee on Emerging and Newly Identi�ed HealthRisks). Health e�ects of arti�cial light. 2012.

[28] Duco A. Schreuder. Vision and Visual Perception: The Conscious Base of

Seeing. 2008.

[29] M Münch. E�ects of realistic o�ce daylighting and electric lighting condi-tions on visual comfort, alertness and mood. April 2015 vol. 47 no. 2 192-209,2014.

[30] Kurt A. Smith Sat Bir S. Khalsa Shantha M. W. Rajaratnam Eliza VanReen Jamie M. Zeitzer Charles A. Czeisler Steven W. Lockley J Clin JoshuaJ. Gooley, Kyle Chamberlain. Exposure to room light before bedtime sup-presses melatonin onset and shortens melatonin duration in humans. 2010.

[31] George C. Brainard Steven W. Lockley and Charles A. Czeisler. High sensi-tivity of the human circadian melatonin rhythm to resetting by short wave-length light. 2013.

[32] Wolfgang Jagla Herbert Jagle Lindsay T. Sharpe, Andrew Stockman. Aluminous e�ciency function, v*( lambda ), for daylight adaptation. 2005.

[33] Photopic Vision. Available at https://en.wikipedia.org/wiki/

Photopic_vision, accessed on 04/9/2015.

[34] John Roberts Zhichun Jenny Ying Nicholas Bloom, James Liang. Does work-ing from home work? evidence from a chinese experiment. The QuarterlyJournal of Economics, 2014.

[35] David A. Harrison Ravi S. Gajendran. The good, the bad, and the un-known about telecommuting: Meta- analysis of psychological mediators andindividual consequences. Vol. 92, No. 6, 1524-1541, 2007.

[36] Iso/iec 18092:2004 � information technology � telecommunications and in-formation exchange between systems � near �eld communication � interfaceand protocol (nfcip-1), 2004.

[37] Alice J. O'Toole Nicholas Furl, P. Jonathon Phillips. Face recognition algo-rithms and the other-race e�ect: computational mechanisms for a develop-mental contact hypothesis. 2013.

[38] Standard Group MAC Addresses. Available at http://standards.ieee.

org/develop/regauth/tut/macgrp.pdf, accessed on 25/8/2015.

https://en.wikipedia.org/wiki/A-weighting

https://en.wikipedia.org/wiki/Photopic_vision

https://en.wikipedia.org/wiki/Photopic_vision

http://standards.ieee.org/develop/regauth/tut/macgrp.pdf

http://standards.ieee.org/develop/regauth/tut/macgrp.pdf

92 BIBLIOGRAPHY

[39] James T. Simpson Ki-Yoon Kim Kwan-Sik Na, Xiaotong Li. Uncertaintypro�le and software project performance: A cross-national comparison. 2002.

[40] Xiaotong Li Tushar Singh Ki-Yoon Kim Kwan-Sik Na, James T. Simpson.Software development risk and project performance measurement: Evidencein korea. 2006.

[41] The Impact of Agile Quanti�ed. Technical report, Rally Software, 2013.

[42] Diomidis D. Spinellis. Software Quality. Available at http://www.

spinellis.gr/codequality/intro.html, accessed on 25/8/2015.

[43] What is a fair productivity measurement technique for program-mers? Available at http://stackoverflow.com/questions/324399/

what-is-a-fair-productivity-measurement-technique-for-programmers,accessed on 25/8/2015.

[44] How do I measure employee (software developer) performance based on bugscreated? Available at http://pm.stackexchange.com/questions/5289/

how-do-i-measure-employee-software-developer-performance-based

-on-bugs-created, accessed on 25/8/2015.

[45] Johnmarshall Reeve Alice M. Isen. The in�uence of positive a�ect on intrinsicand extrinsic motivation: Facilitating enjoyment of play, responsible workbehavior, and self-control. 2005.

[46] Eugenio Proto Andrew J. Oswald and Daniel Sgroi. Happiness and produc-tivity. 2014.

[47] Psychology Of Happiness. Available at http://www.scholarpedia.org/

article/Psychology_of_happiness, accessed on 25/8/2015.

[48] Mihaly Csikszentmihalyi Joel M. Hektner, Jennifer A. Schmidt. 2007.

[49] Martin Fowler. Microservices. Available at http://martinfowler.com/

articles/microservices.html, accessed on 25/8/2015.

[50] Microservices: Decomposing Applications for Deployability and Scalability.Available at http://www.infoq.com/articles/microservices-intro, ac-cessed on 25/8/2015.

[51] Pattern: Microservices Architecture. Available at http://microservices.io/patterns/microservices.html, accessed on 25/8/2015.

[52] Micro Service Architecture. Available at https://yobriefca.se/blog/

2013/04/29/micro-service-architecture/, accessed on 25/8/2015.

http://www.spinellis.gr/codequality/intro.html

http://www.spinellis.gr/codequality/intro.html

http://stackoverflow.com/questions/324399/what-is-a-fair-productivity-measurement-technique-for-programmers

http://stackoverflow.com/questions/324399/what-is-a-fair-productivity-measurement-technique-for-programmers

http://pm.stackexchange.com/questions/5289/how-do-i-measure-employee-software-developer-performance-based

http://pm.stackexchange.com/questions/5289/how-do-i-measure-employee-software-developer-performance-based

-on-bugs-created

http://www.scholarpedia.org/article/Psychology_of_happiness

http://www.scholarpedia.org/article/Psychology_of_happiness

http://martinfowler.com/articles/microservices.html

http://martinfowler.com/articles/microservices.html

http://www.infoq.com/articles/microservices-intro

http://microservices.io/patterns/microservices.html

http://microservices.io/patterns/microservices.html

https://yobriefca.se/blog/2013/04/29/micro-service-architecture/

https://yobriefca.se/blog/2013/04/29/micro-service-architecture/

BIBLIOGRAPHY 93

[53] Microservices and SOA. Available at http://www.oracle.com/

technetwork/issue-archive/2015/15-mar/o25architect-2458702.

html, accessed on 25/8/2015.

[54] Fundamental Design Terminology and Concepts. Available athttp://serviceorientation.com/whatissoa/fundamental_design_

terminology_and_concepts, accessed on 25/8/2015.

[55] Service Orientation. Available at https://en.wikipedia.org/wiki/

Service-orientation, accessed on 25/8/2015.

[56] SOA vs Microservices. Available at https://blog.hedges.net/2014/03/

31/soa-vs-microservices/, accessed on 25/8/2015.

[57] Di�erence between Microservices Architecture and SOA. Avail-able at http://stackoverflow.com/questions/25501098/

difference-between-microservices-architecture-and-soa, accessedon 25/8/2015.

[58] Mark Little. Microservices and SOA. Available at http://www.infoq.com/news/2014/03/microservices-soa, accessed on 25/8/2015.

[59] José Ribeiro. Integration and optimization of energy data analysis systems.Master's thesis, 2014.

[60] Mark Little. MonolithFirst. Available at http://martinfowler.com/

bliki/MonolithFirst.html, accessed on 25/8/2015.

[61] Internet of things (iot): A vision, architectural elements, and future direc-tions. Future Generation Computer Systems, Volume 29 Issue 7, September,2013, 2013.

[62] A Reference Architecture for the Internet of Things. Technical Report 0.0.8,WSO2, 2014.

[63] Internet of things (iot): A vision, architectural elements, and future direc-tions. 2012.

[64] IoT Architecture. Technical report, European Commision, 2014.

[65] D. Thaler H. Tschofenig, J. Arkko and D. McPherson. Architectural Con-siderations in Smart Object Networking. March 2015.

[66] TSL2560, TSL2561 LIGHT-TO-DIGITAL CONVERTER - Datasheet.Available at https://www.adafruit.com/datasheets/TSL256x.pdf, ac-cessed on 27/8/2015.

http://www.oracle.com/technetwork/issue-archive/2015/15-mar/o25architect-2458702.html



http://serviceorientation.com/whatissoa/fundamental_design_terminology_and_concepts

http://serviceorientation.com/whatissoa/fundamental_design_terminology_and_concepts

https://en.wikipedia.org/wiki/Service-orientation

https://en.wikipedia.org/wiki/Service-orientation

https://blog.hedges.net/2014/03/31/soa-vs-microservices/

https://blog.hedges.net/2014/03/31/soa-vs-microservices/

http://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa

http://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa

http://www.infoq.com/news/2014/03/microservices-soa

http://www.infoq.com/news/2014/03/microservices-soa

http://martinfowler.com/bliki/MonolithFirst.html

http://martinfowler.com/bliki/MonolithFirst.html

https://www.adafruit.com/datasheets/TSL256x.pdf

94 BIBLIOGRAPHY

[67] Nmap. Available at https://en.wikipedia.org/wiki/Nmap, accessed on27/8/2015.

[68] Crunchbase - Keen IO. Available at https://www.crunchbase.com/

organization/keen, accessed on 25/8/2015.

https://en.wikipedia.org/wiki/Nmap

https://www.crunchbase.com/organization/keen

https://www.crunchbase.com/organization/keen

quanti cation of smes' work environment, happiness, and productivity, using a microservices …...

Documents