What, again??

Wow!  There are some things that are as predictable as a foggy San Francisco summer.  One of those seems to be the inevitable predictions around the doom of the PC.  Here is another one just today from CNN:

http://tech.fortune.cnn.com/2012/08/07/the-pc-looks-like-its-dying/?source=linkedin

The really dumb thing about this one is that the data that the claim is based on is so incredibly thin.  Unlike the silly article that I debunked last year (from the excellent writer Paul Carr), this one is based on a pretty insignificant downturn in  WW PC shipments.

Here's the problem:  if you used that criteria, then we're pretty much done with cars.  What?  Didn't you know?  The worldwide car business had a huge downturn a few years back.  By this logic, cars are all over.  We're doing skateboards from now on folks.

Wait, that isn't true?  Crap.

People who don't understand technology, business and the business of technology seem to be very confused about what is happening in the real world where the rest of us work. 

There is definately a paradigm shift going on.  Web 2.0 and now cloud is changing the way we all work.  However, the vast majority of us still work on PC's (running Mac OS, Windows, Linux, whatever).  That doesn't seem to be changing anytime soon. 

Walk around any business in America and take a look at the folks doing real work.  How many information workers do you know who use anything but a PC for their primary workstation?  I'm guessing zero.

Not 10% or 1%.  ZERO!  I defy you to find one information worker who uses anything but a PC for their primary work device.

Until this primary fact changes, all writers who declare PC's dead are officially dead to me. 

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

I've written here about value and benefits, but I've never talked about the underpinnings of Benefits Management. Time to correct that oversight.

Early in my consulting career I worked with a group of folks in the UK who were Cranfield business school disciples. Cranfield has developed a framework they call Benefits Management which talks about ways in which you can ensure IT actually delivers benefits to the business. This framework instantly made sense to me. As a technical guy, I had always known in the back of my head that IT had to serve the business in order to be successful, but I never really thought about it much. Benefits Management was the first framework that explained to me in ways I could easily understand how to bridge that all important gap.

If you're interested, you really need to take the course or read the book, but I'll give you a flavor of it here.

In summary, the idea is that when you make IT decisions, you need to make them based on business benefit. That is to say, how much will each project, program or architectural decision impact the business. This may seem difficult, and it is. The idea that Cranfield introduced me to that helped me understand was the idea of indirect but specific and measurable benefits. Cranfield has some very specific rules about benefits that keep you from creating false value statements. My favorites are:

1) A benefit must be measurable. If you cannot measure it, it's not a benefit by definition.
2) A benefit must have a business owner. If you claim that your software will increase sales by $2M, then the Sales VP must be willing to accept a higher sales quota as a result. If not, it's not a benefit by definition.

I cannot tell you how many IT planning meetings I've been in where one or both of these simple rules have been violated. A classic example is worker productivity. "Deploying this software will increase knowledge worker productivity!" Really? By how much? Is the COO willing to fire people because the company is so much more efficient? Or will production quotas rise because of this? If not, it's not a benefit.

In fact, flagrant violation of these rules led to once was once called the productivity paradox. Although this theory is largely debunked, it shows that massive technology infusions don't result in value unless they're carefully managed.

The second major revelation that the Cranfield framework brought to me was the idea that IT should focus on the top line of the business rather than on the bottom line. In many organizations, IT is simply a cost center. This means that you should do IT as inexpensively as possible. Containing costs leads to higher profits. Every dollar you squeeze out of the bottom line goes directly to profit. Unfortunately, as an IT guy this means you're the one getting squeezed. Not a fun place to be, really.

On the other hand, IT organizations that add to the business' top line are much better places to live. If you can create additional business value for your organization then you can justify higher budgets and larger teams. It's also way more fun to work in a place that's creating new things and adding value than a place that's all about cost containment. Since my exposure to Cranfield I have always sought to be on the value side of the house as opposed to the cost side. This change in thinking really changed my professional life.

ITA

How Do You Become an Architect?

Someone asked me one of those simple questions that are extremely tough to answer today.

"How do I become an IT architect?"

My first answer was flippant (go figure): Get about ten years of experience running IT projects then call me back.

My second answer was more so: The word Architect doesn't really mean anything. Just print up some cards and put that as your title.

Yeah, I'm not happy with that either.

So, the next train of thought is "how did I get here?" That answer is much simpler and sounds a lot like number 1. I've spent most of my adult life planning, delivering, building or fixing IT programs, projects and products. At some point, you find yourself designing more than doing and before you know it, you get an Architect pegged onto your title. It's a bit more complicated than that, but you get the idea.

I think the real problem is that there isn't really a fixed definition of what an IT Architect is. Everyone's got an opinion and they're all equally good (or bad). My personal definition is that the Architect lives in the space between business and technology. We translate from one to the other, when given business requirements we create technical specs. When given specs, we write a business plan or budget justification or impact assessment. In my mind this is the one unique skill that architects must posesses that other members of the IT staff normally don't.

Many of my peers focus on design. They design things. While I design things also, there are other members of the team closely involved in the design. Design in my world tends to be collaborative. Everyone wants to be a part of that. But when I explain to the CFO why he needs to cough up the dough for a new e-mail system; the rest of the team is strangely silent. I also don't hear many engineers clamoring for a specific feature because of the key business advantage it will give the business. Hence, my role.

So, how does one gain both business and IT skills? In my case I came from the IT side (which I think is better, duh) and then learned the business side later. At a certain point in my career I just got bored with technology. In the end, computers are simple. They do what they're told. People, process, business impact. Those things are complex. They change, they have no set rules. I spend much more time trying to figure out how cloud computing will change the IT landscape than how Hyper-V works. Hyper-V is simple. Cloud computing (which to me is a business model) is complex and still evolving.

If you've been in the IT business and you find yourself topping out, then it may be time to think about becoming an architect. Go to business school. Take one of those Executive MBA courses. Look at the world differently. Just take your CFO out to lunch. Learn what makes him tick.

ITA

I predicted this

The anti-Google forces are starting to gather: Google is a dangerous monopoly -- more than Microsoft ever was Betanews

I predicted this would occur last year.

OK, it wasn't a really tough prediction. Americans love the underdog. They hate the big guy. We're funny that way. When Google was an up and comer, everyone loved them. The more successful they get, the more people want them to loose. Strange. The same stuff that makes you a hero will ultimately damn you if you get too good at it.

For the record, I think this is crazy. Google is doing the right thing. Just like it was crazy to criticize Microsoft for being successful, it's crazy to do the same thing to Google.

ITA