Cloud and Service Catalog Blog

The Cloudcast Episode 10 - "Clouds on the Storefront Horizon". Where I Talk About Stupid Apps

Recently I did this fun Podcast on clouds touching on stupid apps, network containers. 

We talked about the future of cloud API's and cloud management stack, how well is the self-service concept being received and  we touched on ITIL.

Rodrigo talks about how his world essentially revolves around the concept of change and gives us some tips and tricks to help customers understand how to organize their thoughts and teams around these new self-service models. The bulk of the content on his blog, http://servicecatalogs.typepad.com/servicecatalogs//, is about the mindshift change happening with IT orgs when they start enabling Service Catalogs.

• How is the progress happening in that world?
• Is ITIL the biggest barrier to Self-Service adoption?

And we touched on food as a service models!

John Chambers Keynote: Information Economy to Network Economy

I attended Cisco Live Europe's Keynote yesterday to watch John Chambers give a very thoughtful keynote. The themes that should resonate to readers of this blog.

John touches on transformation, trends, organizational models and the implications of moving from an information economy to a networked economy. Oh and some demos at the end.

Start viewing at 18:00 minute mark.

Video streaming by Ustream

Clouderati vs. Itilista: Thoughts on the Linkage of Cloud and ITIL and Where Twain Fails to Meet

Recently I was speaking with project manager implementing ITIL for the whole service lifecycle. For those, unfamiliar, ITIL is a process framework of 22 processes to manage a service from "Should we do it?" to "How are we are designing it," "How do we operate it" and the end, "We are getting rid of it."

Somewhere in there, the whole how to do it requires a service catalog to design, assemble, offer, order, and deliver the service. - which is why we were talking.

So far so good.

But the project manager, she struggled with how to make all this process framework relevant to her customer, to get the project funded.  So I asked her, "are you building a private cloud?"

A bit of hemm and haw, and out comes a torrential downpour of projects for virtualization, cloud public and private, etc, etc. And her customers she had to sell were the people who were running these projects.

Which explained the focus on the service lifecycle?! It's no good to make server provisioning 5 minutes, if architecture reviews, requirements, design, change management, etc, are all done manually as one-of's bespoke projects that take 6-18 months! 

The real issue is how do you accelerate the throughput of the whole cycle! At the top level, the execs understood this is the real challenge, but down in the implementation level, every one doing the best they can, the forest gets lost, the link unbroken.

So far my observation can be summarized as:

ITIL	Cloud
Focused on process	Focused on automation
Focused on customers	Focused on infrastructure
No linkage to automation, dismissive even	No linkage to business, take that for granted

I don't want to imply that one is better than the other, rather to point out that these are two cultures that need each other, but may not be articulating their concerns and objectives in ways that each can listen and help.

For example, the cloud requires automation of process and policies to speed provisioning of services. Which is why they get annoyed by the ITILISTA focus on manual process.

And ITIL focus on being a  common language sounds plain condescending when your customer truly talks different. "Hey, it's the common language so learn it if you want to be talk right!" just infuriates data center folk

Finally, ITIL lack of focus on automation, getting rid of process steps and rigid definitions completely disables people building clouds from bringing in their objectives, tools, language to the table.

Take change management. Please. <drumsounds>

ITIL prescribes a cumbersome process, very manual, with meetings, etc. In the cloud, we are looking for self-service, instant delivery of computing resource. Should that go through change management?

Your answer will determine whether you are an ITILista or a Clouderati.

Until then, it remains cloudy, with a chance of ITIL.

The Cloud Changes the Emphasis of ITIL. Response to Troy's: ITIL Castles in the Cloud.

So my friend Troy starts this great discussion: ITIL Castles In the Cloud. With song!  Read on: 

Rhetorical Question: But wait I thought that cloud computing strategies are meant to simplify IT service provisioning? I cut the supplier a check and they take care of rest right?

