[A] pCard is a calling card for a software payload--whether simple single container payloads, or complex multi-container distributed payloads--that contains the information needed by a service provider to determine

a) if they can meet the needs of the payload, and

b) what kind of services are required to do so (and their costs).

• Cloud Brokers
  
  This is something that James has not mentioned yet but I am sure he has thought of it as well. Many people are predicting that a natural evolution in the Cloud marketplace is the rise of Cloud Brokers or what some call Cloud Arbitrage. You can read a bit more about these here.
  
  For a Broker to work they need to be able to process in an automated fashion your workload request, pass that to multiple providers and process the results to feed back your options. For this to work you you don't want to be passing the actual work load around. The type and amount of information may be different to the actual work load and you want it to be much smaller.
  
  
• Security
  
  How much information do you want to give away about your application before setting up a trust relationship with a provider? There are certain items you may not wish to reveal about your application to a list of untrusted parties at this stage of the process. You want to throw out the question, "Hey, I have this workload that looks like this, has these mandatory and these desirable characteristics, can you handle it?" You may get many positive responses but its only after you make a selection that you increase the trust level up a notch to actually start sharing data.
  
  
• Returned information
  
  In addition to a simple response to the requested attributes I propose that there will be additional information which needs to be returned by the provider, such as financial information or time frames. Therefore more than just acknowledging ability to execute the payload you can find out the cost of running that workload with a time commitment. "Yes we can run that application and its 90c per hour with a minimum of 60 hours and we can commit the resources for up to 30 days." Having a descriptor separate to the workload allows these different types of information exchanges to take place.
  
  
• cCards
  
  The conversation does not have to be one way. You can imagine a Broker having to send a lot of requests to providers to have pCards processed. Its my idea that there should be an equivalent of the pCard for the provider, call it a cCard for the want of something better. A provide can describe the capabilities of their service in a cCard and this can be loaded into the your system or the brokers. Of course cCards would need expiry information and you would still actually need to send the request to the provider for the final processing. However if there were thousands of providers the broker could quickly filter that list into a sufficient subset based on the matching of data from your pCard and its set of cCards, so that your pCard only needs to be sent onto the relevant providers. For example, if you have a mandated requirement for geographical location of the service there is no point in sending the request to providers who can't provide a service in that geography.
  
  
• Efficiency
  
  There is lots of effort going into creating a standard for workloads, through OVF, vApp and others. However vendors are always going to try and keep their edge and there is only so much standardization that can be done within the elements that have to actually do the grunt work of the actual workload. Having a separate and lighter construct could make things a lot easier. Certainly a pCard could be generated from the packaged workload or even before its packaged up. You could see an analysis system working through your existing workloads running scenarios of how they could be efficiently restructured, running some ROI scenario,s before any actual work was actually done.