Cloud and Service Catalog Blog

The Value of Automation: What Did Captain Kirk Know That Scotty Didn't? & The Roach Motel Infrastructure Issue

Recently, a customer asked me what was the value of using automation to operate a private cloud?  It was a good question. Working  in the middle of the reality distorition field of the cloud industry I take it for granted that everyone knows automation's benefits.

Fundamentally, automation tools help to reduce labor costs, rationalize  consumption and increase utilization.

Costs are lower because the labor required to configure and deploy is eliminate. This automation is possible by creating standard infrastructure offerings. Standard infrastructure offering make possible a new operational model: to move from the artesanal approach of delivering infrastructure ,where every system and configuration is uniqe, to the industrialized approach, that ensures repeatability, quality and agility.  It's the difference between custom tailoring and standardized sizes at The Gap. Both have their place, but one costs more.

The Gap has a self-service catalog.The British bespoke tailor doesn't.  Self-service should not be an after-thought, it's the beginning of the cloud journey.  Self-service drives the standardization of offerings and reduces the labor costs that arise from designing, specifying, ordering, procuring, and configuring computing, storage and network resources on custom basis. 

This standardization and automation is also applied to the application components, security and network services such as LDAP, DNS, load balancers, etc.

Standardization also provides second order benefits through reduction  in the maintenance, procurement and support costs. After all, if the cloud has one management interface, and all compute blades are the same then the whole break/fix cycle gets simplified and procurement is streamlined. 

Automation is all about saving labor. First, the customer saves provisioning labor costs, additional savings are incurred  by reducing errors which means less time fighting fires (labor), and finally, on-going operations (day 2), like applying patch also result in  labor reduction.

The interesting metrics here are the number servers per administration and the number of errors before and after automation is deployed.. As you know, every incident/fire causes a hailstorm of work for a bunch of people.  Imagine if automation detected the error, and fixed it before it became a problem? Well that's what Cisco Intelligent Automation does for compute, network and even SAP.

Utlization: What did Captain Kirk know that Scotty didn't?

The third source of cost reduction, increasing utilization, is probably the biggest opportunity for cloud.  

Yet it is the hardest for IT professionals to achieve because it requires applying a combination of psychology, market dynamics and technology. 

Two big costs in the datacenter are the over-provisioning of capacity and the hoarding of infrastructure by application teams. Introducing service-tiers with different capabilities, costs and delivery options underpinned by automation can be very effective in changing user behavior.

Over provisioning happens because without the ability to quickly and automatically provision services, it’s safer for both IT and the user to deploy the requested capacity. The result is that a lot of VM’s sit there idly at 3% and the operations staff can’t intelligently manage consumption because they don’t have the original request specification and service tier committed. 

As to what did Captain Kirk know that Scotty didn't?  He knew how to balance engine utilization and the mission. Sometimes, Scotty, she can take Warp 10.

In fact, a lot of upfront friction in the design, estimating, specifying happens because the infrastructure teams are trying to ascertain (guess) the real needs of the application, i.e. the mission, so they don't over or under provision.  

Meanwhile, the application teams don't want to get caught short because a) they'll get yelled at by the customer if the app is a great success, and b) it takes so long to deploy additional capacity that to be wrong is exactly like an outage.

That's how workloads becomes gold plated. Every one's happy, but the CFO.   The CFO then makes the CIO suffer, and that's how IT and the business get out of alignment. Automation is the infrastructure chiropractor; it helps bring back IT operations and the customer back in alignment.

Self-service and automation start to change this situation. It starts with Introducing a few service offering with standardized service tiers, backed by self-service and automation changes the dynamic of the conversation.

