In a recent post, enterprise architect James McGovern wondered whether BPM products, like Lombardi's, support XACML.

So I replied with a comment discussing BPM and security mechanisms:

With respect to security there are two fundamental issues: who are you? and what do you have access to? In general, the OASIS SAML specification deals with the former, and the OASIS XACML specification deals with the latter.

Lombardi Teamworks explicitly supports SAML as a means of identifying who you are and passing that around. Very few, if any other, BPMS vendors support SAML and it's a non-trivial specification to implement. Lombardi Teamworks does support SAML and as a result, we have many very secure implementations and customers.

Authorization is a bit different. Generally speaking, XACML defines (1) the mechanics of defining a central set of authorization policies, and (2) how a service accesses those policies. That is, and this is key, you want the service being accessed to be its own enforcer, based on policies set in the central policy repository.

You want the called service to ask the calling application for credentials, and you want the called service to be the one that _allows_ access based on the policies. So as we see, the XACML check is done under the covers of the web service that "houses" the resource being called.

BPMSs (not just Lombardi's, but all of them) don't actually house the interfaces to external services, but rather hold pointers to those services. These are held as metadata inside the process definition. For example, the service endpoint address URI is stored, but not the WSDL. Therefore, the [XACML-based] security implemented under the covers of the web service operates independent of the BPMS [or any other client]. However, in most advanced organizations it relies on the SAML (or other) assertion of who you are and what context (application) you are running within. This is why it's the SAML implementation that forms the basis for security in the BPMS world.

James reflected on this in a subsequent post, and in that post he raised a few more questions... so let's continue the conversation...

1) When the BPMS is the service provider (not the consumer)

James says "the rationale for storing policies centrally is more than just one product needing to be its own enforcer. In an integrated world where a BPM engine needs to talk with an ECM engine, the need for these two to have the same access control policies is important."

Yep, I agree. I didn't make reference to it in my post, but of course for any services you expose from a BPMS (or ECM, or ERP or other platform) you should be able to author them so that the centrally defined policies govern who has access to that service. I suspect that all BPMS allow for this.

2) User interfaces, security policies and the BPMS

James says "It is good to see that XACML checks are done to protect web services but they may also be leveraged by UI components as well as access enforcement may require displaying or not displaying a particular feature/function."

Having UI's call the central policy server for presentation-layer rules on what aspects of a UI to show would be an interesting thing to debate. I'm not sure I'd agree with that as a good mechanism. It would be better for the presentation to drive itself based on the types of data that were presented to it (in the same way that device-dependent presentations are derived). That is, you don't want the presentation layer figuring out the security because that assumes the presentation layer has access to everything to begin with. So I guess I would take issue with the premise.

If, however, you want to drive your presentation-layer in this manner, you probably also want the presentation layer up and outside the BPMS. So while in Lombardi's BPMS (Teamworks) you can author UIs, we also give you the ability to easily plug in your own UIs for particular steps in the process. This would be the mechanism to separate the UI from the process definition, and also allow you to drive the particular UI from centrally-defined policies.

3) On BPMSs storing their own users

James says "I think many would agree that a BPM engine should store processes not users."

Yes, I agree. At Lombardi, you don't have to manage users in our store, if you manage them elsewhere (like LDAP or AD). I would say, though, that in the real world we've found that there are attributes you want to use in a process-context that aren't present in your corporate systems. These may be user attributes (like skill level for a particular job) or they may be role-related (a person's relationships to others change depending on the process context).

So in Teamworks, you have the ability to not only use the central user store, but, if you desire, you can also extend the attributes for a user (or role) without mastering that user... sort of a hybrid system. Again, if you manage the attributes centrally then the BPMS will pick them up. It's a matter of choice, and, to some degree, practicality.

We also think this "relationship" issue is bigger than LDAP and AD. Of course, matrix'd organizations have existed for a long time, and these basically reflect that my relationship to people around me change depending on context. For example, the CIO of Company X reports to the CEO of Company X for operational issues, but may also report to the CIO of ParentCompany Y for other things (like use of standard technologies).

As companies begin to measure more of themselves using process as the normalization, then these numbers of "matrix organizations" expands. So we think that organization modeling is part and parcel of the larger BPM discussion... and that these models will integrate with [LDAP or AD], but provide more extensive information. This is an area that I think will really change and expand in the coming decade, as the convergence of increasing security along with increased decentralization of computing resources gets mainstream emphasis.

Conclusion

Securing distributed systems has been long overlooked due to real-world needs to get technology out the door. But this aspect of enterprise architecture is critical to successfully embracing not just distributed technologies like BPMSs, but also important so-called social computing platforms like wiki's. Without good guidelines and well thought out policies, companies just won't embrace these critical technologies. And as a big company, it is critical you be able to embrace these because your smaller competitors are, and they are stealing your most profitable customer and product segments.

Thanks, James, for a good forum to have this conversation.

Technorati Tags: James McGovern, Security, SOA

In his recent post, Neil Ward-Dutton talks about how WebMethods customers are doing traditional application development under the guise of Business Process Management. Folks, automating a business process is NOT business process management! Sandy Kemsley says "these customers are coming from the traditional EAI-type usage of webMethods." Yep. And, in summary, Neil says:

