4 minute read

The other day I was working on updating my visuals to describe the systems delivery lifecycle (SDLC) for software. Three new depictions arose.

  

Why does the SDLC need a better visual?

I'm doing this because I've never been afraid of change, and the visuals still in use today depicting the phases of delivery are disturbingly incorrect to the modern lifecycle. Take for instance a few common illustrations:

  

Waterfall, cyclical, even the dreaded CI eternity symbol, all crap as far as I'm concerned. The linear fallacy is just too much to bear.

So I got to work on the whiteboard, to play around with some ideas. I really tried to stick to the "design, build, test, deploy, manage, monitor" phase reductions to simplify my life before round 2 coffee.

Is the SDLC Just a Fractal?

The idea that even a man-made structure like wire transmissions* could elicit fractal patterns just like nature got me thinking about other man-made structures...software and processes...are there fractals in what we accomplish, despite our incredibly synthetic rules and predisposition for straight lines? I've always loved this painting:

Fractals have changed my thinking about perceived complexity as a result of a simpler algorithm. There are fractals in all of us, our heartbeat graphed out show how nature may just be surface complexity to our perceived reality.

So I drew out the 'waterfall' (yes, pun intended) like a Kanagawa painting:

* Reference to 'Hunting the Hidden Dimensions' documentary on Mandelbrot's early work at IBM related to SNR telephone clarification algorithms.

If you haven't read 'An Eternal Golden Braid', at least watch a few moments of the following video, I implore you.

[embed]https://www.youtube.com/watch?v=j5ty2s1TZvE&list=PL068ES-0ca9CSIp5OPGI5RXB3k5XgYRxF[/embed]

So this works well for categorizing the levels of detail that a large-scale operation like rolling a new idea out into the market requires, but there's no link to the continuous aspects of the process. Next.

How Is the SDLC Like Digital Public Transit?

After going back to the 'wheel' mentality, I realized that there are just some parts of the SDLC that don't always connect to each other, or at least not every time you complete a full cycle. Things like 'build' in a TDD shop do not block 'testing', so forcing everyone to go through the 'build' phase is wrong.

If instead we were to write out each 'phase' of the SDLC in clockwise fashion in a circle, then draw directed vertices, we'd get something like a subway map, like this:

 

So that's interesting, certainly more palatable than the fractal illustration for most people, and shows a bit of symmetry, even if just as a shallow concept. The thing I like the best about this one is that you begin to see logical byproducts result from visualizing the paths through this state diagram.

If you draw a line from right before 'design' until right after 'test', you'd see how the three design/build/test phases that traditionally developers would do and operations wouldn't touch are separate from the deploy/manage/monitor phases, which mirrors how proficiency in either (but not both) roles usually decides which set of phases you'll be spending most of your time on as a member of a 'DevOps' team, either primarily a developer or an operations person.

Does the SDLC Need Some Taoist Whoop-Ass?

Then things got really weird. I realized that the closer each of the phases are depicted to one another, the easier it was for me to keep in mind that it was possible (sometimes fortuitous) to jump from phase to phase as organically happens in real DevOps / agile teams.

Instead of putting the elaborations (curls, paths) on the outside of the continuous structure (circle), they should be inside it. At first I drew it like a '69' which I later remembered has cultural connotations that are best avoided. Flipping it around, only later when I was out to coffee with some co-workers did someone point out that it looks like the Taoist Taijitu (paisley) symbol. That endeared it to me further:

 

(From top-right in clock-wise order: design, build, test, deploy, manage, monitor)

Any time I can work in some pseudo-science or eastern philosophy into a technical topic, the added mystical sense is a bonus as far as I'm concerned. You come off looking all cool and a bit nuts at the same time.

Further Detail on Why I Don't Like Existing SDLC Paradigms

Formally, my problems with established paradigms for how to visualize the SDLC are:

  • The left-to-right approach as a one-direction trip is inaccurate to how effective people work together, not separate; there are loopbacks thanks to humans
  • The 'fix' to take a waterfall process and just wrap it around on itself to make a continuous process just seems lazy and incomplete
  • Most depictions have no symmetry and no emergence of 'DevOps' role separation

People will use what makes sense to them. I will continue to elaborate these ideas until they bore me.

You may also enjoy