What is different about the Intalio offering is that it was designed from the beginning to operate in a world where there would be many servers working in a flat federation, not a hierarchy. A concern with federated computer to computer interactions is that they could potentially lock up in what is called a “fatal embrace”. AFAIK there is no other BPMS product on the market that can handle federated deployment.

The question is whether it is up to the kind of complexity that we have been discussing. I hope to explore this more next week in my talk at the Intalio User’s Group meeting in SF, http://intaliocon.com/sessions.php#newaspirationsforbpm

For more of an intro I would look at the Wikipedia entry http://en.wikipedia.org/wiki/Business_Process_Management

Jose De La Cruz’s Intalio intro site: http://intalio4people.wordpress.com/2008/04/18/the-mortals-guide-to-initiation/

Since Intalio is open source, you can download and run the code

Sandy Kemsley’s blog: http://www.column2.com/

Ismael Ghalimi’s blog ( Intalio CEO ): http://itredux.com/

Due to the complexities you correctly mention, I am starting to think that what may be needed is to embed a BPMS inside of the existing supply chain software. What we really to have is a very federated environment, where all the players have to be able to negotiate with each other without fatal embrace. In principle, this is exactly what Intalio’s open source BPMS was designed to do. As far as I know, Intalio’s BPMS is the only one that can actually support federated deployment.

BPMS in general suffered in the early years by being used for things for which other alternatives, such as work flow, could be used. IMHO federated negotiation among supply chain parters is a worthy goal for BPMS to aspire to.

I would like very much to see AMEE be the global repository. We probably also need a label, like the carefully designed nutrition labels in the US to show what the total input to a product is. See http://z.about.com/d/pediatrics/1/0/K/2/nutrition_label.jpg for one example.

When I spoke to PC vendors about this they all said that they were looking into it, but that it was a hard problem. Among other things, place of origin has a lot to do with the actual carbon footprint, not just type of thing you are making. There is some evidence from a Carnegie Mellon 2007 report saying that a desktop made in China could have 3x the emissions of one made elsewhere and that US totals would rise by 20% if we included the bit that comes from making what we buy from China

And I agree that we need to include services, not just discrete products. What we are talking about is creating a culture and awareness of measurement — that you would not buy or use anything unless you understood its carbon impact.

In the “enterprise”, with facilities all over the world, leased space, consultants coming and going, there is a lot of space for incremental emissions of the sort that Web 2.0 apps might capture to otherwise not be measured. I generally think of “supply chain” as relating to physical items purchased (paper, refrigerators, whatever), but for a service business part of the “supply chain” is outside services, which then need to feed their carbon emissions into your system to build a full picture. If everyone (and every business) measured their own footprint, and assigned each part to its appropriate realm/client, and shared that data up the chain (anyone got a standard API? Ideally we’d have everyone put it all in AMEE), we’d be in great shape. And Dopplr and Twitter and others will have a role in measuring that footprint, around the edges.

@gblnetwkr — if the facilities people aren’t talking to the IT people, I’d argue you have bigger problems getting a carbon footprint than whether you use Web 2.0 apps.

I agree with @monkchips that we also need bottom up. I strongly support the use of low cost measuring devices such as the Kill-A-Watt or a similar device from Ecohamster.co.uk which let individuals see what the power implications are of the devices they use, when on full, at idle, and on standby.