The Plight of Inter-Domain Associations

I’ve been in China for almost two weeks, enjoying one of my favorite cuisines again.  One treat I decided to try is pig ear.  I figure if Guy Fieri of the Food Network (http://www.foodnetwork.com/guy-fieri/index.html) will try to eat it, I will be just as adventurous!  But, poor pig ears, their plight is to be hidden away on a buffet table and hard to find.  But they always seem to be offered on the buffet or menu!

A similar plight faces inter-domain associations in Frameworx, such as those between Product, Service, and Resource.  They are there in the Information Framework (SID), mentioned in the Application Framework (TAM), but little mention of them is made in the Business Process Framework  They seem to exist in the nether-world between horizontals in the eTOM and domains in the TAM, although the TAM does stated that the association between Product and Service Catalogs maintained by the Product/Service Catalog and associations between Service and Resources are maintained by the Service/Resource Inventory application.

However, there is often a separation from an application point of view between a Product Catalog and a Service Catalog, which creates a quandary.  Same thing often holds true with a separation between a Provisioning application (Service) and a Resource Inventory application.  Then what?  Where does the management of the associations reside?  And what happens to the association between Products and Services and Products and Resources?  Products, typically “live” in a Customer Order Management and/or a Customer Relationship Management application, while Services and Resources live in others.

The management of these associations is often hidden away and sometimes forgotten.  No one wants them, but everyone will debate about where they should go!  But, they won’t go away.  The TAM now has “Cross Domain Applications”, similar to the SID Common Business Entities domain, so is this where inter-domain association management could go?  Would locating them in Cross Domain Applications, as reusable application areas rather than putting them in specific application areas, be a solution?  And allow vendors to decide how to map their current solutions to these application areas?

I’ll be back home for the next two weeks, taking a two-day “road trip” with Jeannie to a few small Texas towns, then off to South Africa at the end of the month.  Stay tuned!