Response: In one sense this is a correct, since you are paying an external supplier to provide a complete service outcome. The service can come in the form of an account for a hosted software service, a development platform or a set of virtual infrastructure components without you having to own or manage the physical assets. However, on the other side of coin it is critical to understand that what you are also doing is introducing a new set of players into your existing IT management processes. Just as Young Cosette discovered in the musical Les-Miserables we still have to sweep the floors and take care of business even when we live in the clouds.

[At The End Of The Day - Les Miserables]

At the end of the day you get nothing for nothing Sitting flat on your butt doesn’t buy any bread

And several people join including IT Skeptic and Matthew Hooper with really great insights that I'm in violent agreement with.  This a topic I've written about before: What responsibility and visibility does IT need to have when engaging a service provider? Well cloud computing is bringing this issue back to the table with a lot of force. 

My response is: 

But there are differences worth thinking about with cloudcomputing. As a user of Amazon EC2, I'm running about 81 instances, several hundred gig of data, and multiple vlans.

And it's forced me to think differently about systems. For example, lifecycle management has become way more important than standard system configuration. We have one image, we test the hell out of it, but then the next 80 servers are all the same image. Traditional cms would have me monitor the internals of 80 servers.

Assets are not that useful, because the real issue becomes subscription lifecycle management because of the liability issue. As long as it's on, Amazon bills me.

Capacity management is a non-issue because of the elasticity, but I better have a good contact at the provider.

Monitoring also becomes different. My cloud is a black box beyond a certain point, but I can monitor uptime, performance. But really, I can't do anything about the machine, OS, Storage and Network. In fact, I build that lack of knowledge into the app architecture -- an instance will fail, so I build that assumption and not worry when it does fail. I report no problem and do no root cause analysis on that part of the infrastructure. I do it on my application, of course.

So my take is: the old stuff applies but the emphasis will be very different than in-house IT.

And yes, I'll provide a song to end with a cloud motif, Paper Planes by MIA!

No one on the corner has swagger like us
Hit me on my Burner prepaid wireless
We pack and deliver like UPS trucks
Already going hell just pumping that gas

What Does CloudComputing Have to Do with ITIL and Me? The Impact of vCloud

For my regular readers, you may have noticed that I've been talking a lot about cloud computing recently. In particular earlier this week I wrote about the impact of VMware's vCloud API announcement.

So I thought I'd take a moment to write about why this is relevant to ITIL and ITSM practitioners.  

In a nutshell, the vCloud API makes all clouds, public and private, look the same to a service catalog tool.  In other words, as you work in defining your service catalog, as long as you ensure certain attributes are there, that request can be provisioned automatically by any service provider who supports that interface: internal or external.

This has big implications for the future operating model of IT, and that includes the usage of ITIL processes.  Luckily for me, Randy Bias, wrote an excellent blog entry about it. So I'll quote a few parts and comment and recommend that you read the rest.

So let's start here:

Cloud Computing as Business Enablement
One of the core propositions of cloud computing that I regularly espouse is the notion of ‘cloud’ being an operational process change and NOT a technology or simple outsourcing.  This is frequently lost in the hype around ‘auto-scaling‘ and such.  By an operational process change I mean two-fold:

1. Creation of ’self-service’ IT for cloud consumers
2. Extensive automation for IT itself, allowing a self-service delivery model

By ’self-service’ I mean: on-demand, pay-as-you-go, and use-only-what-you-need.  By automation, I mean removing the human element in provisioning and managing IT infrastructure.

Whether you realize it or not, right now IT is largely a craftsman’s trade whereby apprentices learn from masters.  It has been unable, despite the best intentions, to evolve into a disciplined profession like manufacturing by itself without a forcing function.[1]

Cloud computing is that forcing function and CIOs everywhere are waking up to it.

This is the first place where your work in creating a service catalog really becomes very important or not. For the cloud operating model to work, we must do away with the notion of a catalog as a document, and focus on the service definition as an atomic product that can drive delivery and provisioning automatically. And as Randy says, that delivery needs to be thought from an automation perspective rather than the traditional back and forth of a change management process. 

