OpenStack Nerd, CCIE, DevOps Junkie

Changing the world, one person at a time

OpenStack Nerd, CCIE, DevOps Junkie header image 1

Why I think Kyle Mestery is right for Neutron – OpenStack PTL Elections

April 7th, 2014 · 4 Comments · OpenStack

I think the biggest challenge with OpenStack right now is finding a healthy balance between all user archetypes that contribute code.

These include (but are not exclusive to)

  1. Manufacturer

  2. Integrator

  3. Operator

  4. Educational Contributor

  5. Individual Contributor

Right now, there is a risk of the sometimes conflicting interests between each of those Archetypes creating situations that stall forward progress of this great project. We need the Neutron PTL to hit this issue straight in the face before it gets toxic.

Why Kyle is the right person for Neutron PTL

NewImage

First, let me say that Mark is an amazing PTL. His leadership has been great, and I’m sure will be great in the future. As an employee of an Operator (Yahoo) he is a close to neutral ground as we can get.

That does mean however that he may not always be fully aware of all the ways that manufacturer politics and angling can manifest themselves in a project.

This is where Kyle comes in. Kyle works for Cisco (specifically an OpenSource spin in called Noiro).. but still Cisco. I have known Kyle since 2012, and in that time I have seen Kyle at ever turn do what is best for the community, even when that may not have been “completely the best thing” for his employer.

Day in and day out, I see Kyle act like I feel (and hopefully how I do). Exemplifying the “Badges Away” philosophy, and using OpenSource to build a bridge of collaboration between parties that at many times compete with each other. This leadership style is demonstrated in OpenStack, Open vSwitch, and OpenDaylight.

Kyle will be under scrutiny

The fact is, that with a manufacturer employee taking a leadership role in a project there is always a risk that a manufactures agenda will be pushed.

That however is a great thing, Kyle will be under the highest levels of scrutiny. Him taking this role will require a new level of transparency around manufacture dev reviews and approvals, and will result in increased health as the project as a whole.

Kyle’s biggest task as PTL

OpenStack is maturing from a project full of beards and tattoos, to a place where suits are as common as birkenstocks. What is happening is that the same market manipulation tactics that are rampant in IETF, T11 an IEEE are making their way into OpenStack (They were a heavy undercurrent in the Hong Kong summit).

Kyle’s biggest task that I see is setting up transparent policies that discourage standards body manipulation techniques, and ensure that the contributors outside of the manufactures have an equal chance to both share the burden of contribution, but also enjoy it’s benefits.

At the end of the day, in the few years that I have known Kyie, he has stood out as an individual who loves this community. Who is connected to us as a whole, and who also strives to find “balance in the force”

This is why I am eager to see Kyle elected as the Neutron PTL. If you feel the same way as I do, I encourage you to make your opinion known too.

→ 4 CommentsTags:···

Is Shadow IT (DevOps) Disruptive or Transformational?

March 27th, 2014 · 1 Comment · devops, ITIL

Today Mark Thiele (EVP at Switch) posted an article drawing comparisons between Shadow / Classic IT, and George Washington / Donald Trump.

While I actually disagree with characterization of Washington as Classic IT (I think the myth of Washington is much different then the historical documents of a man drawn into a struggle by duty) I’ll stick with Mark’s use of George Washington as classic IT, and Donald Trump as Shadow IT.

In his post he describes some interesting alignments of Trump to fulfill the business need through “Any means possible” and GW (the founder of our country, not the “Other” one) as the keeper of the status quo.

I feel that Mark may be implicitly communicating one assumption, that Shadow IT teams are Rogue, and less aligned to the goals of the business as a whole.

Let me share my take.

Pressure from C Level (Executives) to Dev teams

What most people in “Classic IT” organizations don’t see is the extreme pressure to release quality code that is put on a modern software development organization.

As far back as 2009 executive reading such as Harvard Business Review have been discussing Agile. In 2012 this started to be commonly communicated as the DeFacto standard for high speed, high quality product development through senior executive teams.

The result of this has been a changing expectation of performance from a development team. In the past you may have had one to two years to develop a product. Now the expectation is that you have 90 days for the first release (at max) and release every month after.

Dev Team Alignment to biz

