I have good news about cloud computing: Everyone's criticizing it.

Here are just some of the headlines about cloud computing and virtualization that have appeared recently in my inbox from sources such as Network World, Webtorials and NoJitter:

-- Cloud computing: Reality vs. fiction

-- Virtualization: Not as simple as it sounds

-- Are your cloud services secure?

-- Cloud Computing: A Reality Check & Guide to Risk Mitigation

-- Businesses not sold on using public cloud for capacity

That's great stuff! No enterprise technology has ever prospered while it was being emptily hyped. Things only take off once the problems are aired.

One focus of all of this attention is obviously going to be security. (As it is with everything at first. It was a huge issue in the early days of MPLS because it was -- gulp! -- IP.) You'll see jumping-off points in one of the items above about cloud security to white papers, including from vendors like Cisco and Juniper. These papers often deal with the key issue of going beyond perimeters such as firewalls to the whole concept of borderless networks.

One issue, though, that tends not to get enough attention in any technology at first is the matter of Service Level Agreements. Sure, SLAs are often mentioned, and even headlined by vendors in their product announcements. But initial SLAs are often not measured correctly or meaningfully.

In new technology after new technology, we at TC2 and LB3 have seen repeated gaps and weaknesses in SLAs along similar lines. Classic problems include: 1) SLAs for service availability but not true network performance such as application response time; 2) vagueness in appropriate remedies; 3) overly broad definitions of maintenance windows that bump aside any SLA measurement; 4) requiring the customer to make its own notification of below-par performance to trigger the actual SLA measurement and any chance of enforcement.

Could you see these issues in such cloud computing arenas as "Software as a Service" and "Infrastructure as a Service"? We've begun discussing this at past editions of the CCMI Telecom Negotiation Conference, and it'll be a key focus at the upcoming meeting in San Diego.

SLAs as well as all of the issues referenced in these recent articles and e-newsletters are the necessary sort of discussion all enterprises must have as they explore cloud computing.

How often has a carrier account manager conditioned a particular response to you around what he or she "can do" or "has to do" in light of corporate directives? Pretty often, I bet. Carriers find it convenient to tie the hands of their people in the field around various sourcing and operational requirements -- or at least let account teams give the impression that their hands are tied.

Keep that in mind the next time you're dealing with the mixed blessing of a corporate directive from your company. Obviously many telecom buyers are hearing demands from senior management for specific and immediate cost savings -- a double-edged sword that can lead to manipulation by carriers when these demands come out into the open. But you may also be dealing with a new set of additional mandates rooted in the pressure that companies feel to standardize the procurement function in today's economically stressed environment.

These mandates come under many names and cross the boundaries between sourcing and ongoing operations. You may have a "Supplier Governance" process that you have to instruct your carriers and equipment vendors to follow. There may be a set of "Procurement Compliance" procedures that you receive from higher-ups and must be satisfied. You may now even have a "Chief Procurement Officer" to deal with, to go along with the demands of CFOs and other top executives.

Even if you don't hear these terms in your company, you may be part of an over-arching IT organization with a steadily increasing diet of standard demands that alternately assist and hinder you in your job. Some companies even try to force standardized IT agreements onto the telecom process -- misunderstanding the unique structure of telecom agreements and making it more difficult to include critical, telecom-oriented terms and conditions.

Of course, IT organizations are also very concerned about data security, both in a generic sense and in terms of industry-specific mandates that derive from legislation in the healthcare, banking and other fields. But sometimes, generic IT requirements just impose an additional layer of bureaucracy and makework in the supplier-user relationship. These extra requirements can present a mixed message about priorities to your key suppliers when they overwhelm the process.

The key here is to harness these "facts of life" in today's environment to your advantage, instead of letting them control you. One way to harness them is to let suppliers know that both sides of the negotiation are operating under mandates, so their mandate isn't the only one that counts.

Take the issue of billing. Companies love to standardize terms for their accounts payable, and they often pressure their managers (such as you) to enforce them with all their vendors. Up to a point, that's a great help. Carriers need to be told not to require silly terms, such as 30 days to pay a bill after a "bill date" that they arbitrarily assign and may not represent actual delivery of the bill.

But telecom billing platforms do have notorious built-in legacies, and some enterprise-wide billing mandates can have the counterproductive effect of forcing a demand into RFPs that none of the bidding carriers will accept. That leaves you without an effective stick to meet your company's mandate. It's an example of what can happen when a mandate controls you rather than you utilizing it to your advantage (such as putting yourself in a position to negotiate the carrier rep away from his or her company's mandate).

The bottom line is that you can't wait until everyone's gathered around the negotiating table to start whining about what bureaucratic checkpoints you need to fulfill. Determining requirements up front in a competitive RFP (or other initial sourcing communication) helps settle what sort of mandates you will need to get from carriers even if they aren't core to the telecom process, and where you are willing and able to go to the mat for a particular requirement.

Do this work up front, and you'll be better prepared to "trade points" with carriers and their actual or perceived corporate requirements. In the end, it'll make it far easier for you to put the energy of the procurement on the core pricing, service levels, and key terms that you know you need for your network rather than let the process get overwhelmed and sidelined by other issues.