(By the way, at VMworld I saw more people talking and showing self-service than at last year's ITSMF show. And service catalog was lauded as key enabler during the key note -- I haven't seen that at any ITSM show yet.)

We are looking to deliver these environments in minutes and hours, not weeks and months. 

He goes on to say:

Perhaps more importantly, to derive the maximum value from cloud computing’s disruptive force, we must have standards.  De facto or otherwise.  How would the railway systems work without standard track gauges?  What about telecommunications systems?  Or the national power system?  The answer is that they can’t.

Standards are critical to the success of cloud computing and it’s ability to transform IT into a business enabler that can be run transparently like many other parts of the business.

The data center can no longer be a black box!

Randy is referring to the vCloud API, but the reality is that you need more standards than just that. First, IT needs to get its house in order and figure out what are the standard service packages, model the service components, create bundles out of already-automated atomic services to then drive the usage of these cloud services.

Compare what I'm proposing to the traditional 15 page spreadsheet of endless questions that 12 people around a table have to meet for in order to get the datacenter to provide an environment.  That's going the way of music industry.

Since this is a blog about ITSM and ITIL service catalogs, I thought the following quote is a good provocation.

Some will point at ITIL or CoBIT, but the reality is that documenting ‘meatcloud’ processes is not the same as removing the human from the equation; IT is more similar to manufacturing than to the legal or medical professions.  The legal and medical professions are predicated on delivering a certain kind of human talent or skill.  Manufacturing and IT are infrastructure and must be predicated on delivering repeatable, measurable, business value.

I agree with the sentiment.  For me, this means stop looking at the service catalog as documentation project and start looking at it as an automation project.  Not for the whole thing, but certainly for some parts like server, network and storage. Many customers have been doing identity and desktop for a while; it should not be a revolutionary step.

But let's hold a second with the hype, lest you think my head is going cloudy.   I do believe this change is going to take a while, but I don't believe it'll be gradual. 

What I'm seeing is that IT organizations are now thinking of cloud and making some plans to play, but the sudden change in economic fortunes and subsequent layoffs have forced the new team to adopt cloud computing for applications that as little as 6 months ago it would have been unimaginable.  It's not that IT leadership changed, rather IT leadership GOT changed.

There will still need to be many governance and control steps which will be manual, but ... even many of those can be addressed by a service catalog that implements good Role Based Access Control and service profile policies.  Translated to English, it means that rather than manual steps, the catalog figures out what services you are allowed to use and the constraints and changes you are allowed to make.

Essentially, it's a set of pre-approved policy driven requests. Need a small linux testing for 30 days and you are a QA person? Boom, you got it.  Don't even need to approve it because the policy says you have the right and capacity has been reserved for QA. Of course, you better have figured out what your service is and who are the customers of that service.

So what does this mean to you today?  This is a topic I'd like to write more about, but here are my early thoughts in no particular order.

• ITIL practitioners should be be talking closely the server and virtualization folks to close the gap.  They may turn out to be your best allies.

• I'd think hard about the utility and value of the service catalog as a cloud enabler.  It is absolutely going to be; the question on the table is, will it be yours?

• I'd start asking my vendors to show you how they are preparing to meet this new opportunity and how they can guide you in your project.

• Personally, I'd spend some time getting acquainted with Amazon -- it's a credit card away and pretty cheap -- to get some sense of what works.  If you are technically inclined, read the vCloud API intro.

What Does CloudComputing Have to Do with ITIL and Me? The Impact of vCloud

For my regular readers, you may have noticed that I've been talking a lot about cloud computing recently. In particular earlier this week I wrote about the impact of VMware's vCloud API announcement.

So I thought I'd take a moment to write about why this is relevant to ITIL and ITSM practitioners.  