This expectation has been core (in my opinion to the creation of “Shadow IT”. In a company, software development efforts are normally funded out of requests by the line of business (normally approved by the Exec team). The work done is heavily skewed to towards the introduction of new features that improve the competitiveness of the company and / or it’s employees.

The key concept here, is the VP of software development is normally closer aligned to the goals of the business then any other technology organization in a company. That organization is tasked with, and accountable for delivering these products in a very short time, with low defects. All while not drastically growing headcount.

IT Alignment to Dev and Line of Biz

IT organizations more and more are reporting up through the CFO. (CEO >> COO >> CFO >> CIO >> VP-IT). The exec focus and leadership mandates are generally going to be containing costs of delivered services, as well as following established management guidelines.

I hope you see the rub in this organizational structure. Classic IT Ops is more commonly managed by.. well accountants. The pressure of this executive direction is pretty consistent, and will drive management behavior in organizations.

The sad fact, is this reporting structure drives a disconnect between IT and the line of business when business is changing. (While optimizing for efficiency when the business is in a steady state) I believe this is core to the current disconnect between Classic and Shadow IT.

Classic IT – What most miss

Let’s expand on this disconnect. A well run IT organization has five area’s that they focus on.

  1. Service Strategy

  2. Service Design

  3. Service Transition

  4. Service Operation

  5. Continual Service Improvement

Inside of each of these area’s are a number of functions that are critical to a healthy thriving IT / Business relationship. However when optimized for minimized Opex/Capex (primarily Opex btw) is that IT organizations tend for focus on minimal area’s in elements 2,3 and 4. They mostly ignore Service Strategy, significantly ignore Service design, and rarely take a serious stab at Continual Service Improvement.

The Manufacturers role in this failure – “Is It Enterprise Ready”

The sad fact is, that in the most common implementation of this failing IT strategy – Service Strategy, Service Design and Continual Service Improvement are effectively outsourced to the Manufacturers selling them stuff.

IT organizations have been trained, incented, manipulated, whatever to rely so heavy on outside forces to tell them what to do and or buy, when to do it, how to create services to expose to the business.

This has created a situation where classic IT dependancy on outside consulting and influence for service strategy, design and improvement has created a vacuum. Few of these classic sources have real solutions that service modern software development. Furthermore, many of them are threatened by the “Next Generation” of IT services, and actively slow down adoption or creation of these services.

DevOps is just good ops

Shadow IT is not evil, though many times it exists outside of the IT governance initiatives. It generally occurs when an IT organizations fails to attain a level of maturity in identifying new offerings that the business needs, and integrating them into the IT service catalogue.

Specific to DevOps (Close collaboration between Development, and IT Operations, commonly using modern software tools and methods to manage infrastructure and services), this is just GOOD IT OPS.

What makes good IT Operations? 1. Understanding how your org can support the goals of the business 2. Supporting these goals in a high velocity manner (quickly) 3. Providing these services in a high quality manner 4. Maintaining proper Governance of these efforts, so that you don’t break things (laws, kill people, etc) while doing the above.

I could substitute IT Operations with DevOps or Shadow IT in the above statement. Each would still be a true statement.

Shadow IT/DevOps and ITIL/ITISM can live together

Here is a dirty little secret, When you get past the political and emotional barriers to change, you will come upon a simple truth.

DevOps(Shadow IT) and IT Ops (ITIL/ITSM) are not mutually exclusive. They can both operate together.

More specifically, each element of the ITIL change and release management process can be accomplished using DevOps tools and methodologies. Heck, most of the time as a classic IT shop (ITIL) implements the same tools that methods that are in shadow IT, they will notice that their ability to provide high quality services, in a quick fashion while maintaining governance actually improves.

Stop the insanity, and start sharing

Let’s stop the insanity, and start getting along. At the end of the day, if you have shadow IT in your organization, it is probably because the business requires a service that “Classic IT” is not providing.

On the flip side, DevOps / Shadow IT teams that create islands upon themselves are not serving the complete goals of the business either.

What can you do to change this? I personally think that change like this needs to have exec sponsorship. Which can be a huge challenge at times, especially if you are in the “Classic IT side”. it is possible though.

Here is my short list 1. Take ownership of your IT service creation and Continuous Improvement processes. 2. Score your own performance, have your line of business score it too. They are your customer, listen to them. 3. Use lean tools like Value stream mapping to quantize the area’s that IT is impacting the business. 4. Stack rank area’s of improvement, you will probably see Dev services be at the top if you have Shadow IT and cloud consumption. 5. Embrace these Shadow IT/DevOps teams. Leverage them as skill centers. Use them to create dotted lines into your classic IT org. This allows you to learn, and grow together. 5. Share what you learn, this change is huge for most Organizations. You can help others by sharing your own story.

→ 1 CommentTags:···

Thanks to Susie Wee re: DevNet

March 12th, 2014 · 1 Comment · CISCO, devops

Public discussion around features and deficiencies is an important piece of this modern world of OpenSource and social media. It is easy to start a public discussion around deficiencies. It is also important to have a public discussion around success.

I want to use this opportunity to acknowledge Susie Wee and her teams at Cisco.

Susie and her teams responded to public feedback and improving the developer experience with developer.cisco.com. –  http://www.colinmcnamara.com/open-letter-to-cisco-about-devnet/

DevNet

The experience before.. was pretty bad -

I’m going to tell you something, that’s probably really hard to hear. It is near impossible, to use DevNet to find information that we need to be able to achieve our goal. I think that’s your goal, helping guys like us integrate our software with gear like yours.

Susie and team significantly improved the user experience on developer.cisco.com

Now all the product specific links have been removed. I got to API docs on my first try. I have to say, I am happy with this, and am looking forward to seeing further improvements and integrations in the future.

As I said at the beginning, it is important to discuss both issues and success. Thank you very much Susie for taking feedback and improving me and my teams experience. I appreciate it.

 

 

 

 

→ 1 CommentTags:··