Monday, December 25, 2006
Thoughts on BPM and Security
One industry analyst that I have a ton of respect for, Alan Peltz-Sharpe said something intriguing in this Blog Entry that I have been noodling. The phrase: I'm sure many ECM vendors will be secretly annoyed about this, for they pride themselves on their security capabilities made me ask myself several questions, including:
- If vendors truely have pride in their security capabilities and us customers want them to do even more, why wouldn't the vendors actually appreciate this?
- I should have articulated that the idea behind the approach wasn't my own but actually came from a very smart enterprise architect that is employed by Johnson & Johnson as part of a conversation at the Enterprise Computing Strategy put on by industry analyst firm: The 451 Group. While I wish I could take credit for it, I in all honesty can't. I am simply providing amplification of his thoughts.
- I have been debating the merits of standards bodies in which many folks will get twisted and think of as being anti-social. The thesis of my argument is why would an enterprise pay to participate and get the right to vote? Should I care about my right to vote which may or may not result in commercial and open source vendors actually implementing or are enterprises better off by trying other approaches?
- What approach would an industry analyst firm such as Alex Fletcher and Entiva, the folks over at Macehiter Ward-Dutton or even your firm recommend as an alternative approach to getting sorely needed specifications implemented by their vendors in a expedient way? Would also love for you to share insights on how an industry analyst firm can provide acceleration and amplification in this regard?
- Part of the thing that slows down participation yet at the same time increases implementation is that this needs to occur one vendor at a time. This is primarily driven by the fact that participants in a conversation may leak things that the vendor and their NDA wouldn't want discussed with outsiders. Likewise, if the vendor hears the same requirement echoed in the same words at the same time by dozens of Fortune enterprises they will have competitive advantage over vendors who choose to stay annoyed and not listen to the desire of the many. Once implemented, other vendors in this space regardless of whether a standard exists or not, will have no choice but to implement as they wouldn't want to be left out by the same industry analysts who put them into matrixes comparing vendor A and their features to another...
- Likewise, this notion was discussed with the vendor in advance whom thought that the opportunity to understand requirements across multiple customers at the same time, removing the ability to have to distill each and every distinct conversation across vendors provides them with a level of increased efficiency and benefits them as well. In fact, the idea was discussed with the target vendors in detail before it was even mentioned in my own blog.
- New York Life
- Bank of America
- Wells Fargo
- American Express
- Washington Mutual
The goal is to start a conversation around BPM and the following topics:
- External Authorization: Many folks are attempting to use BPM to build composite enterprise applications that may leverage SOA, ECM and so on. The idea says that if I want to optimize people and architecture I may use a BPM engine to manage tasks while storing documents the tasks need in a ECM repository. This of course causes a disconnected security model where BPM engines have their own thoughts on authorization which are different than what ECM thinks. Minimally it does beg the need for having the ability to externalize authorization via a standards based mechanism.
- Active Directory: It would be pretty difficult to find a large enterprise that doesn't have Active Directory. In today's society since directory services are so pervasive, it no longer makes sense for each and every enterprise application to be creating their own separate and distinct identity store. How come BPM products cannot simply bind at runtime and get their own information instead of requiring enterprises to perform import/syncronization mechanisms. This approach is fugly.
- Encryption: BPM implementations usually contain highly confidential information and therefore the need to encrypt data that is used in the BPM process is vital. NOTE: Encryption shouldn't equal shared secret as most folks are good at keeping them. How about also providing hooks into PKI mechanisms that don't require keeping a password/key in a configuration file in cleartext? Wouldn't it be useful to tag a process as encrypted so that no matter what it touches, all stuff about it can't fall into the wrong hands?
- Single Signon: Revisiting the integration between BPM and ECM for a minute, this also begs the need to have a single signon capability. Why do I have to authenticate to each component which is solely based on a dated construct of ID and Password? Likewise, while there are product-specific ways of solving this such as using Netegrity Siteminder or Oracle CoreID, the better way is to support industry standards such as SAML and/or WS-Federation.
- OpenID: I can't think of a better enterprise scenario for using specifications such as OpenID than to incorporate into a BPM workflow. Having a consistent understanding of identity throughout all business processes would be nirvana.
- Logging: Have you looked at vendors such as LogLogic? If you have considered even for a second the problem of logging within a BPM context, you would see the need to close this gap.
- Identity Propagation: As business processes hop from tier-to-tier, so should identity...