Products, Not Applications

https://pixabay.com/en/meeting-team-project-teamwork-1170770/
diema

The other day I wrote something about DevOps:

We shouldn’t be lulled into the idea that DevOps is restricted to just the technology pieces of development and operations, it is pervasive in nature and covers the entire SDLC, including the management of projects.

So, while puttering around on those interconnected networking pipes called the Internet, I came across the TechBeacon fifth annual State of DevOps report.  And it stated that:

This year’s report shows how improving the entire product lifecycle – from initial product planning to quality and security assurance, to customer feedback – speeds up delivery while improving quality, security and business outcomes


Although we mentioned different things we both commented on the fact that it is the entire lifecycle.  But here is the interesting part, I mentioned the software development lifecycle (SDLC) but they mentioned the “product” lifecycle.  There is a subtle cultural difference that I think we need to explore.

A traditional SDLC creates an application and then, essentially, abandons it on the curb waiting for a maintenance team to come by and pick it up.  The end result of an SDLC exercise is an application in all of its naked glory.  That’s awesome.  Well, it’s also a little anti-climactic, don’t you think?  What comes next?  It’s like seeing the season ender for a television show and then being told its canceled.  What happens to the characters?  Does Bobby tell Sue Ellen the truth?  Did those boulders really crush the car that Desiree was driving?  And will Jimmy Bob ever learn to walk after his ukelele accident?

A product lifecycle is similar to an SDLC in that there is an application (aka “the product”) produced at the end of the development cycle, but there is no transition to maintenance.  The team continues to build the product, adding enhancements, making modifications and generally adding things that the customer asks for.  A “product” goes on forever under the care and attention of a product manager.  When that product is no longer needed it is discontinued and then, only then, does the product manager stop the care and feeding.

Most organizations adopt the SDLC approach where something is built and then the team goes on to build something else.  Even if they are building the next version. The idea of building “products” over “applications” seems like a no-brainer, but it is a serious culture shift to do it properly.  Products have a continuous deployment type of mentality where new versions are deployed frequently to continually upgrade the product and make it more valuable to the end client.  Applications are released periodically, like on June 1st, to force people to upgrade to the latest version to get more money.  (And out came the cynic.  Sorry about that.)  Products have a team of people associated with them from start to end – there is no handoff to maintenance.  Applications are built and then tossed over the fence.  The true Agile methodology, in particular, the Scrum variation, works very well with products as it is all about continuous improvement.

Products versus applications.  It’s more than just a name change, it is a cultural perspective.

Leave a Reply