A bronze level service for QA and  development, available in a few minutes, with minimum support might be better than a whole production stack that takes 8 weeks. (It is: that's why people go to Amazon!). 

Over the last ten years, newScale, now part of Cisco,  worked with hundreds of customers and we learned psychology and market forces can be used to shape demand.  Getting something NOW, and cheaper turns out to be a better choice for many users over "perfect later." Introducing quotas and leases, makes the customer a more engaged partner in managing capacity. Putting coss and prices, even in the absence of chargeback decreases demand. Why? Because human beings are wired that way.

And the technology has changed. Converged infrastructure like Cisco Unified Computing platform or VCE's vBlock or NetApp's FlexPod offering when paired with automation and the service catalog keeps the mission and the service level "unified" from the customer view to the operations view down to the actual hardware. This is new and it's getting wide adoption by infrastructure groups.  The ability to

Hoarding: The roach motel of infrastructure management

Hoarding has similar dynamics. When it’s difficult and burdensome to obtain infrastructure resources, when  the process takes months, there’s a tendency to want to keep the resources forever as the customer knows they might those servers them again.So like the proverbial roach motel, resources go out to customers, but never come back.

Automation changes this dynamic: once the customers see they can get resources get provisioned in minutes, the psychology changes. A user now starts to think: "why spend time renewing a lease for an app I'm not using if I know I can get it back in minutes next time I need it? Plus my boss will get the bill and she is going to ask me if I'm still working on that old project?"  

Show them the money!

The final costs savings come from introducing metering and charging. It changes customer behavior and reduces over provisioning to begin with. With dedicated virtual or physical infrastructure, the business paid for it upfront though capital expenditures, the equipment was used and now it sits there idle wasting power, space, licenses and labor. 

And from the point of view of the users Infrastructure is "free" so why do anything about? Plus what could be done? Nothing.  In a capital expenditure model driven by business unit P&L, there really wasn't that much IT people could do.

Subscriptions up-end this model.  A cloud subscription becomes an on-going operational expense that goes on forever unless it's turned off. This changes the psychology and behavior of the organizations.

To get a sense of the emotions unleased by showing the money, please click here.

(On a personal note, this forever subscription would cause my colleagues and I sometimes to go on hunting expeditions on the Amazon cloud, looking for machines to terminate.  Someday, I'l make a game out of it.)

To end, over provisioning and hoarding are holding hostage a large chunk of a datacenter’s resources. When the user has confidence they can get infrastructure on demand they tend to hoard less, and when leases, quotas and lifecycle visibility is available more infrastructure is freed up.

The Cisco Cloud Portal shows the user exactly what they are consuming, shows the boss what the team is consuming and it shows up in the P/L, the behavior changes. Quickly.

 

A Private Cloud Case Study: Cisco on Cisco

There is a lot of discussion about private cloud and how to do one. 

As part of the new data center launch, Stephanie Carullo (Cisco VP data center architecture) interviewed Rebecca Jacoby (Cisco CIO) and John Manville (Cisco VP of IT): http://www.ustream.tv/recorded/17250844

It’s a long video about our new datacenter and our private cloud. Starting at minute 27 for a brief overview of CITEIS and the value that Cisco IT has achieved with Cisco Intelligent Automation for Cloud (newScale and Tidal).

 

Video streaming by Ustream

A real life example of Cisco's Private Cloud. Cisco Cloud Portal and Orchestrator driving Vmware vCloud Director

This is what everybody has been asking for!

This overview introduces CITEIS Gen 2, which is Cisco's private cloud in our new Green data center in Allen, TX. . Any Cisco employee can go to Cisco Cloud Portal and order a virtual app. Our orchestration tool, Tidal Enterprise Orchestrator, automates and integrates all the previously manual tasks to deliver a coherent, integrated experience to the user.

Underneath, we are using Vmware vCloud Director (which the user doesn't see) as the cloud management layer. 

While Cisco was already 75% virtualized, and popping a VM took 15 minutes, it still took several days to do the end to end process. Now it's 15 minutes through self-service, with a standard 30 day lease

This also has significant impact on costs by eliminating steps such a "where should we put it?", procure it, install it, configure it, secure it and the attendant follow ups of "Is it ready?". So it's on-demand, great for sandbox experiments, minimal SLA and support and charged as consumed.

This demo is phase one and is live and in production. Phase two is coming up shortly, which will provision entire virtual data centers and will have a service assurance offering as well.

Cisco Intelligent Automation: How to be prepared for converged networks and clouds deployment. In which, I'd make a great Bond villain

At Cisco Live last week, Wayne and I did a short video panel on cloud with Jay on converged networks and cloud deployment. Yes, we did talk self-service and catalog. 

Wayne who used to work at VERYBIGCO, used to have an SLA of 43 to provision a server... Well, now it has to be be five minutes This completely upends the current IT operating model, throws it under a truck and drives over it, back up and makes sure it's dead.

So what to do?  My main point is that in terms of private cloud, start small, but start. There's so much to learn, but at this stage, you have to do it to learn it. For example, there's this issues with the silos 

By the way, with my looks and accent, i'd make an excellent Bond movie villain. I could say, "Private cloud, Mr. Bond?, No, I'll give you public cloud. BWAAHAAHAA." 

Ok, here's the video.

Science and Art of Cloud Self-service. A Demo of NetApp, vCloud Director and Cisco Demystify Cloud and Bridges to ITSM

You are about to see a fantastic demo. I have divided this post into two parts: The Science and the Art.

The Science

The following demonstration puts a pragmatic face to self-service cloud operations. It provides both the "Front Office" view and the "Factory" view so you can see how this new fangled world is LIKE and NOT LIKE the existing world.

First, we see a Service Provicer administrator (Giri) contract, design and deploy a set of virtual datacenters at different service levels from a single screen. He provisions compute, apps, network and storage services.So it is like what we do today, but rather than requiring a bunch of silos, meetings, documents it's all done instantly. So it's ITSM done agile.

The key is strong standardization coupled with converged infrastructure from NetApp and Cisco with Vmware's vCloud DIrector providing the datacenter abstration.

This new way leans heavily in abstracting operations through the creation of standardized technical service offerings, which then get aggregated. choreographed and  consumed as a larger service offering in the Cisco Cloud Portal (ex-newScale).

You then get to see how the Factory in NetApp and vCloud deploying the requested datacenters in minutes. 

This is then followed by a different end user who needs an Oracle Financials environment - could be for test, development, performance testing, training, auditing, or even production.

The newScale catalog guides the user through all the proper questions to deploy the user's infrastructure.

 

The Art of service catalog

As you watch the demo, you'll see the screens ask certain questions of the person on-boarding the tenant.  The choices provided maybe unfamiliar to some. The choices may be too restrictive for others.

This is where the art and science of service catalog meet.  The set of questions and choices need to be appropriate to the role of the user, in this case an administrator for a service provider. And they need to balance the need for simplification so a customer can choose with ease and confidence, with the need for sufficient flexibility to accomodate different needs. 

This is where the science of technology meets the art of marketing and customer knowledge.  By definition, standard offerings remove choices in exchange for agility and cost-savings.

Where the service catalog software begins to shine is that we may take the same underlying technical service offerings, and package them for a different audience with a completely different set of choices and questions appropriate for that customer. 

For example, we could decide our customer is the telecom facilities manager in charge of deploying voice-over-IP telephones plus video conferencing.  We could then ask questions about the number of phones and video rooms, the size and quality requirements, etc, etc. Those questions and choices, are then translated into the technical specifications that drive the configuration vCloud, NetApp and Cisco UCS. Including deploying the proper telephony and video infrastructure for that application. 

So don't get stuck on choices and questions in this demo, they will vary depending on the audience, role and application requirements.  Instead of your mileage may vary, your service catalog experience wil may vary. 

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!

Incomplete Thoughts on the Service Catalog and Automation. There's That Hopey-Changy Thing Working for Me

ITSM and cloud computing should be married, but some times I feel like the child of divorced parents.

I'm often tugged to explain the one to the other; condemned to be the unfelicitous Hermes between them. And we know how well THAT works. 

I either get condescending nods of fake understanding, like some do to a child --"Yes, of course. But we have to be pragmatic / realistic/ grown up." And all I wanted was a Pepsi or VM.

Or I get is a good thrashing for being technology centric - Hey  we can do a service catalogue with roll of toilet paper. It's people and process, Senor vendor stupido.  Or... "That service model talk is too theoretical, we have some VM's to spin up."

But it's Spring and there's that Hopey thing working for me. So here are some observations on the cloud / catalog journey.

Cloud computing is a new operational model focused on delivering business agility through process innovation and delivery of everything an enterprise does-as-a-service.

The "new" thing here is that you can think of a service as an abstraction of underlying infrastructure that makes it consumable by a user. There's one part that is customer facing, and one part that is hidden from the user.

In cloud computing, that customer facing part is the cloud API that defines what's available, the ordering parameters, and other elements that lead to a "good and valid order." The service catalog is where this abstraction gets expressed in human understandable terms and choices. It's where the order takes place, and where the customer will manage the lifecycle and consumption of her service.

To use my by now-fatigued restaurant analogies, the item on the menu is an abstraction of food useful for ordering by the customer and useful for the kitchen to know which ingredients and tasks are needed to that standard meal, like a BK Whopper.

You really want to understand how standardization works?  Check the cash register of BK. It has buttons for extra cheese, no mayo, add mustard.  Check the one in MickeyD's and they don't have those buttons. The menu is actionable at the ordering point.

So far, these concepts should be pretty familiar to my regular readers. But with cloud we are going to take it one step farther: all the food preparation and delivery will be done automatically, without any manual handling to enable the delivery of the service. 

In other words, we are not "improving" the process, we are completing eliminating the process by automating all the rules, steps, and data into code. This takes a process from days, weeks or months to seconds and minutes. These automated processes ensure that changes, patches, fixes propagate at large scale and errors are automatically dealt with.

It also means the automated infrastructure is constantly being changed by software. And this is only possible because the cloud model strives for operational simplicity.

This is not easy for datacenter people nor ITSM people.

For datacenter people, the notion of creating standard offers with few if any variants (thik manufacturing instead of custom builds), of having to guess what customers might want (marketing research), to limit a customer's configuration (product management) is hard.

They are used to custom building infrastructure around an application, not the other way around

To have to think of capacity management from how do I ensure I have enough resources for the peak performance needs of an application and so no one yells at me, is new.  To have to think of capacity management as demand management (finance and vendor management) is not in the experience-shelf of the cloud team. To think of capacity as sweating an asset as much as possible? Not the usual way of the datacenter; no one wants to see a server sweat, hence the cooling.

Some of these skills are part of what ITSM folk already do, like financial management, service design, demand management, and service catalog. One would think data center folk would be looking to ITSM folk like a settler watching the cavalry arriving to the rescue.  Instead, they are often pointing the guns in that direction.

This is because much of ITSM has traditionally focused process as in procedures, tasks, people, etc.  Which is fine as part of a journey. But when the focus is automation, the journey changes: the focus moves to standarization, simplification and automation.  And this requires technical skills and know how.

From the point of view of the service catalog, it requires tight definitions that include the underlying resources to be provisioned: it could be a virtual machine (VM). If so, what are the technical attributes that need to be specified to get a "good and viable" order? Once we have that, are there options and standards? Are the packages this VM will be part of?  Should we even offer a VM or is it really a higher level offering, like a SQL test environment? What are the roles and what will they see?

All this gets loaded into the technical catalog, forms created, rules set, connected to the cloud automation layer. The lifecycle manager (think of it as cmdb that works) now kicks in an tracks what the user ordered and provide further choices for changes.

I could go on and  on, and I probably will another time.

Which is why I wish mom and dad would get along because we need both to make succesful clouds. So in the spirit of Spring and the hopey changy thing, I encourage my ITSM people to get their hands cloudy.

-------------

Disclaimer: My parents are happily married for 49 years so far...

 

Are You in Catering? Or Are You a Restauranteur? Different Models for IT Service Management (via @TroyDuMoulin)

Since cloud is a new operating model for IT folk, I think this post from my friend Troy DuMoulin should be very useful.

Fundamentally, the struggle IT organizations have master on their way to providing and / or consuming cloud services is the standardization of offerings. This requires se move from the make anything you want to order (like a wedding caterer) to one where there's a reasonable amount of standardization to ensure low cost, self-service and agile deployment. 

This is tough for the typical IT organization. On the one hand if the IT operations group is going to create standards that work, they better engage with the user community to underestand their needs. And for this to work on a self-service, on-demand way, then there will have to be a healthy focus on automated provisioning which means understanding the relevant governance processes that need to automated, eliminated, changed, and/or supported. 

So with that said, here's a visual from Troy that should help.

To illustrate this concept I have developed the following visual:

Certain Processes / Outcomes require more of a craft approach while others demand Process formality, a high degree of standardization and minimized variance.

To assist with this concept Hayes and Wheelwright introduce the following Manufacturing Concepts:

• Engineer To Order: Each time a customer has a request we apply unique specialist knowledge to develop tailored solutions based on one of a kind requirements. Think about Engineering or Application Development type processes. (perfect for low volume)
• Make To Order: looks at the concept of doing something consistently in a batch format. We will follow a common method for a certain process or IT system during the project lifecycle but the next project may use a totally different approach.
• Assemble To Order: We provide unique offers based on the assembly of pre-defined and approved components. Go to the service catalog and order a standard laptop but add options such as memory, disk drives or approved applications. (Balance between consistency and flexibility)
• Make To Stock: Due to cost, regulatory, risk drivers we have to ensure that every time the widget comes off the assembly line or the release is deployed it happens the same way to minimize variance. (necessary for high volume)

via blogs.pinkelephant.com

Lawyering For The Cloud Win. A Primer for Corporate Counsel from EMC

The two biggest objections to cloud computing are security and compliance / regulations. I believe both have some validity but I also believe both can be used as excuses to bury heads into sands and holes.

And I believe shining a light is the best way to assess risk. So it's with great delight I found this article: Cloud Computing Down to Earth: A Primer for Corporate Counsel which starts to list the types of risks that need to be enumarated. 

These include:

1. unauthorized access to confidential client information by a vendor’s employees (or sub-contractors) or by outside parties (e.g., hackers) via the Internet, see id.;
2. the storage of information on servers in countries with fewer legal protections for electronically stored information (“ESI”), see id. at 4, which can be especially problematic in regulated industries that have highly defined requirements with respect to the handling of ESI throughout its life cycle;
3. a vendor’s failure to back up data adequately, see id.;
4. the ability to access corporate data using easily accessible software in the event that the corporation terminates its relationship with the cloud computing provider or the provider goes out of business, see id.;
5. the provider’s procedures for responding to (or when appropriate, resisting) government requests for access to information, see id. What if, for example, a government (domestic or foreign) seizes the actual servers (i.e. hardware) on which Corporation A’s confidential and highly regulated data resides in order to take control of Corporation B’s data, which resides on the same shared, multitenant server?;
6. policies for notifying the corporation of security breaches, see id., so that counsel can immediately fulfill her duties with respect to client notification under Model Rule of Professional Conduct 1.4;
7. insufficient data encryption, see id.;
8. unclear policies regarding the corporation’s ability to “control” its own data, which may result in a quandary if served with a request for production of materials under Rule 34 of the Federal Rules of Civil Procedure;
9. policies for data destruction when the corporation no longer wants the relevant data available or transfers it to a different host, see id.
10. the potential warrantless seizure of corporate electronic mail under the anachronistic Electronic Communications Privacy Act of 1986 (“ECPA”), 18 U.S.C. § 2510, which includes the Stored Communications Act, 18 U.S.C. §§ 2701-12. Signed into law in 1986, the ECPA established a procedural framework for law enforcement authorities to obtain wire and electronic information, including files stored on a computer. Think Miami Vice, not cloud computing. Only two months ago, the Sixth Circuit in United States v. Warshak (6th Cir. Dec 14, 2010), held valid based on the government’s dubious reliance on the Stored Communications Act a warrantless seizure of corporate e-mails notwithstanding a lengthy and informed exposition on the relationship between technology and the Fourth Amendment, see id. slip op. at 14-29.

Actually, as I read these, the ones that I think unique to cloud are 7,8,9, and 10. It's not that 1-6 are not realistic, is that these are existing problems for any outsourcing deal, or internet connected device, which means EVERYTHING. 

The rest of the post provides recommendations on how legal counsel should prepare

 

Mastering the Language of Change Management. When "Forget You" Really Means,,,

Change is hard. It's a pain in the a$$. People get agitated. Misunderstandings happen.

So it's important to develop language that helps translate different attitudes. Here's a great primer via Julie Montgomery's "Alledgely" blog.  Enjoy.

Is Your Private Cloud Defensive or Responsive? < A Bit of Both

Interesting artcicle on CIO.com by James Staten of Forrester about whether the rush to build private clouds is defensive or responsive. By this, they mean, are IT organizations talking private cloud because they fear their users are going around them, using public cloud services?

Or are they are truly being responsive to the business's need for agility and speed? As James says, "the promise of instant access to a technology service at a fraction of the cost of traditional IT deployments means faster time-to-market and higher productivity for the business."

My take so far is that it's a bit of both. I've met IT organizations that have essentially been fired by their users and gone with public clouds. So they have developed their own private cloud to bring their customers back. It worked.

Here's a couple of interesting quotes that resonate with my experience: standardization, automation and self-service are key.

2. Standardize and automate the virtual environment. Without aggressively pursuing these steps, the bottom line is private cloud desires simply won't be met. It's time to find out whos holding back this effort and why. We've found that virtual environment administrators are often trying to protect their jobs and consequently don't share their knowledge. These workers need to be shown a path of career advancement as they move to a higher value role in private cloud operations. For example, they can improve the use of the virtual environment and managing the pool, not the individual VMs.

3. Realize a self-service portal doesn't mean loss of control. There should be an approval workflow between the request and the deployment. But, once the approval has been received, the deployment should just happen if capacity is available. This may not provide the 15 minute timelines that developers are accustomed to with public clouds solutions, but it greatly improves the experience with I&O.

And this is relevant to service catalog practitioners because "standardization" here means standard offerings in a catalog, described with sufficient clarity for a user to understand, configure and order via self-service, that can then be automatically translated into rigorous specifications to drive automation.

That's the goal - and it's not any harder or easier than working on a static catalog.

Reading: Cloud Computing Will Enable ‘IT as Business’

Recommended post on GigaOM by my colleague Michael Liebow.The point is that cloud computing is not a technology, but rather a new operating model.

To achieve immediate results from private cloud, IT organizations must implement self-service, orchestration, automation and lifecycle management on top of a virtualized infrastructure. In other words, enterprise IT needs a business operating layer.

Amazon has set the bar for cloud computing – and enterprise IT, or really any service provider, needs to offer the same experience of self-service on-demand provisioning from a catalog of standardized services, perhaps with tiered options at different price points and visibility into users’ consumption of IT resources.

While most enterprises are using private cloud for application development, testing and QA environments, they’re also increasingly extending their use to production workloads and moving beyond infrastructure to applications. And while application-development teams are using public cloud and IT operations teams are investing in private cloud, the future is likely a hybrid cloud mix of both internal private cloud and external public cloud options.

via gigaom.com

Service Catalogue Resource: This One Is a Good Primer for ITSM/ITIL Folk

I recommend "Demonstrating Value from IT Using Service Catalogues & SLAs" (PDF) by Barclay Rae as a good primer.

He covers SLA's, key service catalog elements and for those looking for categories and hierarchies, a nice comprehensive and visual set for IT services, Facilities and HR.

It's also quite dismissive of bad SLA's and quite funny about it. A small sample:

• This SLA will be filed for reference and stored in the private folder D://unused/garbage, marked ‘Do not read’. In the event of it being read it will become invalid.
• IT will respond in a timely manner to high-priority business incidents, if they
  are asked very nicely indeed, and also made to feel very special and
  important.
• IT will respond in a timely manner to high-priority business incidents, if they
  are asked very nicely indeed, and also made to feel very special and
  important.
• IT will respond in a timely manner to high-priority business incidents, if they are asked very nicely indeed, and also made to feel very special and important.

Other documents are here.

 

Selling Your Project To Senior Management? A Tip from Start Up Land.

Those of us who live in Silicon Valley and are part in the technology industry participate in some un-common practices. One of them is the "StartUp pitch"--which consists of condensing the whole story of your new company, idea, value and call to action to a potential investor in about the time it takes to ride an elevator.

This is actually pretty tough. Once I spent a 20 hour weekend getting my pitch for newScale re-writtent after several rejections. And I had worked on the prior pitch for months before. If you are passionate enough to try to start a company, and have a vision, you become an endless fountain of knowledge about a topic.  Which is good to run the company, but bad to communicate with non-experts.

But selling your project, your idea has similarity to selling your start up idea to an investor. So I thought this deck below would be useful for those trying to convince senior management to fund your service catalog project. By the way, this deck is created by KickLabs, an incubator that listens to tons of pitches daily.

Lean Deck Template

View more presentations from Tristan Kromer.

Are People Really Delivering Private Clouds with a Self-Service Catalog? YES. Embrace the Special Agent in You

The future arrives with a bang. First it's coming, coming, coming, then it's past and we are behind.

This week I've been talking or been in conversations where some very good news were shared.

1) A large government agency went live with their private cloud using newScale.

2) A large manufacturer told us they have close 100,000 people ordering services from their newScale catalog and they will expand it.

3) I'm requested to urgently fly out to finalize a project w/ a company that needs to go live with their cloud by February and could I be there hmm... tomorrow? (No, but I'll be there next week).

