1 / 156

Killing Zombie Software - Technology Exit Planning

Whether you are a big, sprawling MNC or a sleak, sexy start-up, zombie software will quickly invade your product platform. This deck is meant to start a conversation on how our industry can fight the zombies.

selenasol
Download Presentation

Killing Zombie Software - Technology Exit Planning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. KILLING ZOMBIE SOFTWARE please design software to die gracefully http://www.flickr.com/photos/scottpoborsa/

  2. PART ONE WELCOME TO THE ZOMBIE APOCALYPSE

  3. whether you work in a mega MNC or a sexy lean start-up

  4. today’s software professional is at the heart of a zombie apocalypse.

  5. for the last 30 years, we’ve learned how to build more stuff, faster

  6. but we’ve spent very little time learning how to get rid of it.

  7. the result is platform sprawl

  8. with software products and features that are long dead, but which still walk the earth

  9. “grawwww”

  10. this is not sustainable.

  11. if we don’t act now, the zombies will win

  12. this deck hopes to start a discussion about how we escape the apocalypse and kill all those software zombies!

  13. IDEA ONE ALL SOFTWARE NEEDS TO DIE

  14. here is a law of nature.

  15. all software needs to die.

  16. either the business needs will change

  17. or newer technologies will arise

  18. either way, all software will eventually become obsolete.

  19. (and when I say eventually, given biz / innovation speed, I mean 3-5 years for a big firm and 6 – 12 months for a small one)

  20. so, knowing this

  21. one thing is clear

  22. we need a graceful way to get rid of obsoleting software.

  23. IDEA TWO IT IS HARD TO KILL SOFTWARE

  24. unfortunately, shuffling off this mortal code is not so easy.

  25. killing software can be near impossible.

  26. there are technical reasons for why this is true.

  27. for example, in complex platforms where many bits of software interact upstream, downstream, and service to service

  28. changing one piece can have profound impact across the sprawl.

  29. decoupling a dying technology can become a feat of engineering

  30. like a mad game of jenga.

  31. and there are people reasons too.

  32. killing software can easily look like (or actually be) killing jobs.

  33. newer business flows or gadgetry render existing personal skill sets obsolete.

  34. making way for the new is scary and/or threatening to the people that own it.

  35. moreover, there are budgetary reasons

  36. supporting all this legacy software is extremely expensive.

  37. we spend so much keeping the platform afloat, that we’ve nothing left to dig ourselves out of the hole we’re in.

  38. (today some firms spend 60-70% of their IT budget maintaining the existing platform)

  39. IDEA THREE IT IS EASY TO MAKE NEW SOFTWARE

  40. worse yet, not only are we not killing software, but we’ve just enjoyed 30 years of high-speed build-out.

  41. so for every 1 zombie we failed to kill, 9 more future zombies arose.

  42. in the growing economies from 1980 to 2008, businesses simply threw money at the platform.

  43. the mantra was build, build, build!!!!

  44. and where we could not grow organically

  45. we merged, and we acquired

  46. adding duplicative software on top of duplicative software.

  47. as a result

  48. organizations today are living with massive and intractable platform sprawls

  49. made up of dozens, hundreds, and in many cases thousands of vestigial bits of software

  50. of which, perhaps, 30% is actually needed

More Related