In a nutshell, the vCloud API makes all clouds, public and private, look the same to a service catalog tool.  In other words, as you work in defining your service catalog, as long as you ensure certain attributes are there, that request can be provisioned automatically by any service provider who supports that interface: internal or external.

This has big implications for the future operating model of IT, and that includes the usage of ITIL processes.  Luckily for me, Randy Bias, wrote an excellent blog entry about it. So I'll quote a few parts and comment and recommend that you read the rest.

So let's start here:

Cloud Computing as Business Enablement
One of the core propositions of cloud computing that I regularly espouse is the notion of ‘cloud’ being an operational process change and NOT a technology or simple outsourcing.  This is frequently lost in the hype around ‘auto-scaling‘ and such.  By an operational process change I mean two-fold:

1. Creation of ’self-service’ IT for cloud consumers
2. Extensive automation for IT itself, allowing a self-service delivery model

By ’self-service’ I mean: on-demand, pay-as-you-go, and use-only-what-you-need.  By automation, I mean removing the human element in provisioning and managing IT infrastructure.

Whether you realize it or not, right now IT is largely a craftsman’s trade whereby apprentices learn from masters.  It has been unable, despite the best intentions, to evolve into a disciplined profession like manufacturing by itself without a forcing function.[1]

Cloud computing is that forcing function and CIOs everywhere are waking up to it.

This is the first place where your work in creating a service catalog really becomes very important or not. For the cloud operating model to work, we must do away with the notion of a catalog as a document, and focus on the service definition as an atomic product that can drive delivery and provisioning automatically. And as Randy says, that delivery needs to be thought from an automation perspective rather than the traditional back and forth of a change management process. 

(By the way, at VMworld I saw more people talking and showing self-service than at last year's ITSMF show. And service catalog was lauded as key enabler during the key note -- I haven't seen that at any ITSM show yet.)

We are looking to deliver these environments in minutes and hours, not weeks and months. 

He goes on to say:

Perhaps more importantly, to derive the maximum value from cloud computing’s disruptive force, we must have standards.  De facto or otherwise.  How would the railway systems work without standard track gauges?  What about telecommunications systems?  Or the national power system?  The answer is that they can’t.

Standards are critical to the success of cloud computing and it’s ability to transform IT into a business enabler that can be run transparently like many other parts of the business.

The data center can no longer be a black box!

Randy is referring to the vCloud API, but the reality is that you need more standards than just that. First, IT needs to get its house in order and figure out what are the standard service packages, model the service components, create bundles out of already-automated atomic services to then drive the usage of these cloud services.

Compare what I'm proposing to the traditional 15 page spreadsheet of endless questions that 12 people around a table have to meet for in order to get the datacenter to provide an environment.  That's going the way of music industry.

Since this is a blog about ITSM and ITIL service catalogs, I thought the following quote is a good provocation.

Some will point at ITIL or CoBIT, but the reality is that documenting ‘meatcloud’ processes is not the same as removing the human from the equation; IT is more similar to manufacturing than to the legal or medical professions.  The legal and medical professions are predicated on delivering a certain kind of human talent or skill.  Manufacturing and IT are infrastructure and must be predicated on delivering repeatable, measurable, business value.

I agree with the sentiment.  For me, this means stop looking at the service catalog as documentation project and start looking at it as an automation project.  Not for the whole thing, but certainly for some parts like server, network and storage. Many customers have been doing identity and desktop for a while; it should not be a revolutionary step.

But let's hold a second with the hype, lest you think my head is going cloudy.   I do believe this change is going to take a while, but I don't believe it'll be gradual. 

What I'm seeing is that IT organizations are now thinking of cloud and making some plans to play, but the sudden change in economic fortunes and subsequent layoffs have forced the new team to adopt cloud computing for applications that as little as 6 months ago it would have been unimaginable.  It's not that IT leadership changed, rather IT leadership GOT changed.

