|By Esmeralda Swartz||
|December 6, 2013 10:00 AM EST||
As we move closer toward everything-as- a-service (XaaS), the title "Internet of Agents" seems to fit what is really happening. Agents are systems and devices that sense what is going on, and they exchange information with and act on behalf of other agents and people in ways that ultimately result in useful services being performed.
When we start to view the delivery of services as a distributed cooperative effort conducted by millions of agents, as opposed to the actions of a few dedicated and single-minded service platforms, we start to get a glimpse of the huge potential of the Internet of Agents. We also must face the challenge of keeping track of this expanding service universe: managing security and permissions, making the dynamic portfolio available and usable, and ultimately monetizing all of this and ensuring that each contributor to these increasingly complex value chains is compensated for the fragments of service capability provided.
There is no doubt that to be successful in this evolving environment, companies will have to change many aspects of the ways in which they run their businesses. Not all of the traditional ways of working, business models, tools and relationships will survive. That's evolution.
For example, let's take a look at a core component of today's management systems: the product catalog.
Product catalogs were designed originally to - guess what - catalog products, tangible objects and widgets in a warehouse. A product is a reasonably well-defined, concrete physical entity. You can touch and hold a product. If products are small, they come to the warehouse in boxes or on pallets. If they're big, they come in bigger boxes or crated on a giant truck. Products just out of the box do nothing much until a human wields them, manipulates them, puts them on display or switches them on.
The traditional catalog assigns a SKU or similar unique identifier to every product or definable product variant. The idea is that a product can be closely defined by specification and manufacturer, and every product with the same SKU is an example of that product. They should all be similar enough that it doesn't matter which one you buy. Some minor variation is of course allowed - otherwise every banana would need its own individual barcode - but you get the idea. Products with the same SKU are, in principle, interchangeable. They can be stacked together on shelves in a warehouse, and when an order is received for some widget with a specific SKU, it usually shouldn't matter which box the customer gets.
Devised to handle widgets in warehouses, the traditional product catalog has lasted surprisingly well - at least, for those businesses whose products or services still look and behave like widgets in a warehouse. After all, a service is just a product consisting of an activity instead of a thing, isn't it?
Superficially, a service is a bit like a product; you can describe it, put a price on it and put it in a product catalog. You can deliver it, bill for it and put the revenue in a bank account. This superficial resemblance has enabled people to think that services can be totally "productized." This is true, but only if you are prepared to live with the significant limitations of this approach to how those services are conceived, offered and delivered.
Indeed, because of the need to fit services into a product-oriented systems environment, we used to hear people in service companies talking a lot about "productizing" their services: clear, non-fuzzy definitions, perhaps a small range of distinct sizes and colors, but otherwise the aim was to make every service instance look as similar as possible. We don't hear that so much these days. In my next blog post, I'll explain why.