Yesterday, Parker Snyder of Migration Services at HOSTING shared his thoughts on what went wrong with healthcare.gov. Today, he shares his thoughts on how mission critical business applications can be developed properly, to avoid embarrassing mistakes.
Parker says to start by taking your projects end goal, in its entirety, and add every involved component together. Observe where the scope crosses boundaries of solutions. For illustrative purposes, let’s think of this in terms of an MS SQL cluster… what real boundaries does it cross?
- Abstraction layers (i.e. VMware, disk replication, etc.)
Above, there are already 4 systems with intricacies in and of themselves that increase the scope exponentially. Now, imagine that you had built this cluster and released it to the world using our second complex system rule mentioned yesterday. This rule assumes it is completely broken. Where would you look?
At a basic level, there are 4 items directly above that can highlight the precise areas where you would at least start to diagnose such a system.
The build it once, throw it out, and then build it a second time rule can help us understand how to simplify the system.
- In what ways could the initial scope be reduced?
- Of those, can you further simplify their underlying systems?
Now, we get to throw Parker’s favorite variable at the system once the second iteration is built — those pesky humans. Obviously we don’t have hundreds, thousands or even hundreds of thousands of unpredictable people on standby, but we can at least create a decent simulation using modern cloud technologies.
Simple profiling of a few test groups and creating the basic “crash test dummy” of a person that continually hammers on the website until it hits a wall, will begin to show true areas of concern for the systems. Analysis and focus on these areas is where improvements will be found. Once you have run the crash test analogues in your system, and redesigned it, you can go back to the system. Here, a final evaluation can be made as to how well your combination of capacity, load, interaction and moreover, complexity can be adjusted to make your product truly solid. In the case of healthcare.gov, the system wouldn’t have buckled when so many people attempted to sign up for health insurance.
Parker recaps his thoughts with a few very simple, but very important takeaways:
- How big is the product in execution?
- Assume it was done incorrectly or not as well the first time, and build from scratch with those lessons in mind.
- Simply build simplicity – It’s simple.
- Models are nice, scripted models are better, and a variety of virtual equivalents and simulations, is best.