There will still need to be many governance and control steps which will be manual, but ... even many of those can be addressed by a service catalog that implements good Role Based Access Control and service profile policies.  Translated to English, it means that rather than manual steps, the catalog figures out what services you are allowed to use and the constraints and changes you are allowed to make.

Essentially, it's a set of pre-approved policy driven requests. Need a small linux testing for 30 days and you are a QA person? Boom, you got it.  Don't even need to approve it because the policy says you have the right and capacity has been reserved for QA. Of course, you better have figured out what your service is and who are the customers of that service.

So what does this mean to you today?  This is a topic I'd like to write more about, but here are my early thoughts in no particular order.

• ITIL practitioners should be be talking closely the server and virtualization folks to close the gap.  They may turn out to be your best allies.

• I'd think hard about the utility and value of the service catalog as a cloud enabler.  It is absolutely going to be; the question on the table is, will it be yours?

• I'd start asking my vendors to show you how they are preparing to meet this new opportunity and how they can guide you in your project.

• Personally, I'd spend some time getting acquainted with Amazon -- it's a credit card away and pretty cheap -- to get some sense of what works.  If you are technically inclined, read the vCloud API intro.

What Does CloudComputing Have to Do with ITIL and Me? The Impact of vCloud

For my regular readers, you may have noticed that I've been talking a lot about cloud computing recently. In particular earlier this week I wrote about the impact of VMware's vCloud API announcement.

So I thought I'd take a moment to write about why this is relevant to ITIL and ITSM practitioners.  

In a nutshell, the vCloud API makes all clouds, public and private, look the same to a service catalog tool.  In other words, as you work in defining your service catalog, as long as you ensure certain attributes are there, that request can be provisioned automatically by any service provider who supports that interface: internal or external.

This has big implications for the future operating model of IT, and that includes the usage of ITIL processes.  Luckily for me, Randy Bias, wrote an excellent blog entry about it. So I'll quote a few parts and comment and recommend that you read the rest.

So let's start here:

Cloud Computing as Business Enablement
One of the core propositions of cloud computing that I regularly espouse is the notion of ‘cloud’ being an operational process change and NOT a technology or simple outsourcing.  This is frequently lost in the hype around ‘auto-scaling‘ and such.  By an operational process change I mean two-fold:

1. Creation of ’self-service’ IT for cloud consumers
2. Extensive automation for IT itself, allowing a self-service delivery model

By ’self-service’ I mean: on-demand, pay-as-you-go, and use-only-what-you-need.  By automation, I mean removing the human element in provisioning and managing IT infrastructure.

Whether you realize it or not, right now IT is largely a craftsman’s trade whereby apprentices learn from masters.  It has been unable, despite the best intentions, to evolve into a disciplined profession like manufacturing by itself without a forcing function.[1]

Cloud computing is that forcing function and CIOs everywhere are waking up to it.

This is the first place where your work in creating a service catalog really becomes very important or not. For the cloud operating model to work, we must do away with the notion of a catalog as a document, and focus on the service definition as an atomic product that can drive delivery and provisioning automatically. And as Randy says, that delivery needs to be thought from an automation perspective rather than the traditional back and forth of a change management process. 

(By the way, at VMworld I saw more people talking and showing self-service than at last year's ITSMF show. And service catalog was lauded as key enabler during the key note -- I haven't seen that at any ITSM show yet.)

We are looking to deliver these environments in minutes and hours, not weeks and months. 

He goes on to say:

Perhaps more importantly, to derive the maximum value from cloud computing’s disruptive force, we must have standards.  De facto or otherwise.  How would the railway systems work without standard track gauges?  What about telecommunications systems?  Or the national power system?  The answer is that they can’t.

Standards are critical to the success of cloud computing and it’s ability to transform IT into a business enabler that can be run transparently like many other parts of the business.

The data center can no longer be a black box!