4) Meeting w/ the head for cloud of a large financial services firm (and existing customer) today to talk about their strategy plans. What's amazing is that there was no "Cloud" position a year ago. 

So there's a lot of activity, build out. We will exit 2011 with an altered landscape. 

Which brings me to this post from another a customer who is building a cloud. This is a very useful post on the personal journey of adopting a cloud operating model. This is change and that means it's alwasy fearful.  But let's listen to him....

If enterprise IT is truly going to benefit from the today’s embryonic but tomorrow’s immense value proposition of all forms of cloud, then I believe we are going to need an army of change agents, at many levels of a change-able organization to influence and drive toward the desired result.

I am under no illusion that in the coming months (or years) that automation, in the guise of the much heralded public and private cloud services, will render large parts of my current role and responsibility defunct. I am under no illusion that futile attempts to keep hold of areas of scope, sets of repeatable tasks or, for that matter, the knowledge I’ve collected over the years will render me irreplaceable.

Will I shed tears ? Yes. But they will be tears of joy.

As a not-so-Smart Guy who comes from a very deep technical infrastructure background, I already see the assembly line robots beating a path to my door in the shape of orchestrators and directors….I welcome them with open arms.

via blog.theloosecouple.com

I take three valuable insights from the post:

1. The need to be the agent of change, rather at the effect of change.
2. The need for a change-able organization.  Who hasn't hit the wall sometimes. If it happens enough times, maybe it's time to look for the door. 
3. The certainty while whole parts of IT will disappear (I agree), whole new challenges will arise that require new roles, know-how, etc.

But this requires we embrace change early, lead it, learn the good and the bad. Because cloud is happening.

Cote on Morlocks

Good post on the challenge to operations from devops. Basic premise: new agile development methods require agile operation methods.  No point in delivering code continuously if Change Management takes weeks.

It's not a rant, rather it's a "education" for the developer on how to talk to IT ops. The same applies in reverse.

Pragmatic Cloud Computing, or, Dealing with Morlocks, or, Agile Infrastructure

View more presentations from Michael Coté.

Self-service is the New Black. See This Year's Fashion at Our Upcoming Catwalk / Webinar with newScale

My product managers will be sharing the latest, fashion-forward, must have self-service portal of the season.

Self-service is the new black. The consumer has won and they want it now, now, now. So we are introducing our next generation cloud self-service portal that enables IT to deliver a real consumer experience across all types of cloud services (as well as internal services).

I'm using fashion as an analogy because self-service needs to be kept fresh and exciting. What worked two years ago, doesn't work today. It's not just about technology; it's about emotion, usability.

So join our catwalk / webinar. Info below.

A Self-Service Portal for Today’s IT Consumers

Today’s enterprise IT users are savvy consumers. They’ve come to expect their technology to be simple, on-demand, and personalized. It’s the impact of IT consumerization.

Imagine if you could provide these users with a self-service IT portal as easy-to-use as iGoogle. With the new Service Portal from newScale, now you can! Join this webinar for a sneak peek.

Topic: NEW Service Portal

Date: Wednesday, December 15, 2010

Time: 9:00 am PT / 12:00 pm ET / 5:00 pm UK

Click here to convert the Webinar time to your local time zone

Duration: 1 hour

The newScale Service Portal is an exciting new product with innovative self-service functionality that allows you to:

• Offer branded, personalized IT portals for users
• Deliver “single pane of glass” dashboard views
• Provide configurable content, with drag & drop usability
• Improve visibility and control for IT managers

Attend this webinar and learn how you can provide an iGoogle experience for your IT consumers with a self-service portal.

via www.newscale.com

Service Catalog for Storage. A Building Block for Service Level Management and Cloud. #EMC #NetApp

I ran into this cool article on creating a storage service catalog. Storage is one of the holy trinity of infrastructure management along with compute and network (security is under network). Storage is expensive and can be dangerous if you don't retain, secure or delete stuff according to business policie.

When people ask for cloud services or fear cloud services, it's storage management that is the main bugaboo.  One of my customers has 100 year retention requirements for some of their data -- so yeah big deal.

So i'm often asked what should be in a storage catalog; well this is is a good example.And I like it because this can be a very useful component for ITSM service level management and cloud computing.

Read on....

A SNIA presentation about Tiered Services and Classification (PDF) provides a good framework for administrators to create their own storage service catalog. The relevant slide from the 2007 presentation is shown in Figure A.

Figure A

Click the image to enlarge.

This tool can be a great way to give specific quantification for your delivered storage services. While Tier 1 storage to one organization may not be the same to another, the metrics in the Excel document that I prepare can allow you to quantify how the various tiers will perform based on this SNIA resource. Further, you can even add a Tier 0 category if you wish.

These storage service levels are your low-level component storage services which will serve as components for a service request for higher level "composite" services, i.e. bundles.

You'd build on top of these components bundles such as an application. And we wouldn't ask the customer necessarily questions about throughput, but we may ask the customer if any regulations apply to the app which then would automatically select the right retention and security policies.

The example usese four tiers, but there can be more or less. And thet automated service catalog can drive small variations in service levels through automation without generating unmanageable complexity. 

By the way, this example also illustrates the value of automation. With newScale's service catalog wizards, we can drive the customers through english questions that select the proper tier, capacity, back up, etc. But because the Tiers are defined in the automation tools for EMC or NetApp, the provisioning can happen automatically.  And the policies can be embedded in their resource managers so, for example, data accessability policies are executed. 

A shout out to Rick Vanover of Alliance Data for the useful info.

Recommended Reading: How Private Cloud Shakes Up Traditional IT Roles

"How Private Cloud Shakes Up Traditional IT Roles"  is a very thoughtful and pragmatic article by the CIO of EMC on how he sees the adoption of cloud changing his organization and what he is doing to support his people through the transition.

For example, one change that the converged, virtualized infrastructure challenges is the traditional silos.  Now it's possible to have one person configure servers, storage and network; but this calls for a re-skilling where one may have a Major in Network and minors in Compute and Storage.   And it requires a set of ITSM processes that are flexible and almost real-time to enable this new operating model.

The part that affects you, as a service catalog professional is how your role becomes super important in this transition.  This quote is the meat.

Third, with the adoption of the private cloud, IT must be one with the business. In my years as an IT professional, I've seen waves of technology come and go. But, the private cloud alters the playing field by tightly aligning with the business and its dynamic technology needs.

If we can deliver what the business wants as a catalog of service offerings, then life changes. This is not just a change in jargon and roles, but in the overall conversation and approach you have with the business to understand their needs; how the new service catalog built on the private cloud meets these needs; and how the private cloud will deliver a better cost model while improving agility and value. This will be a core competency for IT professionals riding the latest wave of innovation in IT.

Wow. I couldn't say it better myself. The skills needed in that last paragraph range from: service design, catalog management, customer relationship management, financial management and vendor management. That is where the future IT careers are going for the non-technical people in IT. What do you think?

Culture, Process and People Drive the Cloud Operating Model: Reading

Wow. Reading Dustin's Blog on "Surveying cloud and virtualization in application middleware" is a nice and pleasant surprise.  He surveys some of the challenges facing the enterprise adoption of virtualization and cloud computing.

The post doesn't center on technology but rather on that intersection of service management, the cloud operating model and technology.  And this maps very well to the topics people working on service catalog implementation.

I recommend reading the whole blog post where he touches on the cultural, business and process model, and automation challenges.  As I've been blogging lately, if you drive towards a cloud operating model based on self-service and automation, the HOW you go about your service management improvement procesess changes, the order in which you do things, changes, and the specificity of requirements changes. 

I particularly like this quote:

Workflow governance challenges for the cloud: Users are attempting to reconcile traditional workflow governance techniques with the new provisioning model put forth by the cloud.

While the technology allows them to provision environments with unprecedented speed and potentially move toward a self-service model, their workflow governance processes just do not work like this. If I can spin up an environment in 5 minutes from the time I decide to deploy until the time it is ready, that is great.

However, if I have to go through a day long ticket request process to start that deployment, that is not so good. This is the challenge facing many organizations, and providers need to ensure they can account for some type of integrated workflow governance around provisioning.

Whether it is directly in the system, or delivered via integration hooks, providers cannot ignore this capability.

Bingo! But there's more... Someone has to go to the architects about what can be standardized so they are out of the way of every request. And someone has to go to talk to the customer to understand what they need, what they'd be willing to live with and then design the service offerings. Once you have that, then it's back to the operations team to build those VM's and have the self-service portal with the proper integration

The goal is not to have every configuration or option. The goal is to have a 2 or 3 options, with some common configuration options. 

I'll leave you with another quote. This is about culture and how there's a whole lot of attitude change needed. 

Cultural challenges for the cloud: This is a topic I often bring up, but when I talk with users struggling with employing virtualization, automation, or cloud techniques, nine times out of ten it is not technical. Rather, the real problem is confronting culture within the organization. This could be learning how to work across organizational silos as they move towards self-service stack provisioning processes, or it could be convincing developers that the machine hidden under their desk is actually of greater use when put into a shared pool of resource.

I Can Mathematically Prove You Are Attractive. The Self-Service User Experience of Cloud Computing.

Continuing with my guest post series, here is part two from my talented, witty and charming colleague, Carol Dirig (@caroldirig), who is in charge of our self-service portal.

We were at Vmworld in San Francisco this week, where newScale won the gold prize for best software for private cloud. The show featured lots of companies talking about self-service catalogs -- more than at any ITSMf show.

But some things were a bit... odd. Carol can explain there rest:   

Down on the Corner

I’m with 17,000 other IT professionals at VMworld. At this particular moment I’m sitting outside Moscone Center, having just heaved myself across 4th Street and Howard with a mass of attendees. Over 95% of the attendees here are men, a fact that did not escape the conference vendors and organizers.

There are two young angels standing on the corner, dressed in tight white shorts and skinny halter-tops attached to large fluffy wings. They hand out coupons. One shouts, “30% off your VMwares!!” The other quietly hands coupons to slack-jawed men, telling them to take their coupon inside for “VMwares discounts”.

VMwares. Seriously.

Anyway, it’s taking everything in my power not to write (more) about THAT and the hordes of other young women who were hired to lure men into various vendor booths. But I do want to discuss something related to this – that same primal instinct of attraction and its applicability to application design. In my last post I talked about dopamine – the neurotransmitter responsible for our feelings of pleasure. When you find something attractive, whether it’s booth babes or a gorgeous portal interface, you’re brain (and body) is experiencing a chemical surge. In aesthetics, dopamine is triggered by some pretty subtle visuals, mostly related to proportion, and then color. 