"Understand what, exactly, you want to do with BPM. Understand the key characteristics of the processes you're trying to improve, and equally importantly, who's driving the work—is it business people, IT people or both?

"Unfortunately, getting to the bottom of things is not as simple as saying 'I need a human-centric BPMS" or "I need an integration-centric BPMS'."

Neil, you've hit the nail on the head! And, indirectly, you raised the key difference between what used to be called "the pure-play vendors" (like my company, Lombardi) and the "stack vendors" (IBM, BEA, Tibco, WebMethods). I prefer to use the terms "new-BPM" and "old-AppDev" to describe the vendors, but however you slice it, the new-BPM tooling is directly targeted at enabling new levels of participation of business people alongside IT people in the solution scoping and development processes.

As you point out, that difference has nothing to do with "human-centric," "document-centric," or "integration-centric" but whether the user is approaching use of the BPMS as a new developer tool (with, for example, the semantics of BPEL), or as a way to change the way business and IT interact during solution development. This developer-centric vs. business-centric approach is the key difference in deciding what tools you will be successful with.

Our experience is that if a company uses a BPM tool in the same old way (IT application development owning all aspects of the project and the business expected to deliver a set of detailed requirements at the outset of the project) then the project will fail exactly as often as any traditional waterfall application development effort. Which is fairly often.

But if the customer wants to move to a new model for those processes owned by the business, with the business contributing people full-time to the solution development effort, then the new BPMS tools are effective at increasing success rates, lowering costs, and delivering better solutions. The new BPMS tooling by the focused BPM vendors is better at this, far better, than any of the tooling the stack vendors provide. The old-AppDev vendors provide tools for their target market... and that is not business people with moderate technical skills. In contrast, the new-BPM vendors are focused on providing tools for a new solution development model, one that promises increased participation by the business, while retaining full-control for IT.

Technorati Tags: BPM, WebMethods

I was hiking today up above Portland, Oregon at the Multnomah Falls. Spectacular. Except my damn knees. I started thinking about how I hear people say "gee, I wish I was <fill in younger age here> again" and I have to say I really don't want to go back to most of my younger ages but it sure would be nice to have younger knees. I saw 18 year olds running down the 600 foot drop of a trail. I want their knees. Well like Rummy said "you don't go to battle with the army you want, you go with the army you have."

Oddly, this got me to thinking about business process management and about how almost everyone (except Lombardi, of course) has got it wrong. Most people think business process management is about Process. Wrong. Business process management is about people. Specifically, it is about making people more productive. People of diverse skills. People put in positions they might not be quite ready for. People retiring from their jobs. People starting their careers. Dear reader, if you are in a company with more than, say, 1,000 people, I wonder how many of those people do you think are perfectly suited to their jobs right now? How many have the perfect levels of skills, abilities, training and wisdom to do their jobs at peak efficiency right now? How many in your workgroup fit this description? I'm guessing you have people with different levels, some achieving the perfect blend you need, and some not.

Look, the point isn't that your organization needs help. In fact, the point is that your organization looks a lot like everyone else in this respect! Business process management should be thought of as a way to help teams work better. The team you have is the team you have, in many respects. You can't take the perfect team into the battle of competition tomorrow! You have to get a lot of the job done with the team you have. You might top-grade over time, and you might also lose some of your best people to promotions and their own career changes. The fact is, the people in your business have very different combinations of "perfection" at any given point in time. And in this globalized world, the question senior management asks is "how can I be most effective with what I have?" (A recent NY Times article quoted HP CEO Mark Hurd: "C.E.O.’s work on three things: strategy, operating models and people." Which, loosely translated I think means: what strategies can we pull off given our people, processes and customers?")

If workflow is the means by which we define behaviors, then the real advance of business process management is that it is the means by which we normalize how we measure behaviors and correlate those behaviors with the business results we achieve. Let me say it again: business process management is about how we measure people and correlate their activities with the business results they achieve.

In fact, practiced purely, I'd argue that it has nothing to do with how something gets done, only how well it gets done! It is today's evolutionary state of the most advanced de-centralized management capability. And by the way, if you don't get a grip on this issue - how to decentralize control of behavior while retaining insight into results - you will be run over by the people and technologies of the 21st century. Wiki's, blogs, SaaS word processors, SaaS spreadsheets, IM, Facebook (or Open Social) computing platforms... this all means you will have less control over the specific workflows, and more creativity than you ever thought possible. Your BPM initiative better be figuring out how you can deal with this... because these are becoming parts of the best processes in the world.

BPM helps you get a handle on the chaos that is real life, makes it explicit, and helps you manage around it. It does this by making the work explicit, linking that work to the reasons you are doing the work, and providing insight into the results. We call this trace-ability and it's key to doing business in the 21st century. It allows you to take the army you've got, and make them as effective as possible in executing against the strategy you've set.

As for me, there's direct traceability from the hike to my aching knees... time to take an Advil.

Technorati Tags: 21st Century Process, BPM