Introduce Agile Financial Advisory Services company

- [Instructor] Agile Financial Advisory Services had grown as a reliable institution and was a trusted advisor of many families and businesses. Their main application called AgileCore had both employee only and customer facing components. It was built in 2003 with the layered architecture with the following layers, user interface layer, business logic layer, data access layer and a backend database. The application had an XML web services based frontend which integrated with applications built by their partner companies. XML web services exposed the applications functionality as services and the company's IT department could claim to be one of the early adopters of service oriented architecture. Starting in 2010, they had improved their product delivery pipeline by following an iterative and incremental approach that used scrum and Kanban. They use two weeks sprints and had built an on-premise code delivery pipeline. They also added mobile apps that integrated with the same business logic layer. They had moved from physical servers to virtual servers to make better use of servers compute capacity and that made server provisioning much easier. Not all was well with the system though. Their IT department met with their IT director and listed many issues they were facing. The top five issues were listed as, the application had grown in size. It had 3000+ classes and the backend database had 1,300+ tables. The entire application had to be deployed as a single unit. This meant deploying a small new feature would need a lot of regression testing as the entire application had to be deployed as a single unit. Most of the deployment process was automated but this is still required considerable manual effort which delayed deployments significantly. Their competitors in the meantime were releasing features much faster and that meant losing business to competitors. The main application needed scaling but due to the size of the application they needed large virtual machine to handle the workload. Most of the scaling was needed only in two to three subsystems but they could not scale those subsystems independently because the code and database tables were all shared by all subsystems. Their build server was running out of capacity because the build process had to build the entire application which was growing in size. Their IT department had organized their staff as feature teams, one team for each subsystem. Each team had the combined skills of building end to end functionality but keeping team size optimal that is less than 10, a scrum recommendation was becoming a challenge. This is because the subsystems were growing bigger and more complex and they needed more persons to build and deploy new features on time. The installation process was partially automated but the manual steps were based on a 75 page installation guide which made the installation process time consuming and error prone. In other words there was a need for a technology refresh.