Application Maturity Mental Model

TL;DR - Applications are like people*, and go through maturity phases (gestation, newborn, weaning, school, adulthood, maturity, retirement). We should encourage a strong "family" structure around our applications. 

While it does "take a village", typically, a strong family structure has been shown as the best indicator of maturity in people.



An architect I worked with once talked about how applications are like people. They go through phases of life and maturity, from conception to heartbeat, to a screaming & messy entry into the world. Then on to feeding, walking & weaning, potty training, going off to school, adolescence, moving out of the home, college, 1st job, etc. 

This metaphor is very powerful, and with that architect's license, would like to extend it further into how we support our applications.

If we set some smilies in this model, it will be helpful.

Stages

Anthropomorphic Equivalent Application Equivalent Notes
The nursery Sandbox & Development Environment This is the early come life - this is where feedings, diaper changes, first steps and such are done.
Early Schooling Test Environment The this is like walking for the first time or going to school for the first time.
High School/prep school Staging Environment This is where we are really tested, bullied, etc.
College Performance Environment Advanced testing happens here, preparing subject for great success throughout life. Usually expensive
Trade school/internship Beta This is where real hands-on training and learning happens. Usually, everyone is quite patient with issues here
Adulthood/employment Production This is where the application begins to be a productive member of society

Actors

Anthropomorphic Equivalent Application Equivalent Notes
Parents Developers, Architects Those who create the vision and design for the application, and nurture it in very early life
Coaches/Teachers Testers Those who help put the application through its first challenges
Professors Load testers/Chaos Testers
Trainer/Colleague SRE/App Ops Those who help train the application in production
Siblings Suite of applications working together Understanding your relationship with your siblings is really important!

Events

Anthropomorphic Equivalent Application Equivalent Notes
Marriage/Joining a Team Integration with another component. dependencies of applications on each other, integrating with a suite of applications.
Adoption Being acquired
Parent/Teacher conferences Developer Checking in with Productions Team to see how application is going
Coming home for the weekend to do laundry Applications need some extra help to get moving. This is like when an application sends an alert that isn't immediately actionable

Other interesting thoughts in this thought model:

Anthropomorphic Equivalent Application Equivalent Notes
Deadbeat parents Developers who "throw things over the wall" do not encourage healthy & mature children or working applications.
Boomerang children/failure to launch Applications which never really make it to maturity, or always need to be taken care of by developers
Orphans Applications whose developers have left the company
Foster parents Developers that pick up the maturation of an application to adulthood
Allergies Characteristics of an application that only a parent would know that could be incredibly harmful to it.
College Application/Employment Job Application/HR Personnel file Evidence of Releasability
FBI Background Check FedRamp or other Compliance Certification
Juvenile delinquency Bugs found in pre-production
Arrests/Jail time Applications not performing well in production
Fresher/Intern Application just into production, needs lots of training by a mentor & advice from developers
Grades in school/Trade certifications/Annual reviews at work Service Level Indicators

*Exceptions

As of right now - applications don't have self-actualization needs. Yet. However, the rest of the model still works.  


Notes/Links/References

https://drspock.com/

Comments

Post a Comment

Popular posts from this blog

Site Reliability Engineering Maturity Model

After a lot of study of the Google SRE books , I came up with this SRE framework.  The idea is that you could judge a development team's reliability maturity based on this framework. As teams begin to adopt various characteristics of the framework, we would expect that their reliability will go up.  I hope this is useful to you as you start your journey in applying these principles!  The first step will be to do a self-assessment of the current status of your Product Team for each one of the identified capabilities. Define the desired end-point at the end of the next improvement cycle, a cycle can be a month, a quarter, a semester ... every team can define their improvement cycles although a good start would be to set quarterly targets to be able to define meaningful actions. Identify the actions you will need to achieve the desired end-point. Characteristic Crawl Walk Run Risk Observe it/Measure it (SLIs) Set a target (SL...
Read more

Revolutionary Ideas Evolved over Time

I’ve been listening to an audiobook about the American Revolution that happened in the late 18th century in North America, and it got me thinking about what we have come to call DevOps. If you are in the midst of fomenting a DevOps Revolution at your company, your patience is wavering, or you are struggling with the half-measures and compromises (“That’s not revolutionary, that is evolutionary”), indulge me for a moment while I address an older idea in a new light: Revolutionary ideas evolved over time. Let me explain. When Americans look back at the American Revolution, generally, we think of a few very principled, very intelligent men deciding to go against the stodgy monarchy who was insufficient to meet the needs of a growing empire and a modernized world. (At least that is what I think of). (Sound familiar? Keep reading.) We then relish in the glorious revolution of freedom and fireworks and Francis Scott Key’s anthem “that the flag was still there”. An impossible victor...
Read more