The given Sysops Squad system has many drawbacks that include customer and call center staff complains about loosing track of the created tickets, wrong consultant showing up to fix the customer's problem, system freezing or crashing during a spike and changes in the system are very difficult due to its monolith archtecture. These drawbacks are due to not having proper architectural decision and design. We propose to use the techniques presented in the Architectural Katas course to tackle these issues. We are using a top-down approach with the following steps:

• Problem statement - identify the limitations of the current system and issues affecting stakeholders
• Identify architecture characteristics - identify the relevant architecture characteristic associated to the issues identifed in the previous step;
• Identify the ideal Architecture style - we look at all the spectrum of architecture styles and search for the one which optmizes the architecture characteristics identifed in the previous step;
• Definition of modules/services - Once the architecture style is defined we utillize the Action/Actor and Event Storm techniques to depict the modules/services that will be part of the solution. We iterate on the services to refine the final solution;
• Topology - once we have the modules/services defined we construct the architecture topology, identifying elements of the architecture such as UIs, integration with external systems and communication among the microservices;
• Data Model - having the topology defined we analysed the current data model in order to split the existing tables into aggregates into the target model.
• Migration Strategy - we finally suggest a possible approach for the migration from the current system to the new system.

During all steps we made usage of ADRs to support our decisions. Diagrams and text will contain references to the ADRs, when relevant. Moreover, the list of all the ADRs can be found here.

We have analysed the slides and the video in order to extract the main challenges faced by sysops with the existing system. Once we identified the main issues (represented below by the pink stickers) we verified which Architecture Characteristics (Scalabilty, Elasticity, Fault-tolerence, Testability and Evolvability) are most relevant to address the identified issues. As a reference for the list of architecture characteristics we utilized the book Mark Richards and Neal Ford, Fundamentals of Software Architecture. The architecture characteristics are represented by the yellow stickers below.

There are different types of architectural style exist (Layered, Modular-Monolith, Microkernel, Microservice and so on) and those are also mentioned in the book Mark Richards and Neal Ford, Fundamentals of Software Architecture. We have analised the pros and cons between the two style that include modular-monolith and microservice architecture in the ADR0002. Finally we have decided to use microservic architecutural sytle in order to solve the current system architecutre.

Here, we have identified the actors and actions from the exiting architecture and given functionalites of the system.

The Actor/Action method allowed us to have a first view of the services and the interaction among them. Moreover, we have utilized the event storm to build understanding and confidence on the solution approach we are proposing. As the diagram below shows, we could visualize the functions that would be implemented by each service and also the way the services would interact in the future platform.
On the below diagram we have the most important actions and events. We focused on the happy path. As one example, we have the event for "Device fixed" but not for "Device not fixed". This is intentional in order to avoid cluttering the diagram.

The datamodel from the current monolith datamodel is complex and has many interdependencies on the tables.

We have analysed the Sysops monolith datamodel and here we propose the segregation of data according to the functional decomposition of the microservices. All data is shared via well defined APIs and there is NO database sharing among the microservices. It is to be noted that, in order to remove the dependencies among microservices, so entities are duplicated (example: Supported Product). This is intentional and by design.

Due to the difference between the monolith and microservice architecture style we recomend to migration the "Big Bang" approach.