Is ITIL Really Evil?

Read a very interesting blog post the other day that got me thinking...

The No. 1 Threat to Private Cloud Deployment: IT Management and ITIL

The basic tenant of the blog posting is that ITIL and other traditional IT managment structures are fundamentally unsuited to cloud style architectures and this is holding people back in their journey to private cloud.

This was directly related to another blog entry on the same site:

The Biggest Threat to Your Private-Cloud Deployment: Your IT Staff

This blog entry put the blame squarely on the IT staff.

Either way, I agree that people and process issues are definately the core issue keeping companies from being successful in deploying private clouds.

On the other hand, I don't think that it's really fair to blame the whole organization for failing to adapt to a new business paradigm.  There are really only a few people who own this type of change.  It really comes down to senior IT leadership and senior technical leadership to drive this kind of change.  Since I am an Architect, and not a CIO, I'll go ahead and say that I think that the senior technical leadership has an opportunity to step up to the plate here.

As you move up through the ranks of a technical organization there is an assumption that you have technical skills.  After all, that's how you got promoted in the first place (hopefully).  On the other hand, you probably did not get promoted for your business acumen.  What I see as the core issue with most IT organization is that there is no expectation that senior technical folks have a broad purview and a high level of business acumen.

I firmly believe that the difference between mid-level technical folks and senior technical folks is their breadth and business acumen.  There is really no other way to build an organization.  Think about the career path of your typical technical person:

• College Hire.  Straight out of school.  Knows nothing.
• Journeyman.  Knows the job and can be left alone with sharp objects.
• Expert.  Really knows their stuff.  Best individual contributor on the team.
• Master.  Teaches others.  Leads teams.
• Architect.   Plans for the future, leads technical programs, owns the solution.

If you think about this journey, your technical depth really starts to plateau around the "Expert" level.  Not that we stop learning, but the point is we have showed that we know how to learn and that we know how to be a techncial person on the team.  That's how we got promoted to that point.

However, becoming a "Master" implies a different skillset.  You need to be able to make others great.  Not all of us can do that. You need to have a broader perspective about how people work, how they learn and what the external organization really needs.  At the architect level, it's all about external inputs.

When I see senior technical people fail, it's usually because they're an "Expert" that's been put into a "Master" or "Architect" type role.  I'm sure if you think about this for a few minutes, you can think of examples from your own career.  When I mentor people I start out by trying to understand where they fit in this continum and what type of job they currently have.  Then I try to understand their aspirations.  Many technical peole do not aspire to make others great.  For those individuals, a "Master" or "Architect" role will never work out. 

If your aspiration is to become an Architect, I would encourage you to think about how you make others great.  How do you increase the overall value of your team?  By imparting your knowledge and expertise to others, you will not only help them succeed but you will also learn about their expereiences and viewpoints which makes you a stronger member of the team also.

So how does this apply to the private cloud adoption curve discussed in the blog posts above?  I believe that both of these blog posts are focused on the SYMPTOM, not the CAUSE.  The symptom is that organizations are not learning and/or adapting to change.  The cause is that senior technical people are acting as EXPERTS, not ARCHITECTS.  An architect is by definition externally facing and is by definition aware of the changing business climate.  An expert is not.  I would not expect an expert to be able to guide an IT organization to adopt the new cloud paradigm.  That's the job of a Master or an Architect.

If the IT organization makes no effort to develop people along this path, then is it any suprise that they cannot adopt to this new paradigm?

If you are an IT director or CIO, ask yourself a couple of hard questions:

1) What am I personally doing to help my people raise their level from Expert to Architect?
2) Who, within my organization is ready for the next step and how do we get them there?
3) How are Experts incented to raise their game from Expert to Master and then Architect?
4) What is the career path within my organization for senior technical people beyond Expert?

TRUTH: The Architect’s One and Only Yardstick

As Architects, we seek the truth.  This truth may be earth shattering or it may be trivial.  Either way, it is only the truth that will allow us to deliver systems, products and solutions that support the business.  However, unlike philosophers, we seek to create the truth we believe in.  We project this future truth and then seek to achieve it.  The extent to which we can do this determines our success as architects.

