Innovating in the digital domain is almost essential for modern firms to be competitive.
Anno 2021, seven of the ten largest companies worldwide belong to the digital sector compared to only one just twelve years ago.
Digital technologies enable organizations to provide significant additional value that is incredibly scalable to many users, to streamline operations, and to help decision-makers gain valuable insights.

However, creating new and innovative digital technologies is challenging because the competition is intense.
All digital systems within firms, including small experiments that might develop into successful digital innovations, are closely monitored by so-called enterprise architects.
Enterprise architects stipulate the direction of the entire IT landscape, which makes the IT landscape significantly more manageable but perhaps also influences the development of new digital innovations.
Surprisingly, the literature on the influence of enterprise architects on a firm's digital innovativeness is, to the best of the author's knowledge, literally non-existent.

Therefore, this research aims to provide insight into how enterprise architects influence their firm's ability to produce digital innovations.
This is accomplished by measuring for more than 50 firms their digital innovativeness, the extent to which certain Enterprise Architecture (EA)-related factors apply, and the correlation between these data points.
Additionally, the digital innovation readiness of each firm is measured by using several questionnaire items retrieved from prior research and is modeled as a moderating variable in the conceptual model.

The measure for digital innovativeness was found using a literature review and consists of 7 questionnaire items.
The EA-related factors that might influence a firm's digital innovativeness (EA factors) were obtained from three different sources: scientific articles that contain previously identified EA factors, a Best Worst Method prioritization of the factors included in the DyAMM Enterprise Architecture maturity framework, and insights from EA experts.
This approach resulted in the identification of 25 EA factors distributed among six categories: enterprise architecture design, alignment of the To-Be architecture with the business objectives, development of the proper architecture, usage of the architecture, implementation of the architecture, and enterprise architect behavior.

Ten statistically significant correlations were found.
Hiring highly skilled enterprise architects is the highest-correlating factor I found that increases a firm's digital innovativeness.
Other important influencing factors are whether the enterprise architects work in an agile manner, are aware of their role in the context of digital innovation, and actively identify external opportunities for innovation.
Lesser important influencing factors are whether enterprise architects are involved in the strategic discussions, the existence of an open feedback culture, and the presence of a solid EA foundation on top of which it is easy for employees to innovate.

EA experts indicated that all the statistically significant correlations found are probably causal.
Thus, whereas existing literature only hypothesizes that EA factors influence a firm's digital innovativeness, this study provides EA practitioners with the first empirically-grounded guidelines on how to do this.
These findings are important considering the fact that digital innovativeness is often considered a key capability for firms to be competitive in the current rapidly changing markets.

This study empirically shows that an excellent enterprise architect is not only able to design and ensure compliance to an enterprise architecture, but also to behave in a way that stimulates the emergence and development of valuable innovative ideas.

EA experts also indicated for many other EA factors that they would expect these factors to positively influence firms' digital innovativeness, but that more samples are needed to be sufficiently confident in these causal relationships.
Along with several other recommendations for future research, this thesis hopes to also provide a solid starting point for other researchers.

Federated learning (FL) is a type of machine learning where devices locally train a model on their private data.
The devices iteratively communicate this model to a central server which combines the models and sends the updated model back to all devices.
Because the data stays on the devices and only the model is transmitted, federated learning is considered as a privacy-friendly alternative to regular machine learning where all data is transmitted over the internet.

However, the central server used in typical FL systems not only poses a single point of failure susceptible to crashes or hacks, but may also become a performance bottleneck. These issues are alleviated by decentralized FL (DFL), where the peers communicate model updates with each other instead of with a single server.

Unfortunately, DFL is challenging since (1) the training data possessed by different peers is often non-i.i.d. (i.e., distributed differently between the peers) and (2) malicious, or Byzantine, attackers can share arbitrary model updates with other peers to subvert the training process.

We address these two challenges and present Bristle, middleware between the learning application and the decentralized network layer.
Bristle leverages transfer learning to predetermine and freeze the non-output layers of a neural network, significantly speeding up model training and lowering communication costs.
To securely update the output layer with model updates from other peers, we design a fast distance-based prioritizer and a novel performance-based integrator.
The prioritizer prioritizes the model updates based on their distance to the peer's own model and an explore-exploit trade-off, and the integrator integrates each class of each model update separately based on their performance on a small set of i.i.d. test samples.
Their combined effect results in high resilience to Byzantine attackers and the ability to handle non-i.i.d. classes.

We empirically show that Bristle converges to a consistent 95% accuracy in Byzantine environments, outperforming all evaluated baselines. In non-Byzantine environments, Bristle requires 83% fewer iterations to achieve 90% accuracy compared to state-of-the-art methods. We show that when the training classes are non-i.i.d., Bristle significantly outperforms the accuracy of the most Byzantine-resilient baselines by 2.3x while reducing communication costs by 90%.

In this project we aimed to create a post-trading day safeguard system that allows for the identification of bugs in the primary and secondary risk control systems at Optiver. These systems are needed to prevent undesirable exposure to the market from happening, and to ensure that they know exactly what this exposure is. The amount of input data for this project, given in the form of log files, equates to roughly 200 GB per trading day, post sanitation. We have developed a program that can simulate an entire trading day and detect if any limits were breached. This program can be run overnight, allowing for a T+1 report in the morning after the respective trading day. The difficulties in this project were in the acquisition of all knowledge concerning the unique traits of various markets around the world, inconsistencies in the data, incomplete documentation, and optimization of the program to run within the required time.

Organizationally, the project was executed within an agile workflow, with Kanban as software development methodology. Furthermore, the project is tested extensively to ensure the accuracy and correctness of the program.

Concerning the impact of the project, it contributed to the identification and resolution of multiple previously unknown bugs in the control systems at Optiver. Furthermore, our project verified the existence of some previously known issues. In the future, when the software is run to verify all order logs of Optiver, the software will prove its value by either increasing the confidence that there is an absence of bugs in the RiskGuard and autotrading software of Optiver or by identifying breached limits, indicating a bug.