Private Cloud Matures: The Suits Take Over?

Like many things in life, new technologies have a distinct life cycle that is somewhat predictable.  The pace at which they move through this life cycle usually isn't predictable and they sometimes simply fail to progress along the life cycle, but the sequence of events usually predictable even if the pace of this transition is not.

In the private cloud world, there is so much hype and so much pent up market demand that it seems obvious that it will proceed along this timeline fairly rapidly.  However, this is a pretty major paradigm shift so the pacing is difficult to predict.  Because of this, I'm always on the lookout for actual data that shows progress (or lack thereof) in this space.  Recently, CapGemini has come out with a great study that shows that this progression is moving along rapidly:

http://www.capgemini.com/insights-and-resources/by-publication/business-cloud-the-state-of-play-shifts-rapidly/

In short, the study says that Cloud deployment decisions are largely being made by business leaders instead of technology leaders.  That's not unusual when a technology matures.  It's also interesting that in this sample, cloud is becoming very ubiquitous.  This also lends credence to the idea that Cloud is now mainstream and moving into a mature technology phase.

The other interesting thing in this study is the very high percentage of folks who are stating cost savings as a reason to move to cloud.  51% state that cost savings is a major driver for cloud. However, other post-deployment studies have shown that cost savings from cloud aren’t that significant (like this one from CSC). There seems to be a growing gap between expected benefit and actual benefit. Given all the hype, this isn’t unexpected but it may lead to the collapse of the hype cycle.

We have seen this movie before.  When distributing computing started to become mainstream in the early '90's the same thing happened.  This was supposed to enhance productivity and have a positive ROI.  In actual practice, this didn't happen.  Organizations who had loose management policies found little or no financial benefit.  The implementation of distributed computing on it's own had little or no financial benefit.  It was the change in business process that led to benefit, the technology was simply an enabler of this.

The same thing is happening here.  Companies focused on benefits management can gain significant business advantage in deploying cloud style architectures.  However, there is no inherent benefit in cloud. 

Be a CIO in Three Easy Steps

Read a blog post today that made me laugh:

http://www.zdnet.com/why-cio-success-comes-down-to-just-three-things-7000006850/

Basically, the thrust of the post was that a CIO only has to do three things:

1. Eliminate risk
2. Improve cycle times
3. Reduce cost

And if you read the post, then those three things really come down to one thing:  Converged Architecture.  After reading the article, I'm pretty sure the author either works for a converged architecture vendor or just spent a huge sum of money on a new converged architecture system.

Being an Ex-Vendor of converged architectures myself, I do like the idea that converged architectures solve everything.  Unfortunately, this just ain't true.  Sigh.

I also have a funny feeling that being a CIO comes down to more than just three things.  To be fair, it's more than just a feeling.  I used to run a CIO consulting program for Microsoft so I've spent quite a bit of time working with, supporting and selling to CIO's.  I've spent a good portion of my life thinking about this position and what it takes to be good at it.

However, I do like this list as a conversation starter.  If I was a CIO, I would definately be thinking about these three things.  They're probably even in the right order.  If you don't have your risks addressed, then reducing cost and improving cycle times don't matter much.

On the other hand, the blog post really misses a great opportunity when discussing risk.  Risk is one of those things that seems to be widely mis-understood in the technical community.  To me risk is not good or bad.   Eliminating all risk is not really possible nor is it desirable in most cases.  Risk is something that needs to be managed, like the weather.  As they say in the Pacific Northwest, there is no such thing as bad weather, just insufficient gear.  That's probably not strictly true, look at what our friends in the NorthEast are dealing with due to Sandy.  The fact remains that weather must be dealt with and managed.  We cannot control it just like we cannot truly control other sources of risk.

To change the saying to our purposes, let's just say that there is no such thing as a bad risk, just insufficient planning for that risk.

