Thursday, July 19, 2007
Round Two on ECM and Industry Standards
Bex Huff made an interesting comment:
- We knew it made no sense for an ECM product to be both a user repository and a content repository. That just made things overly complicated. Plus, we could never keep up with the feature requirements. Instead, we recommend integrations that "slave" the content server to an existing user repository.
Sadly, other ECM vendors haven't yet figured out these words of wisdom and make it mandatory for you to duplicate user repository information. So, I guess one takeaway is that Oracle Fusion ECM seems to have a better architecture approach in many regards than their competitors. I will have to check with Alan Pelz-Sharpe and Nick Patience of the The 451 Group to see if they have uncovered this particular dimension in their research. This feels like something customers should be paying attention to and should be on the list of questions to ask as part of an ECM RFP.
- But what if the Active Directory domain controller is on the other side of the planet, and performance sucks? It appears that some ECM systems make the interesting choice of replicating the user repository... but we'd suggest instead using a product that is explicitly designed to replicate a user repository, and "slave" the content server to that... such as Active Directory Application Mode (ADAM).
I think I am in love. The notion of not duplicating functionality within an ECM product also makes sense. If the core operating system can provide an LDAP mechanism then why are ECM vendors continuing to duplicate OS functionality?
- I feel that making every application on the planet support SAML is a silly duplication of effort... I think its better that applications allow for loose slave-like integrations with dedicated user repositories. Use the right tool for the right job.
I am only going to partially agree with your statement. If ECM vendors simply leveraged Active Directory not solely for authentication but also as a user store and mapped to it at runtime then the need for SAML disappears within most scenarios within the enterprise. It still ignores a potential scenario where your users aren't stored in any repository that the enterprise owns.
Consider a scenario where say Pfizer wants to collaborate on development of a new drug with Novartis, Merck and Roche. It would be silly for Pfizer to create an ADAM instance of all Novartis employees and vice versa as these two things would get out of sync pretty quickly. Likewise, exposing the domain controllers so that there is a trust across forests over the Internet would weaken security beyond imagination. The best architecture answer from the security standpoint would be to support an industry standard protocol that could leverage a federated model in which SAML is one method.
Of course, one could argue that if you are truly leveraging Active Directory then you may have a preference for the better protocol which is WS-Federation as it is built into the operating system and doesn't require additional software on the part of every enterprise. Awhile back, Pat Patterson and I had a debate on whether support for SAML and WS-Federation should be a standalone product or should it be built into the operating system and I suspect that this may be evidence that others also prefer it to be in the operating system.
- Now... SXIP and OpenID? Those are genuinely interesting... I'd bet that people will be willing to pay for an integration with them before they'll pay for SAML. Plenty of clients use SalesForce.com, and might be interested in a cleaner integration between content and customers.
SXIP is a company who has taken their IP and are busy merging it with other existing specifications. OpenID holds promise but really needs to get its act together when it comes to closing security gaps. I would bet that more people would be willing to pay for an integration with CardSpace in ECM products than OpenID. Likewise, the need to manage content between users of salesforce.com is huge but those guys also need to start paying better attention to directly supporting industry standards as well and not require proprietary implementations nor third-party software...