In case it isn't clear by now, I'll make it explicit: I love the Tridion Object Model API. Sure, our content delivery API is nice, and OData on the content delivery rocks.But me and the TOM was love at first sight (even if TOM never really acknowledged or even winked at me, I'm fine with this one-sided relationship). TOM has matured quite a lot in the past few years, moving from an extremely flexible COM+ architecture to a semi-functional .NET implementation (TOM.NET) to a fully functional one (with Tridion 2011) and with its WCF, service-oriented face ("CoreService") it just shines.
One of the intended benefits of adding a WCF face to TOM was to open up access to our Content Manager core to any client you would want to implement yourself or ourselves (for instance, the Content Manager Explorer and Experience Manager interfaces of our new soon-to-be-released Tridion 2013 use the CoreService to talk to the core), but a few things happened - perhaps unintended initially - with this new-found freedom to interact with Tridion: customers started looking at the CM as something that other applications can talk to.
And Tridion has one functionality that most other applications lack: it can push content to your website. Any type of content. At any time of the day. And though I wouldn't recommend using Tridion to push your 70 million transaction records to your website hourly, it actually fits really well if you don't need to republish your full catalog all the time (which typically is a sign of a bad architecture to start with, but let's not go there). A decoupled WCM will always have trouble with pushing time-sensitive information - like updating the price of 1700 products in the next 2 seconds while at the same time publishing your new 7000 pages website. But we have no trouble at all pushing product info to the website. Even if we don't manage it - or even know it exists beyond perhaps a SKU or product ID.
And I'm not the only one to have realized the potential of this. One of our customers is now routing all 3rd-party content via Tridion (through WCF) for editorial review and publishing to the website, something that was particularly painful for them to do before Tridion was added to the picture. Another one is considering using Tridion as the publishing mechanism for some "records stored in Oracle" that don't need editor attention - but do need to end up on the website, and that's hard to do with their current system. Yet another customer is looking at providing access to Tridion from their PIM, so "collections" of products can be published directly from the PIM's interface (while having Tridion do the heavy lifting).
This flexibility to play nice in the Enterprise is becoming more & more key to today's always on, always connected "modern enterprise" that must deal with aging products that are incredibly hard to upgrade or modify to cope with "simple things" like publishing to a website. But when all it takes is to call a webservice, upload a stream or structured content, and ask Tridion to "Please publish this to our Live site", the whole game changes. Suddenly, it's not black magic anymore to get something on the website.
And I love that too. EAI was my playground before Tridion, and now Tridion is providing EAI-lite features (don't hold your breath on having Tridion handle your bank transactions just yet, but as a publishing service provider for your internal tools it is awesome).
In a recent discussion with a customer we were debating whether to import product info into Tridion or keeping it where it is. The customer's architect was inclined to placing it all in Tridion, while we were telling them not to - probably a surprising action from a vendor, telling a customer to "not use our software to store your info" - but we had a really good reason for this: Tridion is not a PIM. It was not built as a PIM. It does not think as a PIM. So use your PIM for PIM-like tasks.
Likewise, your PIM is not built to publish stuff to the Web or manage it once its live. So don't use your PIM to publish to the web, just ask Tridion to do it for you.
I guess I may be quite a geek, but this idea of using software for what it was built, and talk to other software so they can complement each other, feels just like poetry to me. :-)
PS - It turns out the architect's previous experience with WCM was with a very large competitor of SDL, which has notorious problems playing nicely in the enterprise, and that's why he thought he would have to import all content into Tridion first. He has seen the light now!
