afongen

Based on a recommendation from Gunnar, I read The Starfish and the Spider by Ori Brafman and Rod Beckstrom. I spent all but the last couple chapters wishing that I were not reading it, but in the end it was worth it.

For most of the book, the core message is, “Look! Decentralized organizations that work!” Spiders die, starfish regenerate. Based on the reaction of the few intrigued people I talked to about the book, I’m sure this is a revelation to many, but since I’ve been interested in decentralized organizations since, oh, forever, this observation alone isn’t all that compelling. Certainly not enough to build an entire book around. They provide decent examples — the Apaches, Alcoholics Anonymous, Wikipedia (of course), Burning Man, P2P filesharing — but not a terribly nuanced examination of why decentralization works, or in what scenarios it can be successfully applied, or where it doesn’t work well.

Or so I thought. As I explained the book to my mother (one of the aforementioned intrigued people) I realized that they had provided an interesting analysis of factors that help decentralized organizations succeed in the face of increasingly centralized opposition. When facing a decentralized threat, whether it’s file sharing, terrorist cells, or botnets, one would do well to pay attention to the failures of centralized models. Becoming more centralized tends not to work.

I was surprised to find no mention of Dee Hock, Visa, and chaordic organizations, but that might stretch beyond the narrow confines of the authors’ intent.

In the final chapters, Brafman and Beckstrom at least begin to explore what I had hoped would be the meat of the book: merging decentralized organizational models with centralized ones. Or rather, using decentralized structures within a centralized organization. As with the rest of the book, there’s a rapid-fire series of examples, and a longer exploration of how this plays out in one company (GM). These are just a couple chapters in a short, easily read book, so I’m still a little disappointed by the depth of the analysis. But if you’ve got yourself a bus ride, you could do worse than to spend a little of that time in the last third of this book. If you are completely puzzed by the very idea of decentralized organizations, then you should definitely read it.

Now I’m working my way through the rest of Gunnar’s recommendations.

For the last few years, my employer has been working on a project for system-wide — dare I say “enterprise”? — identity and access management. As I have more than a casual interest in digital identity and identity management, I’ve been watching the project out of the corner of my eye. For the past year or so it’s been increasingly clear that progress is being made and they will release something valuable to the organization and ultimately to our students. One of the important activities this year is to hire staff to work on the project. They posted positions, and a few weeks ago I joined the team.

So what will I be doing? According to the position description, my first responsibility “is to be the senior IAM technical security engineer involved in the design, development, and implementation of MnSCU’s enterprise, multi-campus IAM system.” I will also have “primary responsibility for the daily support of MnSCU’s enterprise IAM system – including the development, QA, and production environments.”

Holy frell, what have I taken on?

If you look at an org chart — which does not show the exceptional people from other groups that participate in the project team — I’ll be the developer on a team consisting of an architect, a business analyst, and a developer. But on such a small team, being a developer means more than just writing code. I need a broad and deep grasp of everything we do, from requirements through to the hardware. It also means day-to-day support of our software and a rapidly growing user base.

It means I’m really damn busy.

After years of being underchallenged, I am at last facing a serious challenge, trying to make sense of all the work that’s been done — in the past year especially — while still trying to contribute in a meaningful way. I am being pushed, and to be honest, I feel a wee bit overwhelmed. Every now and then the scale of what we’re trying to do hits me, and the feeling that I am up to my eyeballs in work is replaced by the sense that I am so far underwater it’s not even funny.

I’m loving it. And I’m hoping that my coworkers won’t strangle me too soon.

It took me a few days to notice that Tim tagged me. I am supposed to “Pick up your nearest book and go to page 123. Find the fifth sentence, and post on your blog the next three sentences. Acknowledge who tagged you, and then tag five more people.”

There are two books equidistant from my chair — and as it turns out, the same would be true were I at home or work: the second edition of Ross Anderson’s classic Security Engineering, and Adam Shostack and Andrew Stewart’s The New School of Information Security. I’ll choose the latter because it isn’t so damn big and doesn’t hurt my arm so much to pick it up.

Most children who go missing do so in custody disputes and are taken by someone they know and trust. The advice to “never talk to strangers” doesn’t address the main cause of children going missing, and it puts them at risk when they become lost. In 2005, 11-year-old Brennan Hawkins got lost in the Utah mountains.

I don’t want to leave the next sentence off because it’s a good point: “For four days, he avoided searchers because he was afraid to talk to strangers.”

Shostack’s book announcement gives a good overview of the book, and Gary McGraw’s recent interview with him on the Silver Bullet Security Podcast should give you a better idea of where they’re coming from.

I’m not going tag five more people. Just cuz.