First of all, why should you care?

I know IT teams who say they don’t really get the point of usability, let alone aesthetics for an application they feel their users HAVE to use. They forget that users always have some kind of choice, even if that choice is how they represent you and your IT team. They hold the power to your credibility. Besides, wouldn’t you just LIKE to have satisfied users? You - who gawked at the angels on 4th and Howard –don’t you want to share a little angel dust with your users? And if you're a service provider, well, it goes without saying you need to pay attention to your dress.

Cosmetics & You

Application aesthetics are more than throwing a few images on a page and changing your fonts. And let me tell you, not everyone has a good sense of aesthetic. You might be one of them. If you enjoy, say,

Comic Sans, 20 points, in lime green,

chances are you think fine art is Uncle Hank’s mounted walleye.

Everyone’s tastes are different, and there are fads. But there is a concept of majority opinion in art and beauty. When we design business applications, we’re looking for a timeless, clean, uncomplicated look. Unfortunately it’s too easy to make a “clean and uncomplicated” application feel like watching 10 years of uninterrupted PBS pledge drives.

So we need an interface that’s interesting, clean, and alluring. Luckily, you can apply cosmetic guidelines to figure that out.

I can mathematically prove that you are attractive

There’s science behind interface cosmetics. For starters, there’s the famous Golden Ratio, or phi φ. Also known as the Divine Proportion, it provides a ratio of length to width of approximately 1.618, proven over centuries to be the most visually appealing. From David to the iPhone, to the very structure of your hand, Angelina Jolie’s face, and the booth babes at VMworld….the Golden Ratio is at work.

You can apply this concept to your Service Catalog landing page, for example, or to service forms. In its simplest practice, apply graphics to your application that are positioned and sized using Golden Ratio proportions to create a very subtle, alluring, visual aesthetic.  (You can even get a Golden Ratio plug-in for Photoshop, by the way, to create or crop images into golden ratio-friendly dimensions.)

Here’s a example from newScale’s RequestCenter. This example is a comparison shopping aid, distinguishing two cloud offerings. I simply proportioned the visuals into golden rectangles.

 

There are other practical cosmetic guidelines you can follow when designing your Service Catalog, like these:

 

What can you do now?

Start by looking at websites you like, regardless of their function. I usually turn to Apple, so I‘ll do that here, and then leave you with Service Catalog examples using the heuristic and cosmetic concepts mentioned in this post.  Then take a look at your application and visualize how you could apply golden ration proportions, combined with tension, balance, flow, depth, and unity.

 

Here are more Service Catalog examples, using newScale RequestCenter. I don’t have permission to use customer names, so I’ve censored them, like naughty bits in a racy magazine. Some are better than others, so consider what you like or dislike about each one. Click a thumbnail to enlarge:

   

 

Cherries, Heuristics & Dopamine: Creating a da Vinci-style Service Catalog

Continuing with my guest post series, here is a two part series from my talented, witty and charming colleague, Carol Dirig (@caroldirig), who is in charge of our self-service portal. In all the rush to self-service in the cloud, I see is that usability and aesthetics got left behind.

In our 10 years of experience deploying self-service catalogs, we know that means adoption of 2% vs. 80%, low transaction rates and zero improvement in process efficiency. In other words, the store is out of business.  Take it away.

Creating a da Vinci-style Service Catalog

I’m setting aside the ubiquitous cloud conversation for a second to focus on cherries. Like, the kind you put on your Sundae. (I KNOW Rodrigo’s penchant for food metaphors, so I’m giving him a blog Sundae!)

Do you remember how you felt when you first held your shiny new iPad in your hands? Or slid into the leather seats of your first ever new car? That emotion is the result of a dopamine surge, a neurotransmitter responsible for (among other things), our sensations of reward and pleasure.

 

It’s also the science behind why we like certain art and music, and yup, web sites and applications.

 

Dopamine Surge

 

Six months ago I was asked to revamp the interface of an IT Service Catalog for a large, globally recognized company. I won’t mention names, but they tend to sell things like frozen entrees and cereal. You can join their club and get discounts!

Anyway, surveys showed that users were unhappy with their experience trying to “interface” through their Service Catalog. The unhappiness created a lot of misgivings for IT, causing their reputation to take a hit.

The user interface was just one part of the equation, but an important one (other parts were workflow and process related). As we hear all the time, most IT people aren’t trained in usability or have aesthetic sensibilities. And that’s ok, right? So I was asked to vavavoom the cosmetics of their Service Catalog and create a more usable experience. Essentially they gave me a focus group and told me to surge their dopamine.

 

Beauty & the Scientist

When we talk about dopamine and user interfaces, there are at least two equally important facets to consider: (1) The usability that creates a consistently wondrous experience, and (2) the cosmetics that cause someone to go “wow!”. 1 is like the sundae and 2 is the cherry on top. Together they make a memorably delicious experience. This post focuses on part 1 – usability.

Usability. Luckily, usability has a science behind it. One approach is to apply web usability heuristics. These heuristics apply to Service Catalogs, cloud portals, or any interface you stick in front of users. There are ten basic heuristics, which you can read about all over the web and Human Factors textbooks, including here. But to summarize for you busy folks, those heuristics are:

What you can do right now?

A very simple thing you can do right now is run your application, portal, or Service Catalog through this heuristic checklist. How well does it meet the heuristic guideline? What required changes fall into your sphere of control?

 

Let’s use newScale RequestCenter as an example (since I work on it!). If you are a RequestCenter customer, you may not realize how much control you have over the user experience. Just a few examples:

 

Here’s a visual of a RequestCenter implementation from the customer mentioned above (their name has been censored for both of our protection), showing how we applied various heuristics to their RequestCenter home page.

 

Here's the same image for a better view, without the callouts:

Part 2 of this post series will focus on the aesthetic athletics of your Service Catalog, and the science behind beauty.

 

Guest Post: Getting the Most out of Cloud Computing with the Self-service Interface

Summertime and the living is easy over here at servicecatalogs.com. I'm inaugurating a new feature for this blog: guests posts. New voices help keep the topic fresh.

Today's blog post is by guest blogger Paul Burns. His company, Neovise, is an IT industry analyst firm covering cloud computing and IT management. He has written several reports on self-service and I think you will enjoy his work.  His regular blog is found here: http://www.neovise.com/blog

Getting the Most out of Cloud Computing with the Self-service Interface

The role of self-service in cloud computing has become increasingly clear over the last year or two. It didn’t hurt, for instance, that the Draft Working Definition of Cloud Computing from the National Institute of Standards and Technology (NIST) specified “on-demand self-service” as one of the essential characteristics of cloud computing. Yet, more importantly, members of IT organizations that have taken the time to consider the benefits of cloud computing seem to have internalized the idea that cloud services provide greater control and agility.

For many, the unique economics of cloud computing will remain critical. However, more IT leaders and staffers are realizing that changing the flexibility, velocity and responsiveness equations in IT can be just as important or even more important. When it comes to getting the most out of cloud computing, the real leaders look at much more than potential cost savings. If you want to be a leader in cloud computing adoption – or more accurately a leader in deriving the greatest benefits from cloud computing – you need to go after control and agility as well.

Not surprisingly, the self-service interface has the potential to be a major source of both control and agility. At the same time, there are many types of cloud environments with equally many different approaches to self-service – some good, some not so much. So an interesting question becomes, “How can IT organizations be sure to get the good and avoid the bad?”

Let’s keep this simple and focus on cloud infrastructure services (a.k.a. infrastructure as a service or IaaS). By understanding some of the ways you may encounter self-service, you will be better prepared.

1. Interacting with public cloud services

a. Public cloud providers offer self-service portals that enable customers to purchase and manage services. Be sure to evaluate self-service capabilities as closely as you would cost and features of the cloud service. Some cloud service providers have not spent enough energy in this critical area. Most have not realized they can benefit from using commercially available self-service solutions. [Hint to public cloud providers: you need to think about how top notch self-service can become a key differentiator for your offerings]

b. IT organizations today utilize self-service interfaces for all kinds of internally provided services. This includes IT services (access to a new application, purchasing a laptop, etc.) as well as non-IT services (requesting a service from facilities, HR etc.). Leading organizations extend their self-service capabilities to external or 3rd party requests as well. Some commercial self-service solutions make this easy or may even provide built-in capabilities for interacting with public clouds. [Hint to IT organizations: there are other reasons to use this approach too, even if you like the self-service interface from your provider; think governance, policy driven control, automated approvals, etc.]

2. Building an internal cloud

Some IT organizations are also building their own internal clouds (often simply called private clouds, even though private clouds can also be offered by 3rd parties; confusing, I know!). If you are building your own internal cloud, do not underestimate what it would take to build an appropriate self-service interface. Even customers that purchase “cloud enabling software” or “cloud controller software” often find that the included self-service capabilities leave something to be desired. Whether you are building an internal cloud from just above the virtualization layer or leveraging some sort of cloud enabling software, keep in mind that commercial self-service solutions can save a lot of time and money as well as produce a better result.

If you want to get the most out of cloud computing, you need to incorporate the additional levels of control and agility afforded by a well chosen self-service interface. Keep each of the scenarios outlined above in mind so that you can have the greatest level of influence over your cloud computing experience.

The SMLXL Standard, Or What T-Shirts Have Taught the Cloud. Reflection on Cloud Standards

Do we need Cloud API Standards? asks Sinclair Schuller in new blog post.

My answer is, like Sinclair, over time yes, but immediately, no. Like him, I see lots of innovation going on and premature standardization will either stifle that innovation or be so over-complicated that no one will use it.

Sinclar makes a good point, which is we already have early de facto standards, like Amazon EC2. We work with Eucalyptus, for example, because newScale already used the Amazon EC2 API.

Given Amazon’s API penetration, a market “gold standard” has been created just by shear adoption, and I think people will naturally flock to a proper abstraction like Eucalyptus because of sheer necessity to ensure compatibility with the gold standard while preserving the ability to experiment with new solutions.

But there are other areas for which standards would be useful to have, like service definition standards.  In fact, I think the most useful standard to emerge from Amazon is NOT only the API, but rather the service definition that introduced t-shirt sizes to IT. I'm talking about Amazon's Small, Medium, Large, Extra Large compute instances.

With SMLXL, Amazon brought merchandising and standardization to the data center.  I've noticed that every cloud provider is forced to speak in these terms even as they try to differentiate, because SMLXL is the baseline. 

Yes,SMLXL are not a perfect fit for everyone (pun not intended)in clothing but they allow for mass production of clothes at prices that are a fraction of custom tailored clothes. Because once we have standard "product" definitions, it's possible to apply automation to the factory and supply chain.

The same thing happens in the cloud. Once we have standard service offerings, it's possible to industrialize the data center, the supply chain and management functions, like capacity.  Think how much easier capacity management if compute requests are one of 4 types, all fungible and all demand driven by self-service.

Yet as simple as SMLXL is, there is room for variability. 

Amazon AWS offers a Small VM which can be Linux or Windows, it can included SQL or not, you can select monitoring or not, you can assign it an IP or not and finally, you can select an image that loads an application or just simple opt for the OS.  On the other hand, Go Grid offers a load balancer, which Amazon didn't offer.

And Terremark's vCloud Express offers CPU, Memory and Storage capacity in bulk which is independent of the number of instances/VM's a customer chooses to run. So you can specify your VM's RAM and you can change the RAM as you wish. Amazon does not do that.

The point is that there's a tremendous variation in the offerings.  From an API perspective, it's possible to abstract like jclouds or libcloud do so all clouds look roughly the same.

But for newScale, and our customers, we have to go a lot deeper.

We need to present the offering in English, explain all the options, allow for comparison and selection.  Then we need to be able to configure the request (for example, do you select monitoring or not). It's the configuration of the request against both the values required / allowed by the cloud vendor API and internal policies and rules of the company it's where things get tricky and valuable.

So as much as we need an API, we need to have a standard format for exchanging catalog information. This is what we are trying to do with SPACL,provide a simple XSD format to express the service offering. And yes you can express SMLXL in a SPACL document.

