Avoiding Waterfall Governance

A brief follow-up to the post I wrote on governance topics.

As we operationalize the cloud, we will eventually get to a place where we have solid policies and process around everything on our governance to-do list and more. However, I think it’s critical, as Sharif put it, to “think like a startup” while we “operate like an enterprise.”

The first thing any programmer learns about managing a development lifecycle is to forget “waterfall.”  Trying to nail down 100% of the design before coding is not only a waste of time; it’s actively damaging to your project, as changes inevitably come later in the process, but you’re too tied down with earlier design decisions to adapt.  I’m sure no one in this organization doubts the value of agile, iterative coding.  We do our best to establish requirements early on, often broadly, refining as we go.  We get feedback early and often to constantly guide our design toward harmony with the customer’s changing understanding of the software as it grows.

We should apply the same strategy toward our cloud initiative.  Because it’s so easy to build and tear down infrastructure, and because our host and application deployments will be scripted, automated, and version-controlled, we have the luxury of trying things, seeing how they work, and shifting our strategy in a tight feedback loop.  Our governance initiative is very important, but it’s also important that it’s not a “let’s decide, then do” process.  That’s why I didn’t just ask for people to come back with designs on paper for things like IAM roles and infrastructure.  I asked that they try things out and return with demos for the group.  Let’s be iterative; let’s be agile.  Let’s learn as we go and build, build, build, until we get where we want to be.

Governance To-Do List

It’s no secret that we are making a push to the cloud.  As Sharif noted in his last blog post, there are many compelling reasons to do so, financially, technically, and organizationally.  However, no one should be under the impression that we are forging ahead thoughtlessly!  We need to come together to understand the many implications of this move and how it affects nearly every part of our jobs.

To this end, we convened our first meeting of the ND IaaS Design Governance group.  In the room were representatives from system administration, networking, architecture, and information security.  On the agenda: a long list of open questions about the implementation, policy, and process of moving into Amazon.

I’m happy to report that we made excellent progress on this list.  For the first half-dozen, we either made policy decisions on the spot, assigned ownership to certain groups, or assigned volunteers to learn more and present a recommendation at the next meeting.  As we continue to meet biweekly, I’ll spotlight the decisions made on this blog.  For now, here’s a glance at the broad topics.

  1. Designing / managing Infrastructure
  2. Security Groups
  3. Account Management
  4. Key Management
  5. Multitenancy
  6. Managing Instances
  7. Version Control
  8. Development
  9. Provisioning Instances
  10. Deployment Policy / Process
  11. Tagging / Naming Conventions
  12. Scripting
  13. Connecting to ND resources
  14. Licensing
  15. Object Ownership
  16. Budget
  17. Other

For the full document with sub-bullets and decisions made from the first meeting, see this document (ask me for access).  This is certainly a first draft.  I can already think of a number of things we should add, not the least of which is how our future change control / RFC process will work.

But things are already happening!  Before I left Friday, I stood in on an impromptu design session with Bob, John, Jaime, and Milind.

IMG_1358

is this what a think tank looks like?

IMG_1359

this could be your next data center

So thank you to everyone on the committee for your dedication and excitement as we move forward!