When thinking about risk, we must first think about our sources of risk.  These may be business (the company is loosing money and fires half of IT) or Technical (the main router blows a power supply) but they also may be political (the city of New York declares your business model illegal; yes I'm talking to you Uber) or natural (Sandy puts your DC under ten feet of water).  Under no circumstances can you do any one thing to manage all these sources of risk.

The next thing to consider is risk mitigation.  What can I do to make this source of risk less likely to actually occur?  In many cases, a strong mitigation plan can completely eliminate a source of risk.  Having no single point of failure in a DC is a common example of this type of risk planning.  However, this is not the best choice in all cases.  For example, what happens if the object being protected is basically a throw away object?

This leads us to contingency planning.  In some cases, it's simpler and easier to simply mitigate the risk once it occurs instead of making the risk less likely to occur.  For example, I used to back up my laptop once a week.  Honestly, it was a pain in the butt and I didn't remember every week.  Now, I used a cloud based storage platform (SkyDrive in my case) so there's nothing on my laptop that's not replicated to the cloud.  No need to backup any more.  If the laptop dies, then it dies.  No data is lost.  Should I bother spending huge amounts of time on keeping my laptop healthy?  No.  Should I bother buying a second hard drive to mirror my local drive?  No.  There is no point.

When deciding which sources of risk to focus on, think about the probability that the risk will occur multiplied by the business impact (measured in dollars).  The risks with the highest probability and the highest impact are naturally more important than those with relatively small impact or extremely low probability.  Unlike the blog post above, there is no way you can afford to completely mitigate all risk.  You can reduce your risk profile but you cannot take it down to zero.

Let People Manage People

I had a great conversation this week about SLA enforcement this week that I thought I'd share here.

The conversation was about private cloud provisioning.  When you use VMware's vCD product, it wil select the correct datastore based on the assigned storage profile.  All well and good.  The question we got was:  "What if I have an SLA that says the storage must be located in the USA?  For example, if this is a federal government customer."

Ah, simple we say.  Just create a specific storage profile that is called "US Only Data" or some such and you're all set.

"Yes, but."  OK, here comes the but.  "I have a contract with the federal government that says that I have to ensure that my data does not leave the USA.  How can your product ensure that doesn't happen?" 

That's the rub, isn't it?  How can we model even a very simple SLA like geo location of data?  The reality is that you cannot.

As I have said many times before, the movement to cloud is a fundamental business shift that is enabled by technology but is not fundamentally a technology shift.  Or to put it another way, technology does not solve every problem.

In this case, we are really talking about business rules that govern the placement of data.  This business rule is created by humans and must be implemented by humans.  Yes, we can create scripts or other tools to help make this simpler, no we cannot insure that the software will always do the right thing.  The humans are, in the end, responsible for ensuring that the business rules are met.

Oh man, I hear the engineers out there protesting.  You are fuming on the other side of your screens!  There must be a technology answer here!   No, there isn't.

Let's think this one through.  Let's say that we did create a system that allowed us to model SLA's.  For example, we could do something simple like a tag for all VM's that's created at provision time that lists the countries that they're allowed to run in.  Then, when we provision, this tag gets set to "USA".  Then we tag all assets in the data center with a geo tag stating their location.  Then we write a script that compares these values.  Simple, right?

Wrong.  We are still dependant on the humans to enter the right value tags.  If that doesn't happen, the whole system breaks down.  And this is a relatively simple business rule.  If you start looking at your SLA's closely, you will find that it is almost impossible to model them completely.  And that's only the "Formal" SLA's.  What about the informal ones?  The reality is that the complexity of human interaction is so complex that it's almost impossible to model.  I'm sure that there are some really smard dudes out there who are trying and they may prove me wrong one day, but I doubt it somehow.

So, what's the message here?  The message is to let the humans manage the humans.  Create scripts and processes to check on things that are easy for computers to understand.  Workload X does on datastore Y.  Why?  Because we say so.  The computer doesn't really need to know.  Maximum acceptable latency on datastore X cannot be more than 12ms.  Whatever.  These are simple things to model and relatively simple to build into monitoring software.  Focus on these things.

The converse is also true.  When setting up formal and informal SLA's with your customers, keep in mind the limits of what the system can actully measure.  Saying that performance must be "acceptable" is really tough to gague.  An SLA around average response time of xx miliseconds can actually be measured and tracked.  Time to first byte, latency, throughput....  These things are all good fodder for SLA's.  Words that require actual judgement "Good," "Acceptable" or "Excellent" are not words that should ever be included in a formal SLA document because these require human judgement.

What's the Big Deal? Reference Architectures.

If there is one thing guaranteed to stir up a bunch of architects into a frenzy, it's a discussion about reference architectures.  Which is kinda sad, really because they're rather dry documents.  However, they do have a big impact on folks like me.  As a vendor architect, it's really the reference architect that forms the basis of every conversation I have with a customer.  When I was a customer architect, the reference architecture documents where the only vendor materials I ever read.

I'm currently working on a big reference architecture program so I've been pondering the nature of reference architectures a bit.  I thought I share some of those ponderences here.  If you couldn't care less about reference architecture, feel free to stop reading here.  No rainbows or ponies in this post.

If you've never been the author of a reference architecture document, let me share a little secret with you:  They all suck.

What?  How could this be?

It's the nature of the beast, I'm afraid.

Here's the deal.  Our friends in engineering spend huge amounts of time creating really cool products that do all kinds of things.  They then spend a huge amount of time documenting all the various permutations of what that software can do.  With enterprise class software, this list can get pretty extensive.  Thus are reference architectures born.  Instead of focusing on all the great stuff that you CAN do, it says, this is the short list of stuff you SHOULD DO.

Naturally, the best reference architectures are very specific.  The word we use in our business is "Prescriptive Architecture."  Good reference architectures are PRESCRIPTIVE by telling folks DO THIS and DON'T DO THIS.  The problem is that the products in question always have tons of great features that can be implemented in all kinds of cool ways.  This implies options.  But we just said that good reference architectures are prescriptive.  This implies few or no choices.  This is the rub.  There is a constant tension between generality and specificity.  You never get this right, it's a constant source of friction.

The other thing that happens is that reference architectures are almost always written by a large group.  After all, if the system is simple enough to be well understood by just one person, you probably don't need to write a reference architecture in the first place.  Right?   I'm sure you have heard the joke that a camel is a horse designed by committee?  Yeah, same principle here.

So, reference architectures suck.  Then why do them?  Because not having them sucks even more.  Without a reference architecture, you have no benchmark to shoot for.  There is no "standard" in your deployments.  This means that there is no direction to customers or partners and they go off in all kinds of tangents.  Not good for anybody.  I firmly believe that reference architectures are a necessary evil in any complex system.  The more complex the system, the more need for reference architecture.

This, naturally, takes me back to private cloud.  As I have written here in the past, Private Cloud is probably one of the most complex solution spaces I have ever been involved in.  OK, apart from running a Nuclear Power Plant, but I wasn't designing the thing, I just worked there.  Of the things I've actually designed myself, this is the most complex by far.  Hence, I'm working on a reference architecture.....

If I'm going to design something, I need to have a set of design guides.  What are my goals in this system?  How do I know that the work product is successful?  Who is my audience? etc..  Let's think about this in the context of reference architectures.  In my case, I work for a technology vendor, so my audience is pretty clear.  I need to speak to customer and partner architects.  These are people who may be or may not be familiar with my product who want to implement a private cloud on our platform.  Luckily, this is a pretty small audience and I know this audience well.  It is almost impossible to write a good document without knowing your audience.

Rules for writing a good reference architecture:

1. Know your audience.  Who are you writing for and what do they need to get from the document?  What are their key pain points and how do you alleviate those pain points.
2. Know the current state of the art.  There is no point in repeating information that everyone already knows.  If something is a widely accepted norm, just say so and move on.  Nothing worse that page after page of explanation of something everyone knows already.
3. Present the architecture sequentially.  Think about the decisions that your audience will make and the order they will need to make them.  There is no point in telling them how to operate the system before we talk about how the system is built.
4. Minimize decision points.  The fewer decision points that the customer needs to make, the better.  Yes, you will need to allow customization of your design; yes, you will need to have the customer make design decisions.  However, the point is to be PRESCRIPTIVE which means reducing choice.  They can always pick and choose from your guidance if they disagree but too many variables make the reference design useless.
5. Be concise.  We architects love to hear ourselves talk.  Resist pontification.  Just lay out your guidance as concisely as possible.
6. Do not generalize.  Saying things like "backups are good" and "No single point of failure" are pretty much mom and apple pie.   Nobody doubts them.  The question is HOW your design enables things like this.  Be specific.  No need to convince people that these things are good or necessary. 
7. Think in layers.  The reality is that your system will look different to different people.  You may need to produce an operations guide, a deployment guide and a architecture guide separately.  That's OK.  Better to be focused on one audience at a time.  While you're at it, don't forget that architecture is about aligning the business problem to the technology.  If your architecture doesn't discuss the business problem or how the end customer benefits, you're probably missing something.

I'm sure you can think of others.  Hopefully, we can all follow these rules and suck less.  Don't be shy in letting me know what you think!!

The End of Solution Sales?

Read a great article today:

http://hbr.org/2012/07/the-end-of-solution-sales/ar/1

The funny thing about this is not the conclusion, which I think I agree with.  It's the assumption that people are actually doing solution selling today.   When I say I think I agree it's because the article is complex and I haven't fully gotten my arms wrapped around the concepts yet.

However, there is an assumption baked into the article that we're all doing solution selling all the time.  The reality s that this is simply not true.  Solution selling is something that most mature technology companies do, but the reality is that maturity level really varies between companies.  This is not a given everywhere.

Here's the deal:  Unless you are investing in your ability to speak the language of your customer, you are not doing solution selling.  When you sell feeds and speeds, you are not doing solution selling.

From the technical side, that means that we architects need to step up to the plate.  Our position as the intersection between business and technology means that we are the point of the spear in helping our engineering teams understand the business and what they require to be successful. 

What I have seen is that most technical organizations simply replace the words "product" or "feature" and replace them with the word "solution."  Thus we get things like the "Exchange Backup Solution."  Naturally, this is nonsense.  When you use terms like this it just makes it obvious that you have missed the entire point of solution selling.  In order to sell a solution, you must be addressing a specific business problem.  You can't just sell the same product in the same way and call it a solution.

For example, you can sell a "E-Mail Retention and E-Discovery Solution."  That is something that a corporate council may need if they anticipate litigation and is a common business requirement that comes from legal and to IT.

The further you are from the actual business, the more difficult this is.  For a product like a SAN, you can legitimately ask if a solutions approach is really appropriate.  After all, you don't really sell SAN's to the business user or sponsor.  A SAN is something that IT buys in order to provide services back to their internal customers, it isn't a customer facing component.

On the other hand, it is those business users who ultimately write the checks.  By being content to sell features to IT, you run the risk of becoming irrelevant.  The cloud is a huge lesson here for technology providers.  Internal IT customers really don't care about all your nifty features or how many IOPS you produce.  They're happy to rent services from the cloud and completely bypass your entire business.  This means that even low level infrastructure companies need to find a way to become relevant to your customer's business users or run the risk of becoming irrelevant.  Don't believe me?  Look at Sun.  Great products, killer engineering.  They pretty much died and Oracle picked up the bones of the company.

There's a great line from "The Right Stuff" that covers this pretty well:

"No bucks, no Buck Rogers."

In our business this means pretty much the same thing.  No bucks, no engineers.  If you are a technical guy and you like eating regularly, you need to think about how your product or service solves problems for your users.  What problem are you trying to solve?  How is your target user's life better than before they bought your product?  Is this so much better that they'd be willing to pay for it?  Do they have any money?  How does funding for your product get approved in your customer?  Who has the power to make that decision?  How does that power role perceive your product? 

Are You Focused on the Wrong Thing?

As an IT organization, I submit that you are probably thinking and worrying about the wrong things.  The idea that you are fundamentally an engineer and that you provide technical support to the organization is getting very outdated.  The traditional IT organization was created because of the mind-numbing complexity inherent in early computer systems.  In the 1970’s it was not uncommon for large shops to write their own operating systems or transaction processing systems.  This type of task is hugely complicated and requires a skilled and dedicated team to pull it off.  The results were similarly huge.  The ability to go from paper processing of customer records and billing transformed American businesses. 

Unfortunately, we as IT folks have found more and more technical complexity to dive into.  We’ve been able to focus on distributed computing, private Intranets, custom developed internal portals and all manner of cool things.  Thus the ABILITY to solve complex technical challenges has resulted in our WILLINGNESS to solve them.  It’s a bit strange really, and reflects the rapid pace and relative immaturity of our business that we still operate this way.

Think about other core services that our parent companies consume.  Do they operate this way?  Perhaps, if it’s truly core to your business.  FedEx, for example does all their own maintenance on all their jets and trucks because they feel that’s core to what they do.  On the other hand, the corporate pool car program has completely faded from the American corporate landscape as folks realized that their employees already had cars.  In our business, the IT organization is quickly moving from a necessity to something that you can probably do without.  This motion of technology from leading edge to commonplace and dull is normal for us, but the underlying business model change required to reflect this obvious change is much harder for us to internalize.

The implications of these changes are still beginning to trickle down into the operational philosophies of our IT organizations.  Things that “were always done that way” are usually incorrect simply because they’re old.  Any standard or process in your organization that is more than a year old should seriously be looked at.  After all, the technology you are supporting has changed.  Why shouldn’t your operational procedure change along with it?  I think that I don’t need to belabor this point.  If we are honest, we all understand that we are in a very fast moving business and that we need to be adaptable to change.

If we accept that basic fact, then we begin to see the core of the problem.  The reality is that technology is changing way faster than our organizations can adapt.   This means we either get picky in which things we implement or we are continually chasing the latest bright, shiny object that comes across our field of view.  This implies a very strong set of filters that prevents us from chasing things that don’t have high value to our organizations.  It is the development of these filters that I think we can generalize and discuss outside the context of each particular organization.  It is almost impossible for me to say if a particular technology or architecture adds value to a particular organization without spending some quality time with that org.  On the other hand, I think that we can establish some ground rules that will help you drive things like technology evaluation and prioritization.

Not surprisingly, the answer revolves around the question of WHY.  Why are we doing what we are doing?  The “BECAUSE” part of your answer is usually where we succeed or fail.  The “WHAT” part is where spend most of our time but turns out to be one of the least important parts.  The reason is that WHAT we are doing becomes pretty meaningless if we are doing the wrong thing.  Take an extreme example.  Let’s say I asked you to build a bridge.  A really big bridge.  Let’s say we started talking about stressed concrete, suspension spans, all kinds of cool stuff.  We get really into it and decide to build a suspension span.  The best suspension bridge in the world.  What’s missing?

Why are we building the bridge?  Let’s say we are building the bridge to connect two towns of 100 people each.  Total expected traffic is 10 cars a day.  Did we build a good bridge?  Not really.  And what happens if we build the bridge with railroad tracks for higher density.  But, there is no railroad within 100 miles of the bridge.  Was that a good idea?  Yes, extreme example, but you get the point.  It’s the context that matters.  Why are we building this bridge?  Who will benefit?  How will they benefit?  How will their lives be better after we’re done?  Can we do the same thing for half the cost in half the time?  Perhaps they’d prefer the simpler answer if they knew they could have it in six months instead of six years.

In our case, the context is much more complex than just driving a car over a bridge (with all due respects to traffic planners and engineers out there).  We all drive cars and at some very basic level this example makes sense to us and some of the more obvious errors would never get made (build a railway bridge where there is no railroad for example).  In the technology business, very obvious errors like that get made all the time.  We buy hardware to support applications that never get used.  We solve problems that don’t really exist.  We write white papers that nobody reads.  Part of this is due to complexity.  As enterprise class IT organizations, we are usually serving a very complex business.  It is simply not possible for us to understand the complexity of even the simplest Fortune 500 class business.

One way to deal with complexity is to model the complex system using simplified concepts and abstractions.  Naturally, this exercise is in its self dangerous because the abstractions can lead to error if the model is wrong.  To correct for this, we need to ASSUME that the model is wrong and continually course correct based on feedback mechanisms.  By assuming error in the system, we allow for forward progress but recognize that our process is not and cannot be perfect.  Thus the concept of “continuous improvement” made so famous by the Japanese.  We assume that our process, our assumptions and our plans are flawed.  We proceed anyway and then see where problems crop up.  By remaining nimble, we allow ourselves to respond to the largest threats and allow potential threats to go unaddressed since they never actually occur in real life.

All of this thinking brings us, of course, to the Customer Centric IT organization.  In a customer centric IT organization, we obsess over our overall customer experience.  Are our customers happy?  Why or why not?  What are the top ten issues customers are reporting?  What are the key pain points that they haven’t addressed?  And this is where it gets messy.  You need to really understand your customer in a fundamental way.  They only way you can do this is by spending time with them.  Call them focus groups or just taking people out to lunch.  If you do not have a direct and personal relationship with your target audience, you will never understand them.  If you do not understand them, your ability to predict their needs will basically be zero.  And it is the ability to PREDICT their reactions that we really need to develop here.  IT isn’t magic.  It isn’t cheap and it isn’t quick.  If we simply react to expressed user requirements we will never achieve our goals of driving the organization forward.  It is the ability to PREDICT their responses in advance that separates the truly great organizations from the mundane sort that we’re all trying to avoid.

The Transition from Product to Solution

When selling enterprise class systems, there has been a very long standing shift from products and a product focused mindset to solutions and a solutions focus.

Interestingly, this trend is not new. The first "solution selling" literature for technology shows up very early, around 1975. The reason I find this interesting is that almost every enterprise class technology company seems to go through this model. I have not done an exhaustive study, but my personal experience is that "young" companies are very focused on their technology and making a better widget. As they and their market matures, the focus changes inevitably to solutions and solutions selling.

The reason I bring this up is because it seems that most companies who sell into enterprises sooner or later realize that selling a complete solution and focusing on core business issues within their target customers helps them to realize better sales and makes their accounts "stickier" over the long term. This transition many times starts with the sales or consulting organization but inevitably seems to percolate down into the engineering teams. The funny thing is that engineering’s first response to this change is to simply take products and rename them solutions despite the fact that they’re not actually solutions. If you sell an accounting software package, it magically becomes an accounting solution overnight.

Naturally, customers are not actually fooled by this behavior. For this reason, the word "solution," like so many others in our business has become completely devalued. This is a shame. Personally, I am a big believer in the solutions orientation. I think that this comes from my background in enterprise consulting and then as a pre-sales engineer. When you talk to customers every day, it becomes really apparent that customers are trying to buy solutions to their business problems. Unfortunately, that’s not always what we’re selling. That causes a disconnect between the customer and the vendor. Some sales organizations respond with marketing. "Our product is the solution to your problem." Marketing is great, but it doesn’t address the key issue here. Products that are designed from the inside out are difficult to sell because they don’t take the user’s perspective into account.

This is not to suggest that product organizations should simply take user input at face value. This also leads to bad products because in reality most users don’t really know what they want. This disconnect between stated want and actual customer NEED is difficult to discern in many cases. The truly great product organizations seem to simply KNOW what customers really need even when the customers don’t realize they want it.

Aside from the "just be really smart" plan, how do product organizations focus their efforts on the correct features and meld those features into a true solution for their customers?

One, obviously, is orientation. Are you solutions oriented in your approach? Does the overall customer solution drive your product plan? This is an interesting consideration because it seems like the simplest part of the puzzle, but in reality, it’s very tough. What normally happens is that product teams tend to focus narrowly in order to get things done. Building software is really hard and you have to specialize to do it well. In larger organizations, this leads to people on the product team who develop tunnel vision in order to ship their particular product or feature. While shipping is very good, it is useless unless your product serves some greater purpose. For smaller companies, it’s sufficient to be a one trick pony. Especially if that trick is really, really good. Look at Google. I would love to have their problem of "only" a single multi-billion dollar business. However, for them this is a huge problem. Fundamentally, Google has only one product, search. Everything else at Google must serve that master. This colors their view of the world to an extreme degree. It is very difficult to step away from that and do something completely new but still be loyal to the success that made the company possible. You have some really brilliant people at Google and yet they have failed to develop a second multi-billion dollar business. Same with Facebook but they are a bit younger. Only time will tell if these tech titans will become true powerhouses with multiple billion dollar businesses.

Compare Google to Apple or Microsoft. Apple (with a little help from Microsoft) was able to survive a near death experience after losing the PC war to Microsoft. Now, they are incredibly dominant in the personal electronics business to the point that they have basically killed Sony (remember they invented mobile audio). Microsoft has pioneered several businesses that have become multi-billion dollar businesses. While everyone knows about Windows and Office (and yes, you must count them separately) some people forget about the enterprise business with Exchange, SQL and SharePoint. Xbox is also the dominant platform in the gaming business despite tough competition from Nintendo and Sony. Both Apple and Microsoft have managed to create new businesses related to but outside their core competency and to make them successful. How is this possible?

In the case of Apple, I believe it is the core focus on the design of their products and the overall user experience. In consumer electronics, this was sorely lacking before they came along. I had several MP3 players before the iPod came out but none of them offered a complete experience that my grandmother could use. Instead of focusing on how much storage or how fast it could rip an album, they focused on the core solution which was to acquire and play music for the consumer.

At Microsoft, I witnessed the shift from product to solution first hand. The transition was not easy and it took several years, but today Microsoft as an organization understands how to build and sell products to their core Enterprise IT audience. For example, instead of competing with VMWare head on with Hyper-V, they chose to focus on the management aspects of Private Cloud. Microsoft quickly realized that in the end the Hypervisor is a commodity feature just like file and print. It is management and other usability issues like pricing that will determine the winner in the Private Cloud age. This is not a new playbook for Microsoft. In my day, the key competitor to Windows Server was Novell NetWare. In those days, Microsoft faced a heavily entrenched competitor with what was arguably a better product. NetWare was a great file and print platform. The obvious tactic would have been a frontal assault where Windows simply copied NetWare features. Instead, Microsoft made their file and print solution "good enough" to be reasonable and focused on running applications like SQL Server and Exchange on Windows Server. Now you had only one platform with a common set of tools to do everything. By the time Novell realized what was happening; Windows took away their core market.

We used to refer to this as the "technology fallacy." The fallacy is that the best technology wins. In reality, that is only one small piece of the puzzle. Technical excellence does not usually lead to market dominance. There are endless examples of better technology losing out to price or convenience. Look at Beta vs. VHS…. Or SMTP vs. x.400… Or even (sorry guys) Windows 3.1 vs. Mac. The Mac was way ahead of Windows at the time and yet they lost. They just could not compete with 100 hardware providers all killing themselves to lower the equipment cost by a dollar. In the end, the cheap PC clone killed the Mac as a serious threat to Windows. Was the PC better? No way in hell. But they sold millions of them because they were cheap and they got the job done. Yes, I am aware that iOS is causing a comeback in Mac land, but in the days of PC vs. Mac, the PC won and Apple nearly went bankrupt. Apple is an iOS company now, the Mac is a sideshow. Just look at the numbers if you doubt this.

So, how do we apply this lesson to our business and why should we, as IT people care? It goes back to concept or orientation. Are you oriented correctly? What business are you in? Are you and your team oriented correctly to make that core business successful?

As an IT organization, I submit that you are probably thinking and worrying about the wrong things. The idea that you are fundamentally an engineer and that you provide technical support to the organization is getting very outdated. The traditional IT organization was created because of the mind-numbing complexity inherent in early computer systems. In the 1970’s it was not uncommon for large shops to write their own operating systems or transaction processing systems. This type of task is hugely complicated and requires a skilled and dedicated team to pull it off. The results were similarly huge. The ability to go from paper processing of customer records and billing transformed American businesses.

Unfortunately, we as IT folks have found more and more technical complexity to dive into. We’ve been able to focus on distributed computing, private Intranets, custom developed internal portals and all manner of cool things. Thus the ABILITY to solve complex technical challenges has resulted in our WILLINGNESS to solve them. It’s a bit strange, really and reflects the rapid pace and relative immaturity of our business that we still operate this way.

Think about other core services that our parent companies consume. Do they operate this way? Perhaps, if it’s truly core to your business. FedEx, for example does all their own maintenance on all their jets and trucks because they feel that’s core to what they do. On the other hand, the corporate pool car program has completely faded from the American corporate landscape as folks realized that their employees already had cars. In our business, the IT organization is quickly moving from a necessity to something that you can probably do without. This motion of technology from leading edge to commonplace and dull is normal for us, but the underlying business model change required to reflect this obvious change is much harder for us to internalize.

The implications of these changes are still beginning to trickle down into the operational philosophies of our IT organizations. Things that "were always done that way" are usually incorrect simply because they’re old. And standard or process in your organization that is more than a year old should seriously be looked at. After all, the technology you are supporting has changed. Why shouldn’t your operational procedure change along with it? I think that I don’t need to belabor this point. If we are honest, we all understand that we are in a very fast moving business and that we need to be adaptable to change.

If we accept that basic fact, then we begin to see the core of the problem. The reality is that technology is changing way faster than our organizations can adapt. This means we either get picky in which things we implement or we are continually chasing the latest bright, shiny object that comes across our field of view. This implies a very strong set of filters that prevents us from chasing things that don’t have high value to our organizations. It is the development of these filters that I think we can generalize and discuss outside the context of each particular organization. It is almost impossible for me to say if a particular technology or architecture adds value to a particular organization without spending some quality time with that org. On the other hand, I think that we can establish some ground rules that will help you drive things like technology evaluation and prioritization.

Not surprisingly, the answer revolves around the question of WHY. Why are we doing what we are doing? The "BECAUSE" part of your answer is usually where we succeed or fail. The "WHAT" part is where spend most of our time but turns out to be one of the least important parts. The reason is that WHAT we are doing becomes pretty meaningless if we are doing the wrong thing. Take an extreme example. Let’s say I asked you to build a bridge. A really big bridge. Let’s say we started talking about stressed concrete, suspension spans, all kinds of cool stuff. We get really into it and decide to build a suspension span. The best suspension bridge in the world. What’s missing?

Why are we building the bridge? Let’s say we are building the bridge to connect two towns of 100 people each. Total expected traffic is 10 cars a day. Did we build a good bridge? Not really. And what happens if we build the bridge with railroad tracks for higher density. But, there is no railroad within 100 miles of the bridge. Was that a good idea? Yes, extreme example, but you get the point. It’s the context that matters. Why are we building this bridge? Who will benefit? How will they benefit? How will their lives be better after we’re done? Can we do the same thing for half the cost in half the time? Perhaps they’d prefer the simpler answer if they knew they could have it in six months instead of six years.

In our case, the context is much more complex than just driving a car over a bridge (with all due respects to traffic planners and engineers out there). We all drive cars and at some very basic level this example makes sense to us and some of the more obvious errors would never get made (build a railway bridge where there is no railroad for example). In the technology business, very obvious errors like that get made all the time. We buy hardware to support applications that never get used. We solve problems that don’t really exist. We write white papers that nobody reads. Part of this is due to complexity. As enterprise class IT organizations, we are usually serving a very complex business. It is simply not possible for us to understand the complexity of even the simplest Fortune 500 class business.

One way to deal with complexity is to model the complex system using simplified concepts and abstractions. Naturally, this exercise is in its self dangerous because the abstractions can lead to error if the model is wrong. To correct for this, we need to ASSUME that the model is wrong and continually course correct based on feedback mechanisms. By assuming error in the system, we allow for forward progress but recognize that our process is not and cannot be perfect. Thus the concept of "continuous improvement" made so famous by the Japanese. We assume that our process, our assumptions and our plans are flawed. We proceed anyway and then see where problems crop up. By remaining nimble, we allow ourselves to respond to the largest threats and allow potential threats to go unaddressed since they never actually occur in real life.

All of this thinking brings us, of course, to the Customer Centric IT organization. In a customer centric IT organization, we obsess over our overall customer experience. Are our customers happy? Why or why not? What are the top ten issues customers are reporting? What are the key pain points that they haven’t addressed? And this is where it gets messy. You need to really understand your customer in a fundamental way. They only way you can do this is by spending time with them. Call them focus groups or just taking people out to lunch. If you do not have a direct and personal relationship with your target audience, you will never understand them. If you do not understand them, your ability to predict their needs will basically be zero. And it is the ability to PREDICT their reactions that we really need to develop here. IT isn’t magic. It isn’t cheap and it isn’t quick. If we simply react to expressed user requirements we will never achieve our goals of driving the organization forward. It is the ability to PREDICT their responses in advance that separates the truly great organizations from the mundane sort that we’re all trying to avoid.

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