There's a precedent for this type of work.

During the B2B e-commerce wave, a lot of attention was placed on transaction standards. Yet all of them ended up needing something like Ariba's Catalog Interchange Format, because before a transaction could be made, the customer needed to know the product name, sku, description and price. We are in a similar place today with cloud.

Over time SMLXL is not sufficient. We will need the equivalent of colors and sizes as well, but for now, just making SMLXL type packages would be a good step.

Oh and here is the movie version of this post

Fear the Fat Finger. An Obstacle to Cloud Adoption?

Working with data center and cloud automation folk, I've noticed there's a deep reluctance to embrace self-service as part their transformation efforts. Drilling down into the reasons for this fear, I've come up with the concept of "Fear of the Fat Finger" Syndrome.

Here's are some of the symptoms:

1. Fear that someone will try to start 1,000 servers and kill the data center
2. Show them and they will come symptoms.  The belief that if you show what's available, it will be consumed and all your resources wasted. So better to not tell them what is offered and hoard resources
3. Fear the user will order the wrong thing and waste resources and still complain
4. Fear the user will configure it wrong and mess up the application or network or server farm, etc.
5. Complete and UTTER certainty that every configuration is unique and there's no way that you can put standards in place. This is a funny fear, because it's coupled by the certainty the users will not accept standards.
6. Architect-arrogance-nose-bleed.  The certainty of the data center architect that unless they have oversight over every configuration and the right reviews are done, nothing should be added to the data center.
7. Bloody-red-shirt-of-security syndrome. You can always stop some new behavior by uttering the enchantment word "SECURITY!!" real loud while waving a blood red shirt with an anecdote of the time AOL/Google/Twitter/Facebook etc was hacked.
8. Fear that they don't have a process ready. This one is the fear that the user will see how hap-hazard or non-existent the record keeping and application of policy is in the data center

I know there are other symptoms and fears.  Feel free to add more to my emergent fat-finger syndrome. Let's see if by calling them out we can show they are smaller and more manageable than they seem at first glace.

To this fear, I have two observations:

First, at newScale, we've been doing this for a 9 years now and we lived through this on the workplace and desktop side. There were no standard desktops, there were no standard services, and there was a fear if they showed what IT provided, people would, errr... ask for it. 

That's been gone for while; self-service and catalogs are pretty mainstream now. Now it's the data center's turn.

Two, the service catalog is about enabling safe and sane self-service. This is why we place so much emphasis on governance, role-based-access control, policy enactment and lifecycle management as part of our platform.  Unlike regular e-commerce, it's about making it easy, yet managed and controlled for the enterprise. We've learned to balance both sides very well over the last 9 years.

This means no one can order 1000 servers, because we can set quotas. And regular employees don't see servers to order, only QA and App Dev. It means, the right questions are asked which then lead to the right configuration for quality of service and security.

The proper authorization steps happen, exceptions are managed. And finally, the catalog manages the workflow processes to ensure the right tasks and checklists get carried out.

So it's like deja vu all over again! Welcome to 2001 my data center friends!  I can tell you how the story ends - in the cloud.

Stay cloudy my friends.

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.

Reading: "100 IT-Business Alignment Questions You Need to Ask"

For people focused on creating a business service catalog, here's a useful exercise: a set of questions that will help you understand the business and how they think about what they do. These questions were posted by Patty Azzarello at CIOUpdate.com to help find the mythical IT-Business alignment.

They work just as well for defining business services.

If you engage your business counterparts in a discussion about their area, what should you talk about? Here I've assembled a list of those questions to learn about your business and engage your peers in discussions about their part of the business.

Money

1. How does your company make money?

2. What are your sources of revenue? How much does each provide?

3. What are your sources of profit? How much does each provide?

4. What things are your company’s fixed expenses?

5. What things are your company’s variable expenses?

..and so forth

I'm not suggesting you have to fill out a 100 question document, but rather to use these questions to find concerns, metrics, key performance indicators, strategic challenges your business counter part lives in.

Found via @HankMarquis

User Needs vs. Business Needs? Who Ought to Win? Why... Both! #ITIL

This article in www.cioupdate.com makes some good points about the reponsibility of the customer in the cost and quality of IT services.

Abdication of responsibility by customers and assumption of that responsibility by IT does not and cannot solve the problem. In fact, it is precisely the cause of the “IT problem” so many have right now. We in IT cannot mandate the relationship between customer and user, nor can we direct customers to do the job they ought to do. However, we might be able to facilitate it through measuring service quality requirements from a human (e.g., user) point of view. We could then provide this information to the customer to help with their decision-making regarding IT funding. If we in IT could move off technical operational metrics and develop true quality of experience measurements, customers could understand the options and make more informed decisions.

I'm not sure I completely agree with the premise that to satisfy the business customer, we must ignore user satisfaction.  newScale wouldn't be in business if we did that.   At some point user dissatisfaction does boil over into a revolt. We saw it with PC's and we are seeing it now with cloud computing, as App Dev groups go out on their own and by pass IT. I just saw this last week. It ain't theoretical, it's real and some people lost their jobs.

In a marriage, whose opinion should count the most? The economic provider or the spouse?  Yeah... That's what I thought. It needs to be both. Any one day or moment, you can compromise or give up something. But everyday? Nope. Recipe for divorce...

Except that in technology, new vendors appear to ease that tension. So the result is not a divorce, but a firing of the service provider who caused the tension... Same in business.  Users and economic buyers will soon agree that their relationship is fine, but IT sucks.  Marriage saved.

So yeah. It's both.  Nonetheless, I recommend reading the article, because Hank is very thought provoking.

Don't Be Such an asdfasdf! Reflections on ITSM Community Building, I'm a Real Person.

At the Pink Elephant conference I met many people who use the community and derive value which was gratifying. Some even bought me a drink - which was awesome. So I thought I'd reflect a bit this friday on newScale's service catalog community on LinkedIn, which is now four years. 

It has become the gold standard for of ideas and conversations about service catalogs.  I've been very happy to watch it become a source of support, learning and professional help so many thousands of people.

Recently Forrester Research called out newScale as the leader in using social media in ITSM, which is gratifying (Thanks Peter!).  I like to think that at newScale we don't use social media, rather we let social media use us. Which can bit hairy sometimes!

A surprising learning has been that identity is more important than anonymity and that our discussions are enriched by knowing with whom we are conversing, their background and being able to link to other aspects of their social life like twitter and blogs. So when Rob comments on the group, you can link back to his blog, same for Chris (Mr. ServiceSphere) and many others. (And it was great to catch up with both of you!)

I'm convinced this is why the conversations are so high quality, respectful and on point. 

The other part is a bit more unpleasant: a community needs someone (me) to act as gatekeeper, bouncer and janitor so the community doesn't descend into crap.

