Should you attend Velocity and DevOps Day? Yes.

 Quick questions...

• Is IT Operations important to you?
• Do you build and/or operate a revenue producing online service?
• Do you want to meet and learn from the best in the business?
• Are you looking for a job? or looking to hire IT rock stars? 

If the answer to any of these questions is "yes"... then you need to be in Silicon Valley the week of June 22 - 25, 2010.

First up, we've got O'Reilly's Velocity Conference from June 22 - 24 in Santa Clara, CA.

Velocity is the premier Web Operations and Performance conference (and from what I understand is O'Reilly's fastest growing conference). If you want to hear from the people who are pushing IT Operations to new heights and powering the biggest successes on the Web, Velocity is the place to be.

This isn't hyperbole. I've been to all of the Velocity Conferences and the hallway conversation alone is worth the price of admission. And that's before you add in value of the the excellent presentations. It's one of those conferences that always seems to manage to produce a handful of presentations that are talked about and referenced for the rest of the year (if not longer). 

This year, three of the the dev2ops.org contributors (Alex Honor, Lee Thompson, and myself) are speakers. Hopefully we'll live up to the high standards that those who have come before us have set.

Click on the banner below for more information and use the code vel10fsp for a 20% discount.

The day after Velocity, Friday June 25, is the DevOps Day Conference in Mountain View, CA (about 10 minutes from Santa Clara). DevOps Day is a one day free conference dedicated to discussing all topics around improving the interaction between what is traditionally considered development activity and that which is traditionally considered operations activity. As the name suggests... it's a day dedicated to an open discussion about all things related to DevOps! 

The event is following a unique single-track all panel format (with a few sets of "ignite style" lightening talks sprinkled in for good measure). The panels are designed to be highly interactive with the full audience. As you can see from the panelist list and the registered attendee list, the panels and the audience will be full of rock stars in our field.

Perhaps I'm biased since I'm one of the organizers, but this is shaping up to be a truly great event.

The conference is free, lunch will be provided, and there's going to be free beer afterwards! 

Click on the graphic below for more information and to secure your spot.

 

People over Process over Tools

Working as a consultant in the trenches, I find myself practicing an implicit methodology that helps me focus on short term improvements while working towards long term gains. The methodology applies to many aspects of the software development life cycle that spans development, test and operations.

The methodology begins by looking for the right people or person to fulfill a needed role. Secondly, ensure that role's process is correct and optimal. Lastly, improve the process' efficiency by reducing steps through some tool based automation. Notice, tools and automation are last! I call this methodology: People over Process over Tools. It's my mantra and I sound like a broken record about it.

The people I work with are typically techies and like many techies, there is often a preference to first react to process problems with tools. The thinking goes like this: tools institute a methodology, embody a process and through their use enforce a policy. Tools can seem like a magic bullet.  Address all the issues at once in a new tool project, the thinking goes.

What I have found is this: selecting and instituting a tool is almost always the worst first step in improving an important function, especially when the function is spread over more than one team. This is because it is almost always simpler to look at how the function is being done -- who does it and how. Choosing, developing, rolling out a tool is an investment and one that might not pay off if the right people and process are not first put into place.

Aligning the team to the function and then fixing or optimizing the process they use is almost always much more straightforward and is a prerequisite to the use of new tools or automation. 

People

Often the very easiest step to improvement is making sure there is a person responsible for the function at hand. This seems obvious but often organizational dislocation results in ambiguities about what person or group is actually responsible. For example, a process might be repeated inside several groups. Roughly the same process may occur in each group, but there is no sharing of knowledge or procedure between them. To address this kind of dislocation, the organization might centralize that function into one role or set up a meeting to ensure common practices. In other examples, perhaps the needed skill set does not exist for that function. The solution in that case would be to define the needed skills for the role and offer training or fill that position accordingly.

Process

The right people might be on the job but how the job is done is not correct or is very difficult. Incorrect processes are those that do not end with the desired result. Incorrect processes might have undocumented assumptions or preconditions. Steps might not be explained accurately or presented in the wrong order. Often processes evolve over time and become dogma even if they present many hurdles or exceptions to the person that performs it. 

In these cases, an eye towards process (re-)engineering can help. Concentrating on accuracy and order are first priorities. Optimization and reduction of duration must come later. 

Tools

Once the right people are performing the right process one can look for further gains by using tools to automate steps… assuming it is worth the cost and effort. I always like to emphasize the cost and effort side of the decision. It may be obvious to tools developers how automation will make drastic improvements but they might not build a business case needed to support their effort over the long haul.

For tool makers with the right skills, a development project that yields productivity gains always seems like a no brainer. But how do they prove it to their management? More importantly, how can they increase their chances that their tool will be adopted by the people that will use it as opposed to those people working around it. I have found that building a relationship with the future end users is always the first and most important step. 

Rather than begin with code, begin by looking at the process from an organizational perspective. Make sure there isn't dislocation at the hand off points. Make sure the procedure is correct and manually repeatable. Only then look for available tools or a justification to write your own.