A brief history of Ksatria Medical System
Ksatria is a medical software system for hospitals, the flagship product being the Ksatria Medical System (KMS). The company has seen success, with many hospitals having utilised the software worldwide. Some of their success can be attributed to being innovative and using great technologies, but that was 10 years ago, and like many companies, the software has started to age and legacy has been settling in.
The good news for Ksatria is that they were able to continue to update the legacy system and support their current customer base, and as it a Java-based application there are still plenty of developers around that know the language. However, the decision makers needed to decide if they were going to continue with the legacy system and watch their release cycles get longer and longer, or whether it was time to look at some way of modernising the legacy system to use better technologies and improve the user experience.
Ultimately, it was decided that it was time to modernise, and Ksatria approached Codebots with the question, How long will a legacy migration take? This is a great question to ask from a business perspective because, if you can determine how long a migration will take, then you can easily work out how much it will cost. Time is money.
In our article 7 ways to estimate a software project we explain how Codebots can be used to create more certainty in an estimation.
As the KMS Product Lead Afri says in the following video, “It takes a little longer but you end up with a higher level of confidence with your estimation.”
Solving the problem
Software estimations are notoriously difficult; anything that tries to predict the future has a chance of being incorrect. Ultimately, what we dealing with is uncertainty, and this can manifest itself in many forms.
From a project management point of view this translates to risk, and the best way to deal with risk is to acknowledge its existence and ensure mitigation tactics are in place to deal with them. The estimation process followed in this case study is grounded in this type of thinking to help ensure a good estimation and that expectations are managed.
Quality at speed
The KMS legacy system is large, with 663 tables currently in the database. This means that any strategy that tries to migrate the entire application in a single step would be doomed for failure. Due to this, it was decided by the KMS team to use a ‘divide and conquer’ approach and align the new system with the current sales efforts. Two customers were identified and interviewed to find out what functionality was the most needed and would result in a sale when the new application is ready. Smart.
The list of requirements that was identified was referred to as the MVP (Minimal Viable Product), and focused on the registration module of the application. Calling it an MVP brought in more of a startup feel to the project and is a good move to align the software and sales teams.
From the requirements for the MVP an estimation process was put in place that followed two estimates; a fixed time estimate and a fixed scope estimate. The reason for these two estimates is to help determine the mindset of how the project will play out. The key differences are that a fixed time with a variable scope encourages more of an Agile mindset, however a fixed scope with a variable time embraces more of a waterfall mindset. This can help with managing expectations and it acknowledges the cone of uncertainty.
For the KMS project, two seperate teams did an estimation from the list of requirements for the MVP; one team had previous experience working on the legacy system, and another team that was qualified in using Codebots. The difference in the results were significant, with the traditional team estimating it would take 69 weeks using traditional software development, while the Codebots team estimated is would take 22 weeks - that’s 32% of the time in comparison!
| Estimation | Fixed Time | Fixed Scope |
|---|---|---|
| Traditional | 69 weeks | 1600 weeks. Too big a number. |
| Codebots | 22 weeks | 57 weeks. |
| Outcome | 32% of traditional | Cannot calculate. Project would likely fail. |
So, how can we confidently predict such a large saving? Well, this is where reuse meets scale.
Reuse with scale
On average, a codebot writes about 92% of an application with other 8% being created by the software team; sometimes higher, sometimes lower.
Part of the 92% of that codebots write are features that are built in to the app and accounts for its underlying functionality.
| Extension | Short Description |
|---|---|
| API | Application Programming Interface’s (APIs) are how you integrate with other software systems. The new KMS application will be able to be integrated with other hospital systems. |
| CRUD | With 663 tables in the KMS legacy system, there is a lot of data management that needs to happen. Create/Read/Update/Delete (CRUD) are the 4 basic operations that can be performed on data. |
In the majority of the bot written code, there is lots of reuse of what we call extensions. Extensions are like common business solutions that you will need to do on many different applications.
The extensions are a great opportunity for reuse and the KMS team wanted to explore some of the different types and how they could potentially be used in the application. The following table lists some of these extensions and their application for the KMS team:
| Extension | Short Description |
|---|---|
| Users | The ability to have users login and access parts of the application that they are authorised for. Doctors, Nurses, Admin, and other roles can access different parts of the application. |
| Dashboard | The hospital staff will be presented with insight into the hospital practices. They can slice and dice the data - similar to a Business Intelligence (BI) tool. |
| Forms | Patients will be able to fill out forms configured by staff and a new registration process can be created to smooth out internal processes. |
| Workflows | A patient can move through a hospitals workflow to ensure they get the best possible care. |
The reusability of the extensions holds a lot of power. At the beginning of an estimation it is important to find out how much coverage you may get on a legacy migration project like KMS. To work this out, the KMS team went through the the MVP’s requirements to see if a extensions could be fully, partially, or was unable to be used for its implementation. The results can be seen in the following sketch; 34.4% of the requirements can be fully written by a codebot, 39.3% partially written, and just 26.2% of the requirements would need to be completely custom code.
So, how can we implement custom code when the extensions cannot help? Well, it is where freedom meets control.
Freedom meets control
For KMS, the team wanted to explore the extent of how much freedom they had with the code that was written by a bot. Could they manipulate a codebot’s extension to get something more closely aligned with how their customers were using the legacy system? And could they do something around the navigation and the registration process that was unique and pure custom code? Exploring the possibilities to both of these questions aligned with capturing a deeper understanding of how a codebot works.
Can we extend?
To see how they could manipulate or change their code alongside a codebots extension, it was decided that a tech spike on the CRUD feature would be conducted. CRUD, or create/read/update/delete, are the four operations that you can do on any data, and a codebot can write lots of code to make this easier for the developers. However, KMS wanted to explore a different way to perform searches and select associated data. In the following video, you can see what was achieved in a single day by the developer, Tom.
The result of the CRUD Tech Spike was 334,132 lines of code written by SpringBot, and 252 lines of code written by Tom (see image below). He was able to modify the code so that it could do two different things: how an associated entity is displayed when it is clicked on, and use the search bar to search for an associated entity so that it displays a modal (popup). Not only is this code usable for developers, but it also meant that the new application could be built in line with what the existing KMS users are used to, which will also help later on with training and sales.
Can we create?
After the CRUD tech spike, the KMS team became more confident that they could extend from the bot written code. The second question they wanted to explore was whether they could create something unique and custom, specificially regarding the navigation and registration process.
A separate team was put together to scope a solution and create a new navigation and registration process. As seen in the following sketch, the scoping team brainstormed and produced a set of prototypes which resulted in a high fidelity click through prototype that was presented using Adobe XD.
This prototype (and accompanying design system) allowed the KMS team to look into a window of the future. The scoping team also used the prototype to create an early version of the new application, and in the following video, you can watch one of the developers, Kellie, using the platform and bots to tech spike some of the prototype.
Through this scoping excersise, the KMS team were confident that the new UX (user experience) and design system was modern and a significant improvement over the legacy system. The tech spikes for the new UX resulted in 334,132 lines of code written by SpringBot and 252 lines of code written by Kellie, which is a huge head start for when development kicks off.
Summary
KMS is now underway with a legacy migration and are off to a great start. They are using the bots to do the heavy lifting on the project, which allows the wider team to use their creativity to solve both design and technical challenges. The estimations say that by using the codebots technologies it will take 32% of the time when compared to a traditional route, which is a massive saving in time.
If you want to observe this project in more detail, watch the highlights reel below.
One of the most important aspects of a software estimation is to acknowledge the risks in the upcoming project. If you acknowledge that the risk is there, then you can put mechanisms in place to help ensure the estimation matches the reality of the project. This project saw the KMS team acknowledge the risks associated with what they were undertaking instead of them walking in blind; they were shining a torch into the corners of the legacy system to make sure that they minimised the nasty surprises that might jump out at them.
One of the biggest risks for the KMS team was to gain an understanding of the new technologies they would be using; most teams pickup the platform quickly but it may take a little longer to understand the target application technologies. SpringBot writes to a Spring server-side and an Angular client-side, and as the team is familiar with Spring but not Angular, there is a training/knowledge gap to get an understanding of Angular. Even though Angular is a great and well-known JavaScript framework, it will still take the KMS team time to bring themselves up to speed, and this means that the prediction of 32% was for a team already proficient in these technologies. However, even if the final result comes in at 50% or even 60% that is still a massive saving.
For Codebots to live up to our three promises (quality at speed, reuse with scale, and freedom meets control), we must provide more than just a cool set of technologies like a codebot; it is also part of our mission to help organisations with their way of working. So, we provide coaches to assist with projects and we also have a global partner network so you can work with a local organisation in your area. You can sign up today and please reach out to us with any questions, we love to help.
Go KMS! We are on the journey with you.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