Randy is referring to the vCloud API, but the reality is that you need more standards than just that. First, IT needs to get its house in order and figure out what are the standard service packages, model the service components, create bundles out of already-automated atomic services to then drive the usage of these cloud services.

Compare what I'm proposing to the traditional 15 page spreadsheet of endless questions that 12 people around a table have to meet for in order to get the datacenter to provide an environment.  That's going the way of music industry.

Since this is a blog about ITSM and ITIL service catalogs, I thought the following quote is a good provocation.

Some will point at ITIL or CoBIT, but the reality is that documenting ‘meatcloud’ processes is not the same as removing the human from the equation; IT is more similar to manufacturing than to the legal or medical professions.  The legal and medical professions are predicated on delivering a certain kind of human talent or skill.  Manufacturing and IT are infrastructure and must be predicated on delivering repeatable, measurable, business value.

I agree with the sentiment.  For me, this means stop looking at the service catalog as documentation project and start looking at it as an automation project.  Not for the whole thing, but certainly for some parts like server, network and storage. Many customers have been doing identity and desktop for a while; it should not be a revolutionary step.

But let's hold a second with the hype, lest you think my head is going cloudy.   I do believe this change is going to take a while, but I don't believe it'll be gradual. 

What I'm seeing is that IT organizations are now thinking of cloud and making some plans to play, but the sudden change in economic fortunes and subsequent layoffs have forced the new team to adopt cloud computing for applications that as little as 6 months ago it would have been unimaginable.  It's not that IT leadership changed, rather IT leadership GOT changed.

There will still need to be many governance and control steps which will be manual, but ... even many of those can be addressed by a service catalog that implements good Role Based Access Control and service profile policies.  Translated to English, it means that rather than manual steps, the catalog figures out what services you are allowed to use and the constraints and changes you are allowed to make.

Essentially, it's a set of pre-approved policy driven requests. Need a small linux testing for 30 days and you are a QA person? Boom, you got it.  Don't even need to approve it because the policy says you have the right and capacity has been reserved for QA. Of course, you better have figured out what your service is and who are the customers of that service.

So what does this mean to you today?  This is a topic I'd like to write more about, but here are my early thoughts in no particular order.

• ITIL practitioners should be be talking closely the server and virtualization folks to close the gap.  They may turn out to be your best allies.

• I'd think hard about the utility and value of the service catalog as a cloud enabler.  It is absolutely going to be; the question on the table is, will it be yours?

• I'd start asking my vendors to show you how they are preparing to meet this new opportunity and how they can guide you in your project.

• Personally, I'd spend some time getting acquainted with Amazon -- it's a credit card away and pretty cheap -- to get some sense of what works.  If you are technically inclined, read the vCloud API intro.

Paul Maritz, VMware CEO - General Session Keynote Mentions Service Catalog

Paul Maritz presented their view of the Front Office of IT, that includes Service Catalog, Self-service, charge back and service profiles.  This is all about offering cloud services.

In other words, VMware has really bought into newScale's Front Office vision; which is great.

However, based on the Lifecycle Manager lab that I attended last night, their 'catalog' is still very much focused on the back-end mechanics. It's a good step but has a few years to mature.

So overall, I'm very pleased by this development. It validates what I've been writing for a while. IT needs to be able to make offers to manage demand. Cloud is all about standard offerings.

Paul Maritz, VMware CEO - General Session Keynote Mentions Service Catalog

Paul Maritz presented their view of the Front Office of IT, that includes Service Catalog, Self-service, charge back and service profiles.  This is all about offering cloud services.

In other words, VMware has really bought into newScale's Front Office vision; which is great.

However, based on the Lifecycle Manager lab that I attended last night, their 'catalog' is still very much focused on the back-end mechanics. It's a good step but has a few years to mature.

So overall, I'm very pleased by this development. It validates what I've been writing for a while. IT needs to be able to make offers to manage demand. Cloud is all about standard offerings.

Paul Maritz, VMware CEO - General Session Keynote Mentions Service Catalog