When we design something, it is based mostly on belief.  We believe that users need X; we believe that technology Y will perform as designed.  We don’t actually know.  If you are designing something that you already know works then you are not actually designing something.  You are implementing something that someone else already made.  Implementation is not bad.  In fact, it’s super important.  Without implementations we never find out if our beliefs will be found to be truths.  It is only through the crucible of actual implementation that we separate incorrect beliefs and assumptions from truths.  It is therefore the truth that we seek as architects. 

This is why so many architects get a bad reputation.  An architect that never measures themselves against the yardstick of truth is not really an architect.  They are a philosopher.  They have ideas that sound good in theory.  Will they actually work?  Who knows?  They never get implemented so they’re just theory.  All theory is equally good and equally bad until it’s implemented.  Then it’s either TRUE (good) or FALSE (bad).  Unfortunately, many of our peers never get to the implementation stage to find out if their assumptions proved to be true or false.  Sometimes these types of architects are referred to as “hand wavers” because they usually make vague gestures when you ask them for specific details underlying their designs.

I really don’t like those types of architects.  I think they give the rest of us a bad name.  My goal is to eradicate this behavior because it is evil and causes cancer.  OK, that last part is probably not true, but I really, really don’t like people who don’t know what they’re doing claiming to be architects.

If you have an architect title or you aspire to be an architect, think about this equation.  How do you hold yourself accountable?  Is your success based on the quality of your design?  Or is it based on the success of your customers?  It is only the internal yardstick that you carry around in your head that really matters.

Five Tests for a Cloud Ready Infrastructure

As an architect of a private cloud solution, I spend quite a bit of time working on making the components of that solution “Cloud Ready.” What’s funny about this work is that there really isn’t a definition of that term. What makes infrastructure “Cloud Ready” anyway? What types of infrastructure are better or worse for private cloud?

One way to think about this is to go back to core principals. What is our definition of cloud? As we have discussed before in this blog, we use the NIST model of cloud computing for our cloud definition framework. Those characteristics are on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. This means that our infrastructure must have features that support those five characteristics. Taking a look one layer deeper into actual implementations, the infrastructure that supports these characteristics has to have all the normal infrastructure characteristics. At Microsoft we used to call these the “abilities.” Supportability, Scalability, Stability, etc.

However, there are implications to aspects like self-service, rapid elasticity and measured service that require additional feature sets that not all infrastructure has. For example, you cannot perform self-service without some degree of automation. There is an assumption in the architectural model that the infrastructure provisioning process can to some extent be automated. In addition, the rapid elasticity and resource pooling characteristics assume an ability to operate at scale. That is to say, you are not going to run a cloud on one server. You’re going to have dozens or hundreds. This also implies remote operations. Anything that requires you to login to a local console is going to be just too cumbersome.

So, this implies that there are some critical features that you need to build a cloud. Here are five tests to see how well your infrastructure supports these key characteristics:

1. Automation. One of the foundations of cloud is self-service. This implies automation. Any infrastructureyou deploy in support of your cloud efforts will benefit from a high degree of automation.
2. Measured Service. Because cloud solutions must be carefully managed to ensure you don’t over-subscribe, you need to be sure that your infrastructure components support a robust performance management interface. Ideally, all the components of your solution use the same management infrastructure so you can establish a single view of your cloud.
3. Rapid Provisioning. Because clouds need to appear infinite, you really need to be able to perform provisioning tasks quickly. Some of this is achieved via the automation bullet above, but in some cases expensive operations like copying a large file can slow things down enough to make the solution a poor candidate for cloud.
4. Scale. Because of the complexity of cloud style architectures, there is a lower sizing boundary below which you really don’t want to go. At that point, the cost per VM just gets too high and you can’t really justify all the complex systems needed to support things like self-service provisioning. That proof point varies depending on your business requirements, but it’s safe to say that a solution that supports less than 100 VM’s is going to have a tough time producing a positive ROI.
5. Availability. I only put this one last because it’s really nothing new. Yes, this is hugely important but in most cases it’s already a consideration for your infrastructure. Most DC’s already operate on a “no single point of failure” rule but I will repeat it here because it is so vital.

  I would encourage you to compare your internal architecture and proposed vendor architectures against this list to see how they stack up.

ITA