Ksatria Medical System: A Software Estimation Case Study
By Eban Escott and Indi Tansey 12 June 2020 Case Studies
Ksatria is a medical software system for hospitals. The company has been very successful with many hospitals using it across two countries so far. Their flagship product is known as the Ksatria Medical System (KMS). Some of their success can be attributed to being innovative and using great technologies, but that was 10 years ago. Like many companies, the software has started to age and legacy has been settling in.
The good news is that Ksatria can still continue to update the legacy system and support their current customer base. It is a Java-based application and there are still plenty of developers around that know that language. But 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 is it time to look at some way of modernising the legacy system to use better technologies and an improved user experience.
The decision was made that it would be time to modernise. Codebots was approached to answer a question about this. We were asked "How long will a legacy migration take?" From a business point of view, this is a good question to ask. If you can determine how long a migration will take, then you can easily work out how much it will cost. Time is money.
You can check out 7 ways to estimate a software project and in this case study, you are going to see firsthand how a codebot can be used to create more certainty in an estimation. As Afri says in the following video; "It takes a little longer but you end up with a higher level of confidence with your estimation."
Software estimations are notoriously difficult. Actually, anything that tries to predict the future has a chance of not being correct. Any hope of predicting the future 100% accurately got thrown out the window when quantum physics showed randomness is at the heart of the way the universe works. We don't have enough computers in the world to work out the interactions of a few atoms, let alone to calculate with accuracy a future state like software estimations.
So, what we are left with is randomness to deal with, and this can manifest itself in many forms. From a project management point of view, we are talking about risk. And the best way to deal with risk is to acknowledge its existence and to 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 expectations are managed.
Quality at Speed
The KMS legacy system is large. There are currently 663 tables in the database. Any strategy that would try to migrate the entire application in a single step would be doomed for failure. 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 followed that resulted in two estimates; a fixed time estimate and a fixed scope estimate. The reason for the two estimates is to help determine the mindset of how the project will play out. Using a fixed time with a variable scope embraces more of an Agile mindset. Using 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. There are always unknown unknowns that will come up on a software project.
So, two seperate teams did an estimation from the list of requirements for the MVP. One team that previously had been working on the legacy system; and another team that was qualified in using a codebot. The difference in the results were significant. The traditional team estimated it would take 69 weeks using traditional software development. The codebots team, estimated is would take 22 weeks. That is 32% of the time in comparison! When the results came in, it was a special moment in time for the team.
|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, it is where reuse meets scale.
Reuse with Scale
On average, a codebot writes about 92% of an application. The other 8% is created by the software team. Sometimes it is higher, sometimes lower. In the 92% of code written by a bot, there is lots of reuse of what we call behaviours. Behaviours are like common business solutions that you will need to do on lots of different applications.
The behaviours are a great opportunity for reuse and the KMS team wanted to explore some of the different behaviours and how they could potentially be used in the application. The following table lists some of the behaviours and their application for the KMS team:
|Users||The ability to have users login and access parts of the application that they are authorised to. Doctors, Nurses, Admin, and other roles can access different parts of the application.|
|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.|
|Dashboard||The hospital staff will be presented with insight into the hospital practices. They can slice and dice the data. Like 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 hospital workflow to ensure they get the best possible care.|
The behaviours hold a lot of power to be reused. At the beginning of an estimation it is important to find our 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 behaviour can fully, partially, or not be used for its implementation. The results can be seen in the following sketch; 34.4% of the requirements can be fulled 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 behaviours 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 behaviour 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 was aimed at getting a deeper understanding of how a codebot works.
Can we extend?
To see how they could manipulate or change their code alongside a codebots behaviour, it was decided to do a tech spike on the CRUD behaviour. 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 search and a different way to select associated data. In this following video, you can see what was achieved in a single day by Tom, the developer.
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 next screenshot). He was able to modify the code so that it could do two things different: how an associated entity is displayed when it was clicked on; and search for an associated entity in the search bar so it displays a modal (popup). He was able to do this as you can see in the above video. This demonstrates that the code is usable by developers. It will also means that the new application can be built with a similar feel to what the existing KMS users are used to, this will 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. To address one of their concerns; Could KMS do something unique and different for 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. The finally was 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. In the following video, you can watch Kellie using the platform and bots to tech spike some of the prototype.
The KMS team were able to gain confidence from the scoping exercise. 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, the developer. That is a huge running start for when development kicks off.
KMS is now underway with a legacy migration and they are off to a great start. They are leaning into the bots to do the heavy lifting on the project, allowing the wider team to use their creativity to solve both design and technical challenges. The estimations say that using the codebots technologies that it will take 32% of the time compared to a traditional route. That is a massive saving in time. Time will tell and we all wait to see the result. If you want to see even more detail, watch the longer 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 the risk is there, then you can put mechanisms in place to help ensure the estimation matches the reality as it plays out. For the KMS team, they acknowledge the risks associated with what they are undertaking and they are not going in blindly. They are shining a torch into the corners of the legacy system to make sure that they minimise the nasty surprises that might jump out at them.
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 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.