Paul Maritz presented their view of the Front Office of IT, that includes Service Catalog, Self-service, charge back and service profiles.  This is all about offering cloud services.

In other words, VMware has really bought into newScale's Front Office vision; which is great.

However, based on the Lifecycle Manager lab that I attended last night, their 'catalog' is still very much focused on the back-end mechanics. It's a good step but has a few years to mature.

So overall, I'm very pleased by this development. It validates what I've been writing for a while. IT needs to be able to make offers to manage demand. Cloud is all about standard offerings.

Killing us softly

There's skepticism about cloud computing and the virtual data center. There ought to be. 

But it does remind me of the proverbial frog in the boiling water  -  getting killed softly.   So when I read this post I was reminded of one of my favorite songs. And I loved the original but this is the one that gets me: Lauryn Hill delivers.

And here's what I mean. Cloud computing may not be ready today, but it's already killing us softly.
Another Half-Dozen Half-Truths of the Cloud.

Killing us softly

There's skepticism about cloud computing and the virtual data center. There ought to be. 

But it does remind me of the proverbial frog in the boiling water  -  getting killed softly.   So when I read this post I was reminded of one of my favorite songs. And I loved the original but this is the one that gets me: Lauryn Hill delivers.

And here's what I mean. Cloud computing may not be ready today, but it's already killing us softly.
Another Half-Dozen Half-Truths of the Cloud.

Killing us softly

There's skepticism about cloud computing and the virtual data center. There ought to be. 

But it does remind me of the proverbial frog in the boiling water  -  getting killed softly.   So when I read this post I was reminded of one of my favorite songs. And I loved the original but this is the one that gets me: Lauryn Hill delivers.

And here's what I mean. Cloud computing may not be ready today, but it's already killing us softly.
Another Half-Dozen Half-Truths of the Cloud.

Using Cloud Computing to Build Your Technical Service Catalog

Cloud computing can be extremely useful to help build your technical service catalog.  I read this short but very illuminating blog post by Gary Orenstein, The Enterprise Impact of Cloud Computing that supports this viewpoint.

Cloud computing brings two major aspect of a service catalog to light: Price transparency and how our customers will interact with our Data Center services. 

A couple of quotes from Gary's post. 

Pricing Transparency — Prepare Your Pencils
Whether businesses jump into cloud computing right away or later on, the pricing transparency from cloud providers completely changes enterprise practices for benchmarking IT costs. Companies routinely spend big bucks to understand IT expenses and effectiveness.
...
Now you can understand exactly how much it costs to rent an x86 server, a terabyte of storage, or a content delivery service with just a few clicks to Amazon Web Services or a host of other providers.

Which is exactly what we hope to achieve with a service catalog, have the customer understand what they are getting and the unit costs they are incurring.

And as to how our customers will interact with IT from now on, Gary writes:

It used to be that deploying a new application meant days or weeks of research, approvals, budgeting, planning and setup. Now it means that individuals outside the enterprise IT domain can pick a service offering of their choice, select a plan, and pay for it themselves. The barriers to start are low, the benefits of scale are high, and the decision gets boiled down to the simplicity of a free trial or impulse purchase.

I agree except that it's not days or weeks, but rather months and quarters. 
How long does it take to get a server into production?  Most enterprises it's 3-4 months, many even more?  How long to configure? Months?  How easy is it for the customers to order, track, understand options, costs?  Very difficult.

This is why I say the IT service catalog is CENTRAL to the next generation data center whether it's virtual, a private cloud or a public cloud.

Without a catalog that defines standard environments, allowed configurations, easy ordering, some sort of provisioning and self-service, customers are going to go their own way, as I've written before on 16 digits to freedom and Amazon has written your technical services catalog.

What do you guys think?  Is it all new, all old, or is there a nuanced view between hype and cynicism?

Using Cloud Computing to Build Your Technical Service Catalog