The threshold to get in is pretty low:  be human (you'd be shocked how many fail the test), work in IT (even tangentially), not be marketing hack for a competing vendor, but consultants / experts from competing vendors are welcome). 

To be blunt, I decline about 5% of applicants; the majority because their profile says "asdfasdf" or they are obviously junior marketing hacks on suicide spam mission.  Or their background is irrelevant to the topic (I'm thinking of you Chicago account manager for a paper catalog printer and your great deals).

There's no other way to keep the conversation focused and on-topic. 

The other lesson is that you have to be a real person.  At newScale, you can access me here, on linkedin, and twitter.  You can access our CEO, Scott Hammond, and our VP of Marketing, Jason Schroedl, and Andrew, our VP of Engineering.

Also our product managers Carol Dirig and Jamie McQuarrie who have great blogs of their own.

So I invite you to join this community.  Just remember, don't be an asdfasdf!

Is ITSM / ITIL Keeping Up with the State of the Art in Cloud Computing? Doubts Emerge. PART 2

I wrote this post, Is ITSM / ITIL Keeping Up with the State of the Art in Cloud Computing? Doubts Emerge, a while ago

So does this mean that ITSM process are not needed?  Actually, it does mean that. To be specific: some processes will go away; some change management will not be needed. Also the manual ways we go about doing ITSM will need to go away.

Here's my latest from-the-field-notes from talking with a customer who is planning to deliver a private  cloud and the questions that surface.

First, they need to figure out what will be the basic services they will offer.

Should they start with Amazon type instance sizes? If so, how do they differentiate? This means they are preparing their technical services catalog and the requests that will drive it.

So now it's not really about documenting processes. It's about being competitive in the market place.

And that means they need create a group that will define, design, configure, and deliver the cloud offerings and other professional service offering within newScale's suite.

This team has to think from the point of view of the market and then work with the technical teams to define, design, configure, and deliver the requestable component services. These will be actionable in the newScale catalog to enable the operational day-to-day delivery of the cloud services.

The outcome? The customer can go to their own self-service portal, see specific configurations, configure their request, order and be provisioned in minutes. 

All the catalog work is about making it happen, then tracking consumption. Other things that we need to provide are account management, customer on-boarding, subscription, life-cycle management, and of course billing.  In the back office, it will run some manual process, but many more automated provisioning processes.

But all begins with the first question: What are the offerings? What's included? How is it priced?

In all this discussion, ITIL never came up.

We spoke of the need of a product manager to continually work with customers and service owners to keep their services competitive.  The concept of a product manager is not in ITIL. To be fair, there are ton of role definitions in the books from which you could maybe figure out a job description...

But if my business depended on getting it right? 'd go here and use the Pragmatic Marketing Framework. 

I've written about this before in the Product Manager Role and also here, and here.

Hence my doubts.  In the thick of it, I am forced to rely more on traditional product management skills than ITSM skills. Competition is wonderfully focusing.

A Great Example of Why a Service Catalog Needs to Be Actionable #ITIL

If you are building a service catalog for financial transparency, I recommend reading this fascinating blog post from Green Monk's blog: PG&E smart meter communication failure lessons for the rest of us

It seems that PG&E implemented smart meters to allow the customers to dial back consumption during peak times, and to get a sense of their own patterns of consumption. It failed.  Here's why.

There are a number of problems here all to do with transparency and communication. If, as PG&E say, this is because of customers not shifting demand to off-peak times when rates are lower, then it follows that PG&E have either failed to communicate the value of shifting demand or the time when rates are lower.

One of the advantages of a smart grid is that the two way flow of information will allow utilities to alert customers to real-time electricity pricing via an in-home display. PG&E have not rolled out in-home displays with their smart meters, presumably for cost reasons.

So it fails because the smart meters don't provide KNOBS or real-time display of consumption in terms the customer understands: MONEY!

So when the bills came due....customer say:

yeah I’m actually pretty pissed, PG&E installed a so called “smart meter” and my utility bill increased $300.

I’m waited for PG&E to put up the daily usage numbers, I won’t get those until next month for some unexplained reason

This is a case of trying to move to variable, consumption based pricing (a good thing), but without the adequate tools or models to allow the customer to determine their optimal mix of cost vs. consumption.

The customer is supposed to turn down the AC on a very hot day to save money, but the report of usage come a month later.

This is relevant to the service catalog because it's core the ACTIONABLE part of the service catalog. Listing the services on a document or putting prices that are not tied to consumption behaviors is useless to the customer.  The customer must have a way to understand consumption and be able to do something about it.

Like turn off the VM. Or change the phone plan. Or any customer-understandable consumption unit which can be acted upon.  

And that's what a good service catalog tool does.

"Is the ITIL make-over like putting lipstick on a pig?" No. But Should We Be Asking Pigs to Fly to the Cloud?

Steve Chambers at ViewYonder catches the same question I had when I wrote "Is ITSM / ITIL Keeping Up with the State of the Art in Cloud Computing? Doubts Emerge" I then wrote that there didn't seem to be much thinking going on about the impact of cloud computing to ITSM.

Steve's wish list is to have a more pragmatic ITIL. 

I wish ITIL was more referenceable, more pragmatic and more relevant for today’s infrastructure.  Here’s some things I’d like ITIL to cover:

1. Virtual Infrastructure – how the service and server lifecycles are transformed, and how they impact all the other ITSM processes from SLM through Finance through to Config Management.
2. Cloud Computing – the epitomy of managing IT as a service, this is a great opportunity for ITIL to provide a best practice framework.

Yes, you heard me, I’d like to see a library of best practice reference frameworks for IT Infrastructure. 

I don't think it's going to happen for three reasons. 

First, it's cultural. Part of the ITIL culture seems at times to be intensely anti-technology and vendor.  And the problem with that is that technological change is vendor driven.  With all the good an bad that implies, but it is a fact. As long as that attitude remains, innovation will flow like molasses, not a river. 

Second, it's structural, ITIL is owned, and parceled out in such a way that many organizations (OGC, TSO, ITSMF, training organizations) each with its own focus and motivation that is hard to bring innovation in. 

It doesn't have to be this way. For example, AIIM is a professional organization, with a a large following and a very well defined process to create international standards. So innovation is part of its daily operations. I'd love to see ITSMf model itself along those lines.

Third, it is the nature of ITIL. Which is supposed to be a "best practice framework". Best practice, by definition, means proven, tested, and ... backward looking.  Which is neither good nor bad. 

I want my surgeon to be very proven, tested and backward looking --most of the time.  But in times of rapid change, particular the junction of technology and economics we are living in 2010 that backward looking "best practice" doesn't work and can be down-right counter-productive.

I do believe the ITIL v3 update will be a good thing. I'm a software guy, so patch updates are not a bad thing.  But when we patch updates, we don't re-write the stack. We fix the minor problems.

So what's the problem with a best practice framework. For me, it's the phrase "BEST PRACTICE." It's designed to make the brain stop thinking and looking for alternatives. If you find best, why keep on searching?

If ITIL was referred to as a set of "common practices," "useful body of knowledge," "guide to where dragons be hiding," or just "useful accumulation of tidbits you really ought to know by now" then... we'd have both the value ITIL brings, and the ability to keep on innovating.

But wishes ain't reality. And someone told me long ago, "Don't aska pig to sing. It doesn't work, and it annoys the pig." 

So it's really us who need to think if we should be asking pigs to fly? Lipstick optional.

Steve. I think we are on your own.

Recommended Reading for ITSM folk: Outlook 2010 IT skills checklist

How does cloud and virtualization affect ITSM skills?

This is a topic I'll be covering at the upcoming Pink Elephant conference.  Before that, I recommend reading this Network World article by Denise Dubie. Here are a few nuggets, worth considering.

The stereotype of IT existing in the back office and not facing the business is gone. In years past, industry watchers have advised high-tech workers to better communicate with the business, but now the task is to become a critical player in the success of the business – and not only by taking direction. IT professionals will be expected to take a leadership role in 2010 and take initiative in making decisions in the best interests of the business.

We see IT become more a broker of services rather than the direct manufacturer of the service.  This means managing the service catalog becomes important.

And service level / relationship management and vendor management rise in priority as well.

Don't Like Service Standards? Go Out and Make Some of Your Own. Here's How. #ITIL #SPACL

We've gotten some good positive feedback about SPACL so far. And we'd love to get more contribution from the ITSM community.

So to help you give us feedback, I thought I'd share a little bit of how we go about thinking what needs to be in the service model.  This is a subset of what I wrote in response to a question at spacl.info/

For SPACL, we need to model a "Core set of Definitional Elements, Attributes, Data Structure and Hierarchy" in one of the three objects we have decided to tackle first; these are ServiceOffering, RequestableService and ServiceRequest.  There are other objects, such as ServiceAgreement, which we may tackle later or never. 

So for any element, like Warranty we run it through a "Core set of Definitional Elements, Attributes, Data Structure and Hierarchy" test. This is why it takes a while to make standards.  I'll explain.

First, is it core? Which is a judgment call for sure, but if Warranty not there is the ServiceOffering still valid? If it's not there, does something important break. And also the opposite, if this gets added, what compatibility and interchange between systems might get lost. What complexity might get introduced?

In the SPACL group we are guided by the history of successful standards, which teaches that the more complex the standard, the less adoption it receives. X.400 was the ultimate e-mail standard, but the winner that the internet runs on is Simple Mail Transfer Protocol (SMTP), and the X.500 model for directory was too complex so it was replaced by Lightweight Directory Access Protocol (LDAP), and so on.

So the question of core is a very important one.

Second, is the element Definitional or is it Run-Time? In other words, can this element or attribute be sent from one party to another without the party having to know about the service operations?  This one trips up more than one ITSM practitioner, yet it's super important.  This would exclude having some kind of customer approval workflow in the definition because there's no way for a provider to know the internal approval workflow of customer.

It doesn't mean that a service at company XYZ can't or shouldn't have an approval process. It simply means that a SPACL ServiceOffering cannot require the provider put an approval workflow in the definition.

Third, is this an element or an attribute? An attribute is like a field. It has a value and a data type; like "$10" is a integer of the type currency.

On the other hand price is an element of SPACL definitions and has a complex data structure at that. For example, the price of "$30 per user per month" is one that has currency time, integer, a unit of measure "per user" which has to be defined somewhere, and a periodicity that also has to be explained ie. a year has 12 months, for example.

In SPACL we know we need to define these things. The question is to what degree? Do we need to create a list of allowable units of measure for IT, such as byte, kilobyte, megabyte, gigabyte, etc? And maintain them? This is a serious endeavor and one that other e-commerce standards eventually had to. For fun, check out the UN site where the global units of measure for international e-commerce are documented.

And finally we have hierarchy. Are some elements required by other elements? For example, price often requires units; it's $5 per hot dog. $5 does not tell you enough. You need the unit of measure hot dog. Thus unit is part of price in this example.

Our goal with SPACL is to take the ambiguity and opinion about service definitions as much as possible and no more. There will always be the need to extend the definition for different industries, uses, etc. In fact SPACL allows for extensions. We see our job as first defining that core set of elements and attributes which all Services need to share.

So to now answer some of your question (I'm lenghty, ain't I). For example your third bullet is very much run-time. The decision of how to display a service is one that a customer can make different from another customer. So SPACL might include category in the definition, but would not include display rules.

Ready to make a standard?

So if you think there are elements and attributes we need to consider for SPACL, I encourage you to make your voice heard at spacl.info.  Go and make a standard you can be proud of.

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

Bending Metal, Or How Cloud Computing Will Change How We Define IT Services #Cloud #ITIL #ITSM

In my discussions with customers about how to define IT services there's always an issue of granularity. How small, how large, what level of detail should it be included.

One of my recommendations has been to borrow from service providers who do it for a living and emulate / imitate.

Recently, I've learned another angle to this approach as I've met people who specialize in helping companies negotiate outsourcing contracts.

Before an organization can outsource it needs to create a list of services (a catalog), with specific service definitions, outcomes, and expectations.  Then it needs to benchmark its services against other offerings. 

This makes sense. You need to define which services you will outsource, and then figure out how the internal IT organization stacks up: are you a lower cost provider? Are there others who do better worse?  What does it cost you to provide a 100M Outlook Inbox?  What is the ongoing price for an e-mail inbox? And what's included?

The concept is sometimes called "market-sizing" services. This means defining services in a way that they match what external providers offer.

Here's a simple thing. What does it cost an organization to provide a small Linux box with 1.7G of RAM, 160G disk. Here's the benchmark against Amazon which includes this and costs $0.085 per hour.

This means you end up with buckets:

1. Services and tasks for which there a variety of external providers, like the small Linux box
2. Services and activities for which there are no external viable providers because they are too specialized, regulation / laws don't permit outsourcing, represent core IP of the enterprise, or are just cheaper to do in-house (this is true).

This second bucket is usually problematic. It's where you find services that need to be done, like support which may not provide differentiation, or services that are unique and provide you competitive differentiation, and of course, crap/waste. Stuff that adds no value, and no one knows why it's there.

Market sizing can help you fix that.

And, it seems cloud computing is accelerating this trend.   James Urquhart, writes inCloud computing and the big rethink about this change. 

Enterprise IT will begin to bend enterprise and solutions architectures to align better with what is offered from the cloud. I may not agree with some that the cloud will stifle differentiation in software systems, but one thing is very true.

As end users select software-as-a-service applications to run core pieces of their business, meet integration and operations needs from the cloud, and generally move from systems providers to service providers, the need to reduce customization will be strong. This is both to reduce costs and strengthen system survivability in the face of constant feature changes on the underlying application system.

Which is why I think the next step in service definitions is bending metal -- meaning, bending IT infrastructure service definitions to match what cloud providers are delivering.

It's inevitable that these questions will be asked: what do you do, how well you do it and what does it cost on per unit basis.  This is at the heart of a service catalog.

Let's Stop Re-Inventing The Wheel in ITIL. It's Product Manager!

I've been meaning to comment on Rob's post about ITIL's continuing re-invention of established concepts.  In particular the role of product manager. 

People often ask me how they should organize their service catalog effort, what are the roles and what's the overhead of ongoing maintenance.  We have a whole methodology and job descriptions we use, but we took a formula that already work, which is how we develop products. This always starts with the product manager.

First, Rob's take

Anyone interested in finding the good, bad and ugly in the Service Strategy book should go invest in a proven Marketing Reference, such as Marketing Management by Kotler and compare theory with proven best practice. You need only compare the table of contents....

Just a few clues (and as an ex Product Manager trained and certified by by Pragmatic Marketing), Strategic Planning is a sub-activity of Product Marketing. Market Research and Development, Brand Management, Prospecting, and Market Segmentation are vital to success.... a product is not a service, a service is a type of product - period. Check the goods-service continuum.

When will IT folks stop reinventing and renaming things that are established by the business and other professions...

Which is absolutely true.  I've written about this before in the Product Manager Role and also here, and here.

The value of using these standard names is that there's a whole domain of practice, training, and tools that becomes instantly available to you as a practitioner.

Or you can just try to decipher what the ITIL books say (not much, not clear, and not prescriptive). 

Why is the product manager role important to me?  They are the ones who own what goes in the service catalog. When I speak about an actionable service catalog, it's really the product manager who determine the packages, features, content, price and what needs to happen to fulfill it. It's a very collaborative role, but they own the product as seen by customers.

So yeah. It's product manager.

A Quick Start to Defining the ITIL Service Catalog Webinar #ITIL #ITSM

Are you struggling with the question: “What’s a service?” Is it hard to get people to agree to a definition?  Need I ask? :)

Trying to document all your service definitions in a Word document or Excel spreadsheet? Don’t have the infrastructure to publish your catalog cost-effectively?

If this is the case, then you are normal; most people are struggling with that situation.

This upcoming newScale webinar will be very helpful to your effort.  The topics covered include:

1. Defining your IT services using ITIL v3 best practices;
2. Publishing standard service definitions within IT and for your customers;
3. Showcasing and promoting what IT does for the business;
4. Updating your services as needs change over time.

You can sign up for free here:

Topic: A Quick Start For Your Service Catalog

Date: Tuesday, November 3, 2009

Time: 9:00 am PT / 12:00 noon ET

Duration: 1 hour

Click here to convert the Webinar time to your local time zone

I understand there will be a surprise announcement that Tuesday, but I can't talk about it until then!

Good Take on Private Clouds in CloudComputing in the Enterprise from CloudBzz

I recommend this article for people building service catalogs. I think it helps to see how the catalog will actually get used.  My comments, in-line.

One of the first things IT needs to let go of, to get a cloud running to its full potential, is the concept of manually approving anything.  All of the rules for approvals need to exist in advance and the system just needs to follow them.  

I don't disagree with this last statement, but this is unlikely to happen in the medium term.  The best thing to do will be to put in electronic approvals so this stuff can be at least reliably tracked.

Having a person “OK” the creation of a VM is just crazy, yet that’s what happens in many IT organizations.  Someone requests a virtual machine instance for a project and it goes into a queue for manual approval, and then manual implementation.  Yikes!!  This isn’t to say that nothing is approved – as I said, you have to set up the rules in advance.  How many instances of X can a department get?  What do we charge them (IT is now really a business, no?)?  Are there time limits on the VMs or servers we provide (e.g. maximum lease terms)?  All of this needs to be there and ready to go.

This is not difficult to carry out with a service catalog.  But in my experience it takes a lot of preparation work to establish the standard, rules, and pools.  In fact, other than budget limits, why should there be limits to how many VM's I can request.  But the reality is most IT shops don't charge back. And you'll need a real good subscription lifecycle manager to track expirations.

Then you need to give people the portal. That’s the magic pixie dust that makes it all come together.  Rather than “requesting” a server, you provision one.  It might take a few minutes for the automati0n to do its work, but that’s a lot better than the hours, days, or even weeks (yes weeks for a single VM!!) it used to take.

That's exactly our customers achieve with our product. We have learned that they a) have to see it to believe it, and b) it takes a while to let go of the reins while they become comfortable with the new operating model.  It's a tranfsformation!

So, to net it out — a private (internal) cloud = hardware + virtualization + automation + chargeback + self-service portal. It also = the promised land for enterprise IT modernization.

Sounds easy?  As if!

Agree. Not so easy if you don't have the right tools.  Read the rest via www.cloudbzz.com

Growing Interest in #CloudComputing Calls for New IT Governance Tools. People Just Beginning to Wake Up.

EMC announced their new cloud service recently; buried within the announcement, was this quote:

...a field of growing importance in enterprise computing circles as businesses try to set and enforce limits on who can access the cloud, and what they can put there. (via gigaom.com)

The service catalog is a central tool for providing those controls to IT. Here's how it works at newScale:

1. We have defined standard configurations in the service catalog,
2. We provide guides that help the user choose the best path, such as "Intranet server," "Sharepoint set up," or "Small Linux test servers".
3. Wizards then assist the requester to ensure the proper workload goes to the proper option. For example, certain workloads require privacy considerations so they automatically stay in the private cloud.
4. Configurators assist the user in making changes to their environment without deviating from the standard.  Think like a Burger King Whopper can be requested with extra pickle, or no onion.  The configurator also prevents mistakes.

This is but the tip of the self-service iceberg.  There's a lot more I'll share at another time. Regardless, the private cloud will require this kind of actionable service catalog. 

No catalog. No cloud.

Is ITSM / ITIL Going to Get Run Over by CloudComputing? Yes, If Gets in the Way

There's a lot of discussion / questions going on about the relationship between ITSM / ITIL and cloud computing.  At some level, cloud computing is nothing but IT; of course ITSM will play a big role ... no? 

Yes, but there are also big differences. And there's a great need to begin to understand those differences. To understand what changes, what remains the same, what gets emphasized, and what gets diminished.

Two examples: Change Management and Service Catalog.

Ch-ch-ch-ch-changes Management

The singular focus on Change Management CAB as the ONE process to add stuff to the infrastructure is either irrelevant in cloud computing or has to be vastly changed, automated and and made policy driven. Heck, there's a request process now in ITIL v3.

It cannot remain the same because in the cloud servers come and go.  The speed of configuration and deployment needs to be much faster than a once a week meeting can handle.

And by the way, moving those to be pre-approved changes is a nice semantic pirouette that solves nothing for an infrastructure team under pressure to adopt virtualization and a cloud computing operating model.

We will have change management, but a huge number will now need to be standard requests off a catalog that go directly provisioning and lifecycle management, and not change management.

The other case is the service catalog. 

I'm seeing great interest from infrastructure teams trying to create self-service provisioning that goes directly to the cloud. They are defining packages, processes, trying to define their standards, etc. 

On the other side of the company, I see ITSM team still thinking a static document is the catalog and struggling with service definitions.

So there's this conflict brewing between the infrastructure group that is in hurry to adopt a cloud operating model and the ITSM group that is only focused on process. There's a good chance the ITSM group will get run over if it gets in the way.

The Cloud Operating Model is a tremendous opportunity for ITSM groups, but only if they can speak the language of cloud. And I'm not seeing that happening. 

Part 9: Preventing Sprawl and Shaping Demand with Showback - 10 Things VMware Admins Should Know About Self-Service

Part 9: Preventing Sprawl and Shaping Demand with Show back

The service catalog can be used to shape demand by making clear the cost of resources; then you can use that information to shape demand and better plan capacity.

You can starting by putting clear prices and costs for resource consumption. Whether you do charge back or "showback" (showing costs, but not charging) is not that important initially.  Showback can be a stepping stone to full charge back at a future moment.   What's important is that EVEN WITHOUT charge back, communicating costs starts to change behavior.

One of newScale's customers a few years ago put a $200 for a service they needed an external company to provide and watched requests drop 40%.

Just understanding that "Large Linux" is 3X small Linux, helps people, many for the first time, to understand the differences in cost to IT.  For example, most people have zero idea of the huge difference in cost between 4 nines and 5 nines of availability. Showing what's included and the costs helps you communicate VALUE.

Show back also helps shape demand.  Demand shaping is a very useful concept for DataCenter management. Here's an explanation from an EE times article:

"Demand shaping" is a demand-driven, supply-constraining customer-centric approach to planning and execution.

... It also helps optimize use of resources, reducing excess inventory and improving inventory turns. At the strategic level, the emphasis is on aligning customers' long-term demand patterns to long-term resource and capacity constraints.

At the tactical level, the focus is on understanding demand patterns and then influencing customers' demand toward available supply, using the levers of price, promotion and products/services bundling.

Pragmatically this might mean showing the cost of "Small Linux VM instance for qa/testing for a month" as effectively $0, but the same configuration in physical form to be $nnn.  This pricing sends the signal that the VM is a better deal. 

We can also add other demand shaping info like lead times.  VM's delivered in 5 minutes, physical in 5 weeks.  

The basic tenet of demand shaping is that it starts with understanding the products the customers are requesting. This is where the standardization and packaging that a service catalog provide are so central to this process.  Understanding which packages and what other services are bundled, then tracking consumption helps us come back with a better offer that is better aligned with our existing capacity and architecture. 

Unless you've defined your "products" you can't do the kind of reporting needed to understand demand. This is what I see broken with most PPM tools -- it's all labor. You have no visibility to demand.

Applying the concept of optimizing resources and reducing excess inventory to Virtualization, translates to gaining higher density and utilization of our existing infrastructure. Which means we need to understand demand patterns in order to better plan capacity.

People really do respond to cost information. It can be a powerful tool to manage capacity.

Part 9: Preventing Sprawl and Shaping Demand with Showback - 10 Things VMware Admins Should Know About Self-Service

Part 9: Preventing Sprawl and Shaping Demand with Show back

The service catalog can be used to shape demand by making clear the cost of resources; then you can use that information to shape demand and better plan capacity.

You can starting by putting clear prices and costs for resource consumption. Whether you do charge back or "showback" (showing costs, but not charging) is not that important initially.  Showback can be a stepping stone to full charge back at a future moment.   What's important is that EVEN WITHOUT charge back, communicating costs starts to change behavior.

One of newScale's customers a few years ago put a $200 for a service they needed an external company to provide and watched requests drop 40%.

Just understanding that "Large Linux" is 3X small Linux, helps people, many for the first time, to understand the differences in cost to IT.  For example, most people have zero idea of the huge difference in cost between 4 nines and 5 nines of availability. Showing what's included and the costs helps you communicate VALUE.

Show back also helps shape demand.  Demand shaping is a very useful concept for DataCenter management. Here's an explanation from an EE times article:

"Demand shaping" is a demand-driven, supply-constraining customer-centric approach to planning and execution.

... It also helps optimize use of resources, reducing excess inventory and improving inventory turns. At the strategic level, the emphasis is on aligning customers' long-term demand patterns to long-term resource and capacity constraints.

At the tactical level, the focus is on understanding demand patterns and then influencing customers' demand toward available supply, using the levers of price, promotion and products/services bundling.

Pragmatically this might mean showing the cost of "Small Linux VM instance for qa/testing for a month" as effectively $0, but the same configuration in physical form to be $nnn.  This pricing sends the signal that the VM is a better deal. 

We can also add other demand shaping info like lead times.  VM's delivered in 5 minutes, physical in 5 weeks.  

The basic tenet of demand shaping is that it starts with understanding the products the customers are requesting. This is where the standardization and packaging that a service catalog provide are so central to this process.  Understanding which packages and what other services are bundled, then tracking consumption helps us come back with a better offer that is better aligned with our existing capacity and architecture. 

Unless you've defined your "products" you can't do the kind of reporting needed to understand demand. This is what I see broken with most PPM tools -- it's all labor. You have no visibility to demand.

Applying the concept of optimizing resources and reducing excess inventory to Virtualization, translates to gaining higher density and utilization of our existing infrastructure. Which means we need to understand demand patterns in order to better plan capacity.

People really do respond to cost information. It can be a powerful tool to manage capacity.

Part 9: Preventing Sprawl and Shaping Demand with Showback - 10 Things VMware Admins Should Know About Self-Service

Part 9: Preventing Sprawl and Shaping Demand with Show back

The service catalog can be used to shape demand by making clear the cost of resources; then you can use that information to shape demand and better plan capacity.

You can starting by putting clear prices and costs for resource consumption. Whether you do charge back or "showback" (showing costs, but not charging) is not that important initially.  Showback can be a stepping stone to full charge back at a future moment.   What's important is that EVEN WITHOUT charge back, communicating costs starts to change behavior.

One of newScale's customers a few years ago put a $200 for a service they needed an external company to provide and watched requests drop 40%.

Just understanding that "Large Linux" is 3X small Linux, helps people, many for the first time, to understand the differences in cost to IT.  For example, most people have zero idea of the huge difference in cost between 4 nines and 5 nines of availability. Showing what's included and the costs helps you communicate VALUE.

Show back also helps shape demand.  Demand shaping is a very useful concept for DataCenter management. Here's an explanation from an EE times article:

"Demand shaping" is a demand-driven, supply-constraining customer-centric approach to planning and execution.

... It also helps optimize use of resources, reducing excess inventory and improving inventory turns. At the strategic level, the emphasis is on aligning customers' long-term demand patterns to long-term resource and capacity constraints.

At the tactical level, the focus is on understanding demand patterns and then influencing customers' demand toward available supply, using the levers of price, promotion and products/services bundling.

Pragmatically this might mean showing the cost of "Small Linux VM instance for qa/testing for a month" as effectively $0, but the same configuration in physical form to be $nnn.  This pricing sends the signal that the VM is a better deal. 

We can also add other demand shaping info like lead times.  VM's delivered in 5 minutes, physical in 5 weeks.  

The basic tenet of demand shaping is that it starts with understanding the products the customers are requesting. This is where the standardization and packaging that a service catalog provide are so central to this process.  Understanding which packages and what other services are bundled, then tracking consumption helps us come back with a better offer that is better aligned with our existing capacity and architecture. 

Unless you've defined your "products" you can't do the kind of reporting needed to understand demand. This is what I see broken with most PPM tools -- it's all labor. You have no visibility to demand.

Applying the concept of optimizing resources and reducing excess inventory to Virtualization, translates to gaining higher density and utilization of our existing infrastructure. Which means we need to understand demand patterns in order to better plan capacity.

People really do respond to cost information. It can be a powerful tool to manage capacity.

Part 7: 10 Things Vmware Server Admins Should Know About Self-Service. Role Based Access Control.

Part 7 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

7. It's safe to offer your services in a catalog as long as there's robust role-based access controls down to the granular level and policies.

At larger companies, there's often a concern that if the users can see it, they'll order it. "We'll be inundated with requests and we can barely keep up as it is," I've heard some folk say.

This is where role-based access control (RBAC) comes in.  RBAC allows you to create rules so that some service classes, or even individual services are viewed by some groups, departments or even individuals.

Your service catalog helps you control:

• Who can see, order or approve what services
• Who can change what services once operational

For example, certain mainframe environments are available only to application teams that work on the mainframe; while linux test servers could be available to all of QA and Development groups. 

The same could be for certain VM environments. Some developers can do some basic lifecycle (start, reboot, terminate) while others may get more services (add more memory, snapshot).

The most extreme case of RBAC use in a service catalogue was the car buying service available to executives in a Mexican company.  Pretty sweet.

Our service catalog at newScale can provide access control from a complete service category, to a service definition, to form component, down to a field.  These get quite a bit of use. For example, you may only want the requestor to see the server password. 

Having these type role based access control actually makes it easier to deploy self-service since you don't need to worry about security.

Part 7: 10 Things Vmware Server Admins Should Know About Self-Service. Role Based Access Control.

Part 7 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

7. It's safe to offer your services in a catalog as long as there's robust role-based access controls down to the granular level and policies.

At larger companies, there's often a concern that if the users can see it, they'll order it. "We'll be inundated with requests and we can barely keep up as it is," I've heard some folk say.

This is where role-based access control (RBAC) comes in.  RBAC allows you to create rules so that some service classes, or even individual services are viewed by some groups, departments or even individuals.

Your service catalog helps you control:

• Who can see, order or approve what services
• Who can change what services once operational

For example, certain mainframe environments are available only to application teams that work on the mainframe; while linux test servers could be available to all of QA and Development groups. 

The same could be for certain VM environments. Some developers can do some basic lifecycle (start, reboot, terminate) while others may get more services (add more memory, snapshot).

The most extreme case of RBAC use in a service catalogue was the car buying service available to executives in a Mexican company.  Pretty sweet.

Our service catalog at newScale can provide access control from a complete service category, to a service definition, to form component, down to a field.  These get quite a bit of use. For example, you may only want the requestor to see the server password. 

Having these type role based access control actually makes it easier to deploy self-service since you don't need to worry about security.

Part 7: 10 Things Vmware Server Admins Should Know About Self-Service. Role Based Access Control.

Part 7 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

7. It's safe to offer your services in a catalog as long as there's robust role-based access controls down to the granular level and policies.

At larger companies, there's often a concern that if the users can see it, they'll order it. "We'll be inundated with requests and we can barely keep up as it is," I've heard some folk say.

This is where role-based access control (RBAC) comes in.  RBAC allows you to create rules so that some service classes, or even individual services are viewed by some groups, departments or even individuals.

Your service catalog helps you control:

• Who can see, order or approve what services
• Who can change what services once operational

For example, certain mainframe environments are available only to application teams that work on the mainframe; while linux test servers could be available to all of QA and Development groups. 

The same could be for certain VM environments. Some developers can do some basic lifecycle (start, reboot, terminate) while others may get more services (add more memory, snapshot).

The most extreme case of RBAC use in a service catalogue was the car buying service available to executives in a Mexican company.  Pretty sweet.

Our service catalog at newScale can provide access control from a complete service category, to a service definition, to form component, down to a field.  These get quite a bit of use. For example, you may only want the requestor to see the server password. 

Having these type role based access control actually makes it easier to deploy self-service since you don't need to worry about security.

Part 6: 10 Things Vmware Server Admins Should Know About Self-Service

Part 6 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

6.There's a lot more to self-service than a web form.

I'm shocked by what some people call self-service. A 1996 style web form painted against someone's workflow API's with all the appeal of a lipsticked pig without a date on a Saturday night.  No offense to pigs.

There's a heck of lot more to self-service than that.  We need to think about the customer experience and what we want to achieve rather than the technology. Some useful concepts to consider are:

Navigation categories that guide a user to find a particular server or configuration. For example, some users will think from the point of view of the use they'll give it (say, Intranet or App Server), others will think in terms of performance (High, Medium), yet others may think in terms of cost.  The same server should be available from multiple categories. 

Consider using a catalog to deliver pre-packaged environments into appliances so it's not a server that's requested, but an Oracle App Test environment or MS SQL development system.  This a growing trend and many good tools are out there from the likes of VMware and rPath.

Comparison guides that help answer the question "am I making the right choice from what's available?" These guides need to have different vectors of comparison so the user can see the 2-5 most important differences in a configuration

Good content needs to be developed. Feature, benefit and functions.  With good pictures.  Not the "Win2kSrvrx86FullImg"  This include links to other documents, FAQ's, or videos.

Good search. Many young application people are well, young.  They are used to Google.  So this means they want to search and click.  So really need to work up keywords and mis-spellings so you get that hint of "Did you mean....?  Try it on Google or Amazon. Search for Adobee.  It's really simple to do and trust me it'll bring a smile to your user's face.

More advanced but even more important for server administration are Configuration Wizards .  So after I've picked up my my general server or environment, a wizard will guide to a final recommendation; it will also let the user tweak their choices so they can make adjustments her and there.  

These type of wizard needs to also be present in the forms to allow finer grain control.  For example, one of our forms asks about data privacy requirements, if you select yes, it switches from a cloud environment to an internal environment. 

A self-service wizard can help the user do some rough calculations about capacity, availability and security. It doesn't need to be exact, but it provides Rough Order of Magnitude estimates that help that user make a better choice. The wizard should also prevent users from mixing things that can't go together.

Provide self-service control over lifecycle processes such as start, stop, snapshot, and configure.  Recently, I attended a Morgan Stanley CTO symposium where the topic of self-service came up.  An interesting quote was: "Use self-service.  Don't worry about the users getting it wrong. They always do, no matter how much we work with them, except they always blamed us before.  Just make sure they can correct it on their own."  Smart. 

Your service catalog should  let a user see all the items they have ordered, the status of service delivery and ... the lifecycle requests that can be made against them.   For example, a server request could be pending approval, and another operational.  The operational server would have requests for termination, reboot or reconfiguration as options that can be requested.  This is lifecycle management.

Don't skip on the graphics. Have a graphic strategy so the colors, fonts and pictures are all in the same family. 

Use service bundles to communicate value. This allows a form to be simpler because it reuses other services. 

I could go on, but I'll stop here.

I've written about this here, here and here.

Part 6: 10 Things Vmware Server Admins Should Know About Self-Service

Part 6 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

6.There's a lot more to self-service than a web form.

I'm shocked by what some people call self-service. A 1996 style web form painted against someone's workflow API's with all the appeal of a lipsticked pig without a date on a Saturday night.  No offense to pigs.

There's a heck of lot more to self-service than that.  We need to think about the customer experience and what we want to achieve rather than the technology. Some useful concepts to consider are:

Navigation categories that guide a user to find a particular server or configuration. For example, some users will think from the point of view of the use they'll give it (say, Intranet or App Server), others will think in terms of performance (High, Medium), yet others may think in terms of cost.  The same server should be available from multiple categories. 

Consider using a catalog to deliver pre-packaged environments into appliances so it's not a server that's requested, but an Oracle App Test environment or MS SQL development system.  This a growing trend and many good tools are out there from the likes of VMware and rPath.

Comparison guides that help answer the question "am I making the right choice from what's available?" These guides need to have different vectors of comparison so the user can see the 2-5 most important differences in a configuration

Good content needs to be developed. Feature, benefit and functions.  With good pictures.  Not the "Win2kSrvrx86FullImg"  This include links to other documents, FAQ's, or videos.

Good search. Many young application people are well, young.  They are used to Google.  So this means they want to search and click.  So really need to work up keywords and mis-spellings so you get that hint of "Did you mean....?  Try it on Google or Amazon. Search for Adobee.  It's really simple to do and trust me it'll bring a smile to your user's face.

More advanced but even more important for server administration are Configuration Wizards .  So after I've picked up my my general server or environment, a wizard will guide to a final recommendation; it will also let the user tweak their choices so they can make adjustments her and there.  

These type of wizard needs to also be present in the forms to allow finer grain control.  For example, one of our forms asks about data privacy requirements, if you select yes, it switches from a cloud environment to an internal environment. 

A self-service wizard can help the user do some rough calculations about capacity, availability and security. It doesn't need to be exact, but it provides Rough Order of Magnitude estimates that help that user make a better choice. The wizard should also prevent users from mixing things that can't go together.

Provide self-service control over lifecycle processes such as start, stop, snapshot, and configure.  Recently, I attended a Morgan Stanley CTO symposium where the topic of self-service came up.  An interesting quote was: "Use self-service.  Don't worry about the users getting it wrong. They always do, no matter how much we work with them, except they always blamed us before.  Just make sure they can correct it on their own."  Smart. 

Your service catalog should  let a user see all the items they have ordered, the status of service delivery and ... the lifecycle requests that can be made against them.   For example, a server request could be pending approval, and another operational.  The operational server would have requests for termination, reboot or reconfiguration as options that can be requested.  This is lifecycle management.

Don't skip on the graphics. Have a graphic strategy so the colors, fonts and pictures are all in the same family. 

Use service bundles to communicate value. This allows a form to be simpler because it reuses other services. 

I could go on, but I'll stop here.

I've written about this here, here and here.

Part 6: 10 Things Vmware Server Admins Should Know About Self-Service

Part 6 of the series "10 Things VMware Server Admins Should Know About Self-Service Catalogs and Lifecycle Management" that I'll be publishing over the next couple of weeks.

6.There's a lot more to self-service than a web form.

I'm shocked by what some people call self-service. A 1996 style web form painted against someone's workflow API's with all the appeal of a lipsticked pig without a date on a Saturday night.  No offense to pigs.

There's a heck of lot more to self-service than that.  We need to think about the customer experience and what we want to achieve rather than the technology. Some useful concepts to consider are:

Navigation categories that guide a user to find a particular server or configuration. For example, some users will think from the point of view of the use they'll give it (say, Intranet or App Server), others will think in terms of performance (High, Medium), yet others may think in terms of cost.  The same server should be available from multiple categories. 

Consider using a catalog to deliver pre-packaged environments into appliances so it's not a server that's requested, but an Oracle App Test environment or MS SQL development system.  This a growing trend and many good tools are out there from the likes of VMware and rPath.

Comparison guides that help answer the question "am I making the right choice from what's available?" These guides need to have different vectors of comparison so the user can see the 2-5 most important differences in a configuration

Good content needs to be developed. Feature, benefit and functions.  With good pictures.  Not the "Win2kSrvrx86FullImg"  This include links to other documents, FAQ's, or videos.

Good search. Many young application people are well, young.  They are used to Google.  So this means they want to search and click.  So really need to work up keywords and mis-spellings so you get that hint of "Did you mean....?  Try it on Google or Amazon. Search for Adobee.  It's really simple to do and trust me it'll bring a smile to your user's face.

More advanced but even more important for server administration are Configuration Wizards .  So after I've picked up my my general server or environment, a wizard will guide to a final recommendation; it will also let the user tweak their choices so they can make adjustments her and there.  

These type of wizard needs to also be present in the forms to allow finer grain control.  For example, one of our forms asks about data privacy requirements, if you select yes, it switches from a cloud environment to an internal environment. 

A self-service wizard can help the user do some rough calculations about capacity, availability and security. It doesn't need to be exact, but it provides Rough Order of Magnitude estimates that help that user make a better choice. The wizard should also prevent users from mixing things that can't go together.

Provide self-service control over lifecycle processes such as start, stop, snapshot, and configure.  Recently, I attended a Morgan Stanley CTO symposium where the topic of self-service came up.  An interesting quote was: "Use self-service.  Don't worry about the users getting it wrong. They always do, no matter how much we work with them, except they always blamed us before.  Just make sure they can correct it on their own."  Smart. 

Your service catalog should  let a user see all the items they have ordered, the status of service delivery and ... the lifecycle requests that can be made against them.   For example, a server request could be pending approval, and another operational.  The operational server would have requests for termination, reboot or reconfiguration as options that can be requested.  This is lifecycle management.

Don't skip on the graphics. Have a graphic strategy so the colors, fonts and pictures are all in the same family. 

Use service bundles to communicate value. This allows a form to be simpler because it reuses other services. 

I could go on, but I'll stop here.

I've written about this here, here and here.