On modeling dependencies in complex systems...

gistfile1.txt

Excerpt from an email I sent during May 2011:

I've been doing some research into this whole DevOps space as part of
my efforts focused on improving our continuous delivery pipelines at
<REDACTED>. Of course one of my main avenues is to harness otherwise
non-productive time listening to podcasts, and yesterday I happened
upon DevOps Cafe. It seems this guy named Tim Berglund did an
interview with these guys last summer around the theme of his
"Complexity Theory and Software Development" talk. ;-) I listened to
about half of it on the way in to the office this morning.

At any rate, I have to let you know how incredibly intrigued I am by
the ideas you're presenting. All of this harkened back to Esther
Derby's talk at Uberconf last year - and you mentioned her work as
well. What's really interesting to me is that you've put a framework
around some thoughts that I've had baking in my mind for quite some
time now. It's this rather emergent connection to DevOps that happened
because you and one of the hosts happened to connect in Ireland that
brought this to the forefront of my thinking.

Of course you know I work in the ENTERPRISE (stay with me now...).
You're looking at roughly 250 folks managing a multitude of different
systems at different layers of abstraction - from client-facing
applications all of the way down to power and cooling in the data
center and everything in between. There has been a continued and
understandable desire amongst management and technical leadership to
know "Who owns what?" A simple database was even built (called WOW
:-/) to house this information. One can imagine how successful an
endeavor like this might be, and he or she would be correct.

The problem lies in the fact that we're not looking at a
two-dimensional problem that can neatly fit into a table. It really is
a graph, as you say. And what's important is not so much the nodes,
but the number and nature of interconnections and the type of network
that emerges, etc., etc. I may have applications that depend on each
other, they may depend on a different virtual machines, they may
depend on a single node of a ESX cluster, it may depend on a storage
network of some point. Different people groups might "own" different
things. Some nodes will fall into that "critical" category where
failure causes as you say "poop to hit the fan."

So my thought has been - why not build a tool to model enterprise
architecture in this way? As I have been thinking about NoSQL over the
past few months, and graph databases specifically, this was one of the
first problems that came to my mind as a potential "learning exercise"
for a tool like Neo4J. What I didn't have was the thought framework
that made the problem make sense. Thanks for that. :-)

Imagine it...I model my system and then start simulating what happens
when nodes fail. Then take it to another extreme...find a method for
allowing graph nodes to monitor the health of their real world
counterparts. When things go down, you could start triggering alerts
proactively rather than waiting for things to fail. If you modeled the
different people groups as nodes themselves, you could start alerting
folks that their systems are at risk. Heck, you could even proactively
notify user communities.