Cloud computing can be extremely useful to help build your technical service catalog.  I read this short but very illuminating blog post by Gary Orenstein, The Enterprise Impact of Cloud Computing that supports this viewpoint.

Cloud computing brings two major aspect of a service catalog to light: Price transparency and how our customers will interact with our Data Center services. 

A couple of quotes from Gary's post. 

Pricing Transparency — Prepare Your Pencils
Whether businesses jump into cloud computing right away or later on, the pricing transparency from cloud providers completely changes enterprise practices for benchmarking IT costs. Companies routinely spend big bucks to understand IT expenses and effectiveness.
...
Now you can understand exactly how much it costs to rent an x86 server, a terabyte of storage, or a content delivery service with just a few clicks to Amazon Web Services or a host of other providers.

Which is exactly what we hope to achieve with a service catalog, have the customer understand what they are getting and the unit costs they are incurring.

And as to how our customers will interact with IT from now on, Gary writes:

It used to be that deploying a new application meant days or weeks of research, approvals, budgeting, planning and setup. Now it means that individuals outside the enterprise IT domain can pick a service offering of their choice, select a plan, and pay for it themselves. The barriers to start are low, the benefits of scale are high, and the decision gets boiled down to the simplicity of a free trial or impulse purchase.

I agree except that it's not days or weeks, but rather months and quarters. 
How long does it take to get a server into production?  Most enterprises it's 3-4 months, many even more?  How long to configure? Months?  How easy is it for the customers to order, track, understand options, costs?  Very difficult.

This is why I say the IT service catalog is CENTRAL to the next generation data center whether it's virtual, a private cloud or a public cloud.

Without a catalog that defines standard environments, allowed configurations, easy ordering, some sort of provisioning and self-service, customers are going to go their own way, as I've written before on 16 digits to freedom and Amazon has written your technical services catalog.

What do you guys think?  Is it all new, all old, or is there a nuanced view between hype and cynicism?

Using Cloud Computing to Build Your Technical Service Catalog

Cloud computing can be extremely useful to help build your technical service catalog.  I read this short but very illuminating blog post by Gary Orenstein, The Enterprise Impact of Cloud Computing that supports this viewpoint.

Cloud computing brings two major aspect of a service catalog to light: Price transparency and how our customers will interact with our Data Center services. 

A couple of quotes from Gary's post. 

Pricing Transparency — Prepare Your Pencils
Whether businesses jump into cloud computing right away or later on, the pricing transparency from cloud providers completely changes enterprise practices for benchmarking IT costs. Companies routinely spend big bucks to understand IT expenses and effectiveness.
...
Now you can understand exactly how much it costs to rent an x86 server, a terabyte of storage, or a content delivery service with just a few clicks to Amazon Web Services or a host of other providers.

Which is exactly what we hope to achieve with a service catalog, have the customer understand what they are getting and the unit costs they are incurring.

And as to how our customers will interact with IT from now on, Gary writes:

It used to be that deploying a new application meant days or weeks of research, approvals, budgeting, planning and setup. Now it means that individuals outside the enterprise IT domain can pick a service offering of their choice, select a plan, and pay for it themselves. The barriers to start are low, the benefits of scale are high, and the decision gets boiled down to the simplicity of a free trial or impulse purchase.

I agree except that it's not days or weeks, but rather months and quarters. 
How long does it take to get a server into production?  Most enterprises it's 3-4 months, many even more?  How long to configure? Months?  How easy is it for the customers to order, track, understand options, costs?  Very difficult.

This is why I say the IT service catalog is CENTRAL to the next generation data center whether it's virtual, a private cloud or a public cloud.

Without a catalog that defines standard environments, allowed configurations, easy ordering, some sort of provisioning and self-service, customers are going to go their own way, as I've written before on 16 digits to freedom and Amazon has written your technical services catalog.

What do you guys think?  Is it all new, all old, or is there a nuanced view between hype and cynicism?