In mid-June 2019, I started an internship with Bosch in Tokyo, Japan. Till mid-November, I am going to work as a DevOps Engineer taking care of the whole software development cycle from planning, analysis and design through to implementation, deployment and maintenance.
Background
Usually, internships in the field of software engineering are within a team consisting of at least one other developer. However, as I am interning in the Automotive Aftermarket department which mainly deals with sales, marketing and logistics, I am there as the only engineer. Fortunately, during my last internship for Bosch in Singapore, I picked up lots of skills needed not only for software development but also for organising your project within the Bosch group, so I had some ideas about the security restrictions and the proxy issues.
Requirement Analysis and Planning
After arriving on the first day, my supervisor Atsushi Takada already arranged the first deep dive into the complex ERP orchestration for the Japanese market and how different part numbers are grouped differently based on customers. Afterwards, we focused on the process of bringing products in the ERP systems from the supply to the demand side of the market to eventually sell them to customers.
My task is to improve this process and I can decide how to do this. I figured out that the main bottleneck is the communication between the different teams. I aim to reduce the time and effort needed for informing other teams about their tasks. Furthermore, all data should be consistent and readable by everyone involved in the process. Suitable for this is developing a new web application which fulfills the required needs.
Politics Influencing the Output (and eventually the Outcome)
Before my arrival, different parties discussed already about different approaches to improve the process. This leads to different parties trying to influence the development to their own advantage. I always have to remind myself of what I want to achieve without digressing too much to particular needs. Nonetheless, I should be mindful that everyone’s wishes are at least partly reflected.
Agile Development to Tailor the Product
The key to convincing others to use your application is the usability; the application would have to be tailored to their needs and developed together with them. During the design of the new application, it became apparent that information could sometimes be delivered or understood incorrectly. This, together with the limited time available for this project, made it quite clear that a more agile approach, where the planned product could be changed quite easily, was necessary.
Communication within the “Team”
The communication in the development team is not that important because I am the only developer responsible for the product. Nevertheless, introducing the product to the department and communicating with lots of different parties happens often through my supervisor, who knows quite well the process I am trying to improve. In addition, communicating with the department was way easier in Japanese. This means that I update him of my progress quite often.
Agile Development in Sprints
The product backlog describes everything which should eventually become implemented. Based on priority and suitability, selected issues in the product backlog are transferred into the sprint backlog to be implemented in the next sprint. After a short period of time (around one to two weeks), a product increment could be deployed. Then, the users could already test and feedback the changes which would get implemented during the next sprints. This also means that the product backlog could get extended further.
Other Locations
It would be useless developing a new application which already exists similarly for other locations and the plan is not to implement a way of performing the process that would only be applied in Japan. After talking to the teams in other countries, we figured out that this improvement would be helpful for multiple locations.
Design
The main idea is creating a table with all the products which should be transferred from the supply to the demand side. Additionally, this table should hold all the relevant details of the departments involved such that no additional data sources are needed.
Common Database
An employee of the request-initiating team would create an entry in the table with all the information they could get. Afterwards, an employee of the next team would go on to read some information, add some information and complete their tasks. This could go on through multiple teams and eventually the initial team would receive the information that all the tasks for the specific product are performed.
Tailor-made Editor
Choosing a tailor-made editor instead of a standard Excel table could prevent more wrong user input. Besides the table with all the products, different views allow the user to specify the values selectable in the drop-down lists in the primary editor. There are simpler drop-down lists with just values like the production plant and its code and more complex drop-down lists with objects like customers, responsibilities and business units (selecting one of these objects create links to other objects).
Furthermore, a tailor-made editor allows for customisation for a specific user group.
Identification of Users to Assign Different Roles
In the next development step, users would have to log in to identify and get the authorisation to perform only the operations assigned to their role. This also leads to the possibility that every user could get specific tasks, finish them and then, the next user should get notified automatically via email.
Dashboard with KPIs
As a final step, some analytics could be performed on the data entered and its metadata about the entry. This leads to the possibility to give an overview of the whole process and create a dashboard with relevant KPIs.
Implementation
An interesting decision for developers is often the choice of the technology stack. At the start of my internship, I did not know exactly what the digital infrastructure of Bosch offered. Nevertheless, I had learnt from my previous internship which technology stacks other services often use.
Backend
As a backend technology, I mainly considered Spring Boot in Java and Flask in Python because there was some time pressure and these are suitable frameworks which I am quite proficient in. I like the structure of Java which results partly out of its verbosity; Python does not seem to be that verbose. Even though both frameworks offer good object-relational mapping (ORM) tools to connect to databases (Spring Data JPA with Hibernate and SQLAlchemy), the Spring community seems to be bigger and I enjoy the simplicity of JPA repositories.
Frontend
Although I had some previous experience developing in Angular and attended a seminar about React, I did not use them and started picking up Vaadin Flow during this internship. It is a framework offering frontend development directly in Java. This means that I needed less effort wiring REST APIs for the communication between frontend and backend and there are also fewer security vulnerabilities. Moreover, the existing designs of Vaadin could already be used for simple business applications and Vaadin makes it quite simple to display data of such data-driven applications.
Database
Hence, Vaadin and Spring Boot were chosen for the frontend and backend respectively. The choice for the database was still left. The general decision is SQL or NoSQL. This was quite an obvious decision because business data objects in a table have exactly the same attributes with often recurring values and the data is already represented in the format of different Excel tables. In addition, querying for different attributes is quite simple: the ORM tool offers a simple connection between programme code and database.
Even though an object database would have been an interesting new topic, the limited time restricts me from trying completely new topics.
Interviews
According to the previously described agile development approach, I try to conduct interviews with the involved teams differently: I develop a rough prototype of the product and then I show them the prototype and ask them specifically how they want it and which information they need. Afterwards, I try to implement their requirements and approach the next team with the “incremented prototype”. This allows me to transport my thoughts not only verbally but also visually. Furthermore, they are more open because they could already feel an improvement of their process.
Deployment
Designing and developing an application is not enough. It should also be deployed to be made available for others. Without a supervisor or any direct colleagues in the tech area, it was difficult finding out about the options available in the intranet.
Bosch IoT Cloud or OpenShift
After contacting lots of different people, I found out two feasible options: hosting the application using an available OpenShift instance or the Bosch IoT Cloud (BIC). The BIC is based on Cloud Foundry. Depending on the used technology, only a buildpack has to be selected to deploy the application. OpenShift requires a Docker image of the application, which could then be deployed while BIC (Cloud Foundry) does not require a Docker image (but could use it).
The convenience of usage is quite similar and both platforms offer a good scalability for asynchronous processes. Nevertheless, support for the BIC is available directly in the Shibuya office in Tokyo. Even though the developed application is not directly IoT related, we decided on deploying the app on the BIC because of its support.
Managed Database
Previously, the decision for SQL was described. This was not only to avoid dealing with synchronous processes in an asynchronous environment but also because it is offered as a service and the service provider takes care of the backups, therefore a managed database was the first choice. MySQL is easy to use with JPA and it is also the cheapest option in the BIC among the available SQL databases.
Limited to Bosch Intranet
To avoid lots of security and privacy concerns, the application would be deployed only within the Bosch intranet and therefore, not accessible by external parties.
Project Management With GitLab
For managing the project, I use GitLab. Till now, it is not clear whether I could create an open-source version but at least the activity could be tracked on my GitLab page.
GitLab also offers the opportunity of creating deployment pipelines. Like this, DevOps could try to use less tools to perform the same tasks. Of course, the combination of Jira, Jenkins and Bitbucket would offer me more opportunities but the free GitLab version is an interesting option to create a more portable environment. Nevertheless, the CI/CD functionality is restricted by the strict proxy usage.
Future…
A deployed application should also be monitored and maintained. Monitoring and maintenance is especially important at the beginning; users should realise how well the application works. After my internship, I wouldn’t be on-call to provide technical support that fast. Nonetheless, the BIC is still accessible externally. Moreover, the support at the Shibuya office could provide help quite fast.
Assessment of the Project
When presenting the ideas, one manager, who usually initiates projects like this, told me that a project like this would normally be scheduled for two years with multiple developers. My five month-long internship might be a little bit too ambitious to achieve this. But at least, I want to provide Bosch with an application offering a little bit more than just a proof of concept. After my internship, I will be still available for support and I am interested to continue working on this project that I created from scratch. Maybe, Bosch offices in other locations could benefit from this new application as well.
Internship Opportunities
If you also want to pursue an internship in Japan for a multinational company like Bosch, have a look at the new recruiting homepage of Bosch Japan. Currently, the recruiting homepage is undergoing a transition, so some internship offerings could still be found on Kopra. Like the word multinational implies, interns from all nationalities are welcomed.
As I already have my second great internship with Bosch, I could also recommend having a look at the global careers page of Bosch. Navigate to specific countries and find your internship.
Contact me via email if you would be interested in experiencing the whole software development life cycle within the Bosch Group and own the developed tool. You should be quite experienced in programming and should not be afraid to negotiate with others on how to design your tool.