Enterprise Architecture: From Incite comes Insight...

My final look at the responses of Craig Randall when it comes to ECM standards...

I’m becoming rather bored of the barbs. Yet, despite them, it’s worth providing answers to reasonable questions

I apologize profusely for asking difficult questions. I guess it is unreasonable for anyone reading up on ECM to surely expect folks to consider security in today's marketplace. Security should be solely limited to whatever makes folks feel comfortable and avoid discussion of things that could be labeled as unreasonable if they might have to do some homework.

I’ve said as much already in my blog, which by the way is a personal weblog and not a vendor weblog.

You will note that my blog as well is a personal blog and in no way associated to anything with my employer. That being said, this doesn't prevent me from providing commentary on things I belief. For example, as an Enterprise Architect, I have opinions on open source that are in many ways opposed to my thoughts outside of work. I am not looking for a status of Documentum's roadmap as that would be of nebulous value. I am always curious though of what is bouncing around in other folks brains. If someone were to asking me what I am currently working on at work, I would avoid the question as it is status-oriented. If you however were to ask me what do I think about on a daily basis, I would respond with full transparency.

I don’t think savagely of James or anyone else, supposedly thinking: “the easier it is to get rid of your product, the more we like you.” Actually, I’m fully of the mind that you should be in full control of your content, metadata, identity, etc. In this sense, I think that the opposite generally holds: the more you respect what flows in your platform, the more your platform will be relied upon.

My statement was related to portability and avoidance of vendor lock-in. For example, a buyer may feel more comfortable choosing an open source database because if it doesn't work out, they can quickly migrate to another product. Standards such as ANSI-SQL allow for this to happen. Your statement was about leveraging something you have already purchased which is a different dimension. Our collectively statements both hold true and in some situations are complementary while in others are in conflict.

Being candid, I am not a security nor an identity expert, and I’ve never advertised myself as one. Regardless, these are critical aspects of any ECM platform, and DFS does afford greater openness via its support of SOAP, WSDL, WS-Security, etc.

I am not sure that any of my comments require anyone to be a security or identity expert. I think if you understand that DFS is a client tier API and that all one has to do to bypass it is to simply not use it, then it is inherently insecure. In terms of support for WS-Security, all this means is that there is a place to put security stuff in the SOAP header. It doesn't mean that just because you support WS-Security that support for SAML, Kerberos, WS-Federation and so on are supported. Was simply looking for a deeper understanding of your past blog entries. Some folks will say they support WS-Security only to have still stuck with username/password constructs which at some level is dishonest.

Likewise, one should acknowledge that there is a difference between server APIs and client APIs. I hope that you are noodling as part of your day job making both aspects of the equation extensible...

DFS is a forthcoming enhancement to the EMC Documentum platform in its 6.0 release–one focuses on participation within and enablement of SOA, where not all services come from Documentum or into Documentum (e.g. WSDL from DFS bound into a capable third party BPM system, MEP’s between an ERP service and a DFS service, etc.).

Your previous blog entry talked about integration between Documentum and other BPM products from a UI perspective where I asked about what your thoughts were in terms of creation of industry standards were. Here you have mentioned using DFS which I understand is a service interface which of course you know is distinct from a UI way of integration.

For example, providing XACML support means having an entitlement on every usage of every piece of content from an external source and not from Documentum’s security model.

My commentary wasn't related to Documentum but the ECM domain at large who seem to have fell in love with IRM/DRM type constructs while pretty much the rest of the world understands and embraces the notion of declarative security models that can be externalized away from the product. Yes, IRM/DRM is a separate product in terms of a SKU mindset but where I can make a BEA WebLogic Portal interoperate with Securent, I can also take BEA Enterprise security and make it interoperable with say Vordel. I simply want to understand the mindset of ECM folks at large and hope to understand why they are on a different page than the rest of the industry at large.

I apologize if my questions make folks feel uncomfortable, simply attempting to understand the ECM domain at large. If I observe inconsistencies then should I not ask deeper questions about them in order to gain insight or would the ECM community prefer me to exercise my right to remain silent and only talk about the wonderful progress of features in this world kinda like the industry analysts do without understanding how ECM fits into the enterprise ecosystem?