"I tell you captain, if you look in the maps of the worlds, I warrant you shall find in the comparisons between Macedon and Monmouth, that the situations, look you, is both alike. There is a river in Macedon, and there is also moreover a river at Monmouth."

- Fluellen, in Shakespeare's Henry V, explaining that his hometown Monmouth, Wales, is very similar indeed to the classical kingdom of Macedonia

Last night I had a dream that Fluellen said: "Pegasystems has training. Oracle has a BPMS. And IBM has Blueworks. I warrant you shall find in comparison of these situations with Lombardi, look you, is all alike."

The Welsh do make me laugh, and I did, I woke up laughing.

Normally, I use this blog to talk about industry issues and try to not so much flog Lombardi-specific products as deal with universal issues. But not today. Today is the culmination of hundreds of man years of effort and understanding here at Lombardi. Today marks the end of what I call "the first decade of BPM" and sets the industry on what I think is going to be an all-new course, or more accurately, a much broader and valuable course. And so out of pride, but also because I think that the BPM industry shifted today, I want to write about Lombardi.

Today Lombardi announced major advances in all three areas that determine success or failure in BPM:

• The need to communicate - you have to make business improvement personal
• The need to automate - you have to drive productivity and re-use
• The need for talent - you need to be able to assess risk, plan, and lead

Forget about simplistic approaches to driving transformational change based solely on whether your BPMS (or "BPP" or "PAAS") has a given feature. The so-called "Business Process Platform" as a sole-sourced technological salvation is a hoax. It's a solipsistic approach by technologists to once again say "if I have a better tool, I won't be as big a fool." Go on, stare at your image in the water and try to pawn all this off on simply another development tool or architecture. Instead, you need to take to heart what Toby Redshaw, CIO of Aviva, said a couple of weeks ago (paraphrasing here): If you're in IT and not doing BPM, three years from now you won't have a job.

He wasn't talking about a tool. He was talking about change and changing everything: how we relate IT to the business, how we use tools, and how we manage, nay, lead, change in our businesses through the use of BPM tools and methods.

Today Lombardi re-defined what a BPM platform needs to be; three specific vehicles:

Blueprint (Spring '09): The place your people should go for business improvement conversations. Using a unique approach of combining structured process (BPA) tooling with Facebook-style social networking and wiki documentation, Blueprint helps guide personal conversations about "how I think I can do my job better" into the scalable discovery of practical business improvements. Blueprint puts BPM on every desktop. Some of our customers have made this commitment and are in the process of training thousands of users. Yes, thousands. Want to knock down some walls in your company? Put Blueprint on every desktop and lead people (by example) to make suggestions about their jobs, their tasks, their activities. Even if you're not ready for the automation part of BPM, Blueprint will help you discover your processes, and then improve them. BPM isn't just about "modeling" and "BPMN" or "rules." It's about changing a culture, about embedding technology into the fabric of how we do things. We can learn from social media how to do this. This isn't your daddy's enterprise software, because it isn't 1983 anymore (or 1977, or 1896).

Teamworks 7: What's new about BPM-style process application development? It's the model, stupid. And so why is all the management of models and their internal assets built on top of traditional, decades-old-school-text-based source control systems? Using models, the application development goes faster, but then when you save a version of the model and try to manage it (both at design-time and at run-time), our competitors use traditional notions, or incomplete representations of the model (they might, for example, restore the rule that existed at some point in time, but not the UI's or the integrations).

Teamworks 7 answers this question with a completely new way to manage process models for their entire life - from the beginning of time. We looked at every use case along the entire process application life-cycle and we solved every problem that BPM-style development threw at us. Let's take a simple example. BPM demands iterative development. So what happens at the end of every sprint in agile? You know what happens: you tell people to "stop development for 24 hours" to stabilize the system, to make sure it's going to work. With Teamworks 7 you simply create a snapshot of the working version, then you keep developing, and when it's time for the Playback, with one click you go Back In Time to the Playback version (while all the other developers are still working on the tip), and you play it back. Zero lost productivity, entire model-universe reversion. One click. Back In Time is the biggest advance in iterative/agile development tooling since the method was developed. And you can quote me.

But that's just the beginning of Teamworks 7's repository model management. Dependency management is a problem that is solved, finally, with Teamworks 7. This is the best way to manage dependencies in any SOA development environment. Ever.  Because of this, Teamworks 7 also enables re-use to an extent never before realized. Re-use is the lynchpin of the BPM value prop. And the barrier to real-world re-use of technology assets isn't knowing they exist, it's knowing you won't get screwed by upgrades to those processes/services if they change. With Teamworks 7, you won't get screwed from service or rule re-use. Ever. And yes, you can quote me on that.

Lombardi University: OK, so you have people talking to one another. And you have a platform that truly enables the end-to-end business process application life-cycle. Now what? "How do I sell BPM to the business?" "Where do I find qualified people?" "What skills do I need?" "My infrastructure is maintained in a different group, and they are difficult to deal with!" Although BPM is (relatively) new, it isn't about all-new skills, and it's not about building an empire or creating an "other" part of the organization to deal with BPM. This is about adding the unique aspects of BPM-style development and management to each of your peoples' CV's. Sure, all vendors do staff-augmentation with experts, but there's also skills-augmentation. And frankly, this is what we are hearing our customers and partners want. "I have good people who can (build apps) (lead projects) (maintain infrastructure) but this is a bit different. Teach my people. Help me (or my partner) become self-sufficient in a scalable way."

With Lombardi University, there is now a roles-based way to augment your peoples' and your partners' skills. Roles-based is the key. This isn't simply education on the speeds and feeds of a tool.

And with Lombardi University certification, you can also measure the attainment of those skills and your own maturity as an organization. Have you deployed five process applications? How many people can you rely on to maintain that infrastructure? How do you assess the risk you are assuming? How do you talk about a 1, 2 or 3 year roadmap of skills development? With Lombardi University, there is now a way to do just that.

And not only that, I've talked with CIOs around the world and their #1 talent concern is this: how should I lead my BPM initiative? Who should do that? What does that person look like? Well now, for the first time, there's BPM Executive Leadership courses. We're launching two at the outset. These courses don't teach modeling and products, they teach how BPM is different from other programs - and how it is the same - and gives concrete guidance on how to lead your BPM effort, so that it doesn't become an "other" - that it is mainstreamed into the programatic fiber of your company.

By the way, we can't do all this by ourselves. So we've embraced technology from Saba to help you manage your talent development programs, they're the leader in career development software (in fact, your HR group might use Saba... if so, we can mash it all up and you can manage your BPM careers along with the rest of your career development efforts).

We've also engaged outside faculty. Industry experts like Bruce Silver will be delivering courses available through our catalog. Some of them use Lombardi tooling, some don't. The issue is education, not brainwashing. If you succeed with our help, we'll do fine. Derek Miers and his BPM Focus group will be teaching Lombardi University courses. Same with Dr. John Alden, 30 years with Accenture, co-founder of Terraquest. And Andrew Spanyi, author of probably my favorite BPM book, BPM is a Team Sport. This isn't altruism that we're practicing here, it's about your success. If we assist in that, we'll figure the money bits out. So Lombardi University is attracting the best BPM faculty in the world (if you want to be a part of our Extended Faculty, let me know).

Together, these 3 pillars - communication, automation and leadership - combine to form the basis for the platform for BPM's second decade. Lombardi is that platform. You don't have to do it all at once. Like all journeys, BPM is something best tackled one step at a time. Ping us for more information. I promise that if you do, you won't confuse us with Pegasystems, Oracle or IBM, or any other Monmouth of BPM...

Another reply to Bruce on this whole BPDM/BPMN debate. Yes, Bruce, I think this issue has very little to do with XML, BPDM or BPMN. I think this issue strikes to the heart of the matter: BPM is disruptive. Powerful, entrenched, legacy vendors don't like disruption. BPDM and the concepts inside BPDM are the most transformative of anything the BPM technology industry has seen so far. This is a chess game that's being played, not checkers...

Bruce,

No matter how you spin it, IBM/SAP/Oracle interests are offering up a new XML representation limited to, basically, what BPMN did four years ago. Why is that, Bruce? Why are we debating "how best to stand still" instead of "how can we get all this brainpower from IBM, SAP, Oracle, Lombardi, Mega, etc." together to extend BPMN to cover all the great business power in BPDM? Instead, IBM/SAP/Oracle are spending their time making sure the BPMN spec stands still, so that we're all, as Tom Waits put it, "waiting until yesterday is here."

I've come to the conclusion that this shift in power of process application development inside end-user companies is such a major change that the vested interests of IBM/SAP/Oracle will fight it. This is a change on par with what happened in the '80's as we moved to desktop computing. It's not some big conspiracy theory I'm advocating... it's just business. BPM is about changing the way business runs, using model-driven technology as the prime enabler of this change, and integrating real business people into a radically different software development life-cycle. Vendors who have billions of dollars invested and at stake have no interest in disruptive changes to the SDLC. They have an interest in the status quo.

Most of the elements of BPDM that are so "hard" are, in fact, elements that have always been planned for notation in future BPMN versions, like choreography. These have been discussed for BPMN since the BPMI.org days! So why is there so much push-back? Why aren't we having a very different debate? For example, it would be more interesting to me if the question was "how can we accelerate the choreography concepts of BPDM into the BPMN notation?"

But we're not having that debate. We're not using these 18 months (that's how long BPMN 2.0 will take, start to finish) to push the notation radically forward. We've got a lot of smart people arguing over a metamodel - again! We're wasting time - again! Why not leverage work that's been done (BPDM) instead of wasting time proposing yet another metamodel?

Those of us "on the BPDM side" want to change how businesses are modeled. We want to move business modeling forward. Why would we spend 18 months doing what can be done today perfectly well with BPMN and XPDL. If IBM/SAP/Oracle are really serious about easy-to-use serialization, then why don't they simply do this: release your BPMN tools today and have them serialize using XPDL. You can do that today. It's easy. I'll put this link in so their developers can easily find it. If IBM/SAP/Oracle adopted this serialization mechanism, it would be the standard, no question.

Instead they're stealing time... trying to get us to wait until yesterday gets here.

The power move is to embrace the concepts in the BPDM specification, and design a more powerful notation for them, while also embracing all the existing elements of BPMN. That's a notation worthy of our best efforts.

Whether we bite off the complexity of BPDM today, or in the future, we will have to bite it off. It's not the mechanics of BPDM that are scaring IBM/SAP/Oracle, it's the concepts. And those concepts - powerful business concepts - will prevail, it's just a matter of time. I'd prefer to accelerate the change, they'd prefer to slow time down, to wait until yesterday comes.

But don't be fooled as to the issue: this isn't about XML, it's about strategy. It's about BPM.

Phil

I'm taking a break from my governance blogs for a post to respond to Bruce Silver, who wrote this piece to register his objections to the use of BPDM.



Bruce,



There's several points you make in the post, but I'd like to take exception to a couple of them: (1) that BPDM took over BPMN and (2) that simplicity is a strategy.

 For a long time now the goal has been to get BPMN to include an explicit metamodel and serialization mechanism. All the groups inside the OMG agree on this, and it was a joint decision to use the BPMN 2.0 spec to do this. On the latter point, the simplicity argument coming from some, shall we say simple-minded, vendors isn't a strategy, it's a tactic to divert attention from their real strategy, which is to kill BPM.

You say that Conrad "picks up the defense" of BPDM. But BPDM doesn't need defending. What needs explanation is why we are where we are.

BPDM vs. BPMN


First I'll address your implication that "the BPDM people simply announced as a fact that BPDM would be renamed BPMN." This isn't correct. In fact, the head of the BPMN group, Stephen White of IBM, has been part and parcel of the long-term vision that BPMN 2.0 would include the serialization mechanism and was part of the name change. This wasn't done by "the BPDM people" but, rather, by the larger group within OMG (called BMI) that runs the spec processes for both BPDM and BPMN. IBM and SAP both play a major role in the BMI group, and were part of the consensus that (a) one spec was better than two, and (b) BPMN was the better spec to move forward with. The reason for the name change isn't sinister. Here's 
the thinking:

1. Most everyone in the "post-BPDM" world wants the notation spec to include an explicit metamodel and serialization format, so that these diagrams can be interoperable.
2. The notation spec has the more widely known and adopted "brand" (BPMN).

3. The BPMN and BPDM teams both agreed that we could and should live with BPMN.

4. The chairman of the main BPMN group has been (and is) Stephen White of IBM. Within OMG it's acknowledged that Steve "owns" BPMN. So if anything, the concept of an OMG-based BPMN serialization - something that until now is only contemplated in the BPDM spec - was pulled in by the BPMN group.

The BPDM group has always been willing to let the separate BPDM spec go by the wayside if the BPMN metamodel is explicit, powerful and, like all OMG models, MOF-based.


In summary, most everyone at OMG wants a more mature BPMN spec, one that includes an explicit metamodel and serialization, and we all think BPMN is the right mechanism for that consolidation.



MOF-based BPMN vs. simple XML-based BPMN


So we are all aligned that BPMN should be serializable using a standard format. The debate is now centered on "what should that format be"? This is a legitimate question and, like anything, both sides have valid points to be made. There is not a "right" answer. As a person who believes that direct manipulation of XML is not a desired end-user requirement, I've never bought the argument that BPDM "is too hard... too complex." Vendors add value by taking powerful abstract objects (like a file format) and making tooling that allows easy manipulation of those things. And so I think the best way forward is the one offering the most reasonable chance for robustness and future-proofing (ie. the standard will live a long time, making my investment as a vendor pay off).

Software vendors don't make technology decisions based on how easy something is. We make decisions based on corporate strategy. In this case, watch out for the simple-minded vendors who claim they are for "a simpler" file format. Most likely they are simply for a format that doesn't threaten their vested interest.

At Lombardi, we've already announced our strategy: we're in the BPM industry for keeps. We will support BPMN 2.0 in whatever form it takes. Period. We prefer the BPDM metamodel and serialization, but will work with any adopted standard, because this is good for the industry. It would be nice to hear other major vendors make the same commitment.



Some vendors, though, will tell you that "the MOF-based XMI of BPDM is 'too hard,'" implying, I guess, that they won't support BPMN 2.0 if it contains BPDM. These same vendors have hundreds, even thousands, of developers building complex BPM platforms. They have messaging platforms and/or complex materials masters and logistics algorithms. But BPDM is too hard? Come on. This isn't a complexity issue, it's a control issue. It's a business strategy issue.

Powerful elements of major companies were against BPMN itself to begin with. By acquiring BPMN, and then seeing it massively adopted, OMG changed their world. It's only been in the last 12 months or so that some major stack vendors and application vendors have announced support for BPMN.

And then, when OMG approved BPDM, once again their world was challenged. All the sudden, a legitimate, useful, long-term alternative to technology-based diagramming (like UML) was a reality. Business-facing diagramming... with power? Big problem.

There is no question that the power of BPDM - the explicit aspect of it that you are worried about - was a key contributor to the movement of some of these vendors into a "hey we better beef up BPMN with a simple serialization" mode. Could it be that they recognize that crippling the power of an alternative model to UML might be in their strategic interest?

I don't know everyone's motives in this discussion, but I do know the following:

1. Powerful non-user interests have been aligned against an explicit non-UML metamodel for BPMN - and voted against BPDM, killing it the first time around.
2. At the same time, these same people proposed a MOF-based UML metamodel for BPMN, and would have been happy with that. This would not have been "simple," it simply would have been strategically aligned with their interests.
   
3. Once BPDM was on the brink of adoption these interests all the sudden started talking about how BPMN serialization isn't a bad thing, but this BPDM thing is just too hard... we need a simple, non-abstract metamodel.
   
4. Once BPDM was passed, the simple-minded vendors all the sudden got religion and started preaching this "simplicity."
   

So as you consider the state of the world in July 2008 and look at the tooling around MOF manipulation (which, as you say, is limited), also consider what we in the true BPM industry (as opposed to the same-old same-old tools for technologists industry) are trying to do. This is a paradigm that is changing the guard in enterprise computing and will define how companies compute for the next 30-40 years. We need to move beyond simple 1990's XML, and into something more extensible, more powerful. This will inevitably upend the power inside end-user companies, and upset traditional buying/selling relationships.

The struggle for BPDM is in some part struggle for account control.

I choose power over simplicity. I don't trust those who have entrenched, vested interests to watch out for me. In fact, what would truly be a shame is if the powerful interests trying to hobble BPMN succeed by inserting a more XPDL-like rendering of the model, which they would like to do because this would not have the power of other OMG modeling standards, like UML. Hmm....

Phil

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

Just a quick note to give you this link to a blog post on Google's site where we talk about the development of our Lombardi Blueprint product. That product represents a real leap in capability in terms of process mapping, documentation and modeling... the ease of use and business value it provides is pretty cool. And it really couldn't have been done as efficiently without Google's "Google Widget Toolkit" (GWT). So the blog post is on the GWT blog. Since the post went up, a ton of developers looking at using GWT have hit the Blueprint site, and we're really pleased and proud to be the poster child for this AJAX-y technology... which we hope (obviously) becomes somewhat of a standard.

Alex Moffat, the lead engineer on the Blueprint product line, wrote the post and I like how he sums up the business goals for the product:

The challenge handed to us was to create a tool that the average business user could use to document and manage their business processes. It had to be easy to use, encourage collaboration between team members, and provide a shared repository for all of a company's process documentation. Workflow functionality had to be on par with our competitors: Microsoft Visio, IDS Scheer's ARIS, IBM's WebSphere Business Modeler, and other desktop modeling tools. But we also wanted wiki & shared whiteboard capabilities to store information. Editing should use the drag and drop interaction users of desktop apps are familiar with. We ended up with some additional features that really set us apart:

• An intuitive map view as a high level visualization of a process

• Automatic workflow diagram generation

• PowerPoint generation for easily presenting the process

• Online chat functionality

I think this shows how achieving business goals is more and more becoming inextricably linked to the technology addressing those goals. This application simply could not have been developed even five years ago, without an investment 20-50x of today's cost... which obviously means that the economics wouldn't support it. As it is, Blueprint is licensed at the ridiculously low price of FREE for the Personal Edition, and only $50 per month for the team account!

We're doing the same thing with the more traditional behind-the-firewall BPMS integration platforms, today. They are getting simpler to use and this is changing the game of what types of enterprise process applications can be built because they are changing the game on who can build them!

Business Process Management is about knocking down the traditional development skills while retaining the important, traditional development patterns. Blueprint is one aspect of this, and traditional BPMS's, like our own Teamworks, is another angle of attack.

Business process management is not about one or two simple, specific things. It is about the pervasive shift of responsibility over all process-related elements (documentation, compliance, execution, improvement) from IT to the line of business. We're happy to be pushing the envelope on how we deliver all this capability. And thanks again to Google for creating a great framework for us to leverage.

Again, here's the link to the blog post Lombardi Blueprint, Built With GWT.

Technorati Tags: Google, Microsoft, Lombardi Blueprint, Visio, WebSphere

Only in the tech world could we be in June passionately arguing about "top down" and "bottom up" and not be in a convertible drving up PCH to Zuma with a cooler full of Pacificas and limes in the trunk. Well, to return to the summers of your youth and live the dream of BPM, now's the time to download this 8-track podcast., set aside Danielle Steele and for the next 22 minutes listen to ebizQ's Gian Tratta interview me about why and how to implement top-down BPM strategy.

"Our view is that business process management is a business function and it is something that should be pervasive to your organization. If you're really going to start viewing your company through the prism of process, this requires top-down commitment."

I know that's pretty steamy but if you can handle it, there's more where that came from. Enjoy...

Technorati Tags: Blueprint, Gian Trotta, ebizQ

Nathaniel Palmer wrote a review of Lombardi's Blueprint that I thought was interesting. So after my conversation on "Enterprise 2.0" with Sandy Kemsley a couple of days ago I thought I'd go back to that.

You see, I agree with Nathaniel's assessment that platform-level BPM-SaaS   (or any other integration-intensive platform) is a non-starter (for the relevant future, anyway).  Like any new technology (for purposes of this discussion, let's assume "SaaS" is new and that it's a technology, both of which are bad assumptions but that's another discussion) it will be mis-used by existing players and only new ideas will bring out its primary benefits.  Remember the move by the mainline DOS players to Windows?  They all died because they viewed this new thing as just a re-swizzling of their old thing... when in fact a new design approach was required.

So if you want to look at the BPM market I think there are 3 or 4 "buckets" that a process platform addresses.

- Modeling
- Execution
- Monitoring
- Reporting

I suspect we could quibble at the edges but generally that's what there is to this thing.  Each of us vendors make implementation choices that we can debate, but the functional buckets are pretty much those four. Let's take a look at what's required for each of those, and where new technology or services could make a difference:

Modeling doesn't require integration and it benefits from collaboration.  Now, there are advanced use cases where integration into and introspection of existing systems will help build scenarios for simulation, but in general, the bulk of the work done in the front-end of the modeling life-cycle looks like an OK fit for something delivered over the web. SaaS is not simply about a scalable way to deliver functionality, it facilitates collaboration if you tap into that part of it. The web allows people to get together to do their human-based work. If the tool you are providing also is easier than competing alternatives, structures data and puts in an accessible place and can hand it to you in a standardized format, then SaaS gives you a very scalable way to deliver this capability. That's where salesforce.com excels: doing something that was already being done but in a better way. In addition to that, if there are new concepts in this tool, then even better. At Lombardi, we think Blueprint is both easier to use than modeling alternatives (like salesforce.com) but also we think there are some new ideas (like integration with our behind-the-firewall BPMS). Easy access at the beginning, and tightly-coupled standards-based round-tripping when you move to execution.

Execution is different.  The aspect of BPM process execution that I find most interesting is the execution that is done to make existing alternatives more flexible.  BPM isn't a rip-and-replace thing where you should be building a new application. In fact, a BPM system should host as little system-of-record data as possible (other than the intrinsic SOR data that execution and monitoring spins off, process analytical data about the process performance... which I think is the most interesting aspect of BPMS-based execution!) If you aren't integrating to legacy systems, then all you're really doing is building a workflow application. Been there, done that, more silos, more support headaches for IT. That's not the process problem for the Global 3000. These companies have significant dollars invested in their systems and now those systems are holding them back.  They can't dump them, their whole business depends on them.   At the same time, these big systems just can't be changed fast enough.   SOA alone isn't the answer, because the problem is not that the system-to-system transactions aren't working... it's the patchwork quilt of systems and humans that want to work together in new ways that aren't able to move fast enough. So service-enabling legacy systems as a part of a larger SOA is a Good Thing, but it's a Good Thing so that you can consume them in the new human-facing processes unified across the new business initiatives. BPM (and SOA) is a part of that.  A BPM layer can be inserted and extended... it is more flexible for new things, and it masks the old thing while making the whole process seamless across the multiple systems.  Well, anyway, the point of all this is that integration of the process platform into your business BPM is heavy, heavy lifting.   If it's not heavy lifting (the low hanging fruit of unintegrated workflows) then all you have is a portal, a form and a workflow engine... you're not doing BPM. Unintegrated workflow applications using SaaS? Sure. Core-process BPM execution? Nope, not well suited to SaaS. (Of course, you could see a path from modeling to unintegrated prototype - one that "executed" - and then a transfer into a behind-the-firewall platform, but to me that's just modeling, so I'd put that up above...)

Monitoring.  This part of BPM gets very interesting and sometimes not well understood.  Not only should BPM offer up technologies that are agile, but BPM is the conduit through which we make business decisioning more agile.  In fact, my experience (from many years pre- and post-BPM) is that being able to make informed business decisions is the longest pole in the tent of agility.  And having good information is getting more difficult because of the morass of systems and silos (Ex-hell, as a customer calls one popular spreadsheet silo...).  So monitoring complements execution and is equally important to execution for almost any process of consequence.   You probably won't execute all of a core business process, but you will have to monitor key parts of it to provide the process-oriented "perspective" to management so they can know when, where, what, who and why of improvement.  The reason is simple: any core process will already have some systems in place to support it. They may not be great (hence the need for BPM) but they will exist, resulting in more integrations, therefore not a candidate for SaaS (again, in the relevant future).

Reporting.    The results of execution and monitoring need to be visualized.  I think interesting Saas-based work may be done here around real-time collaboration and real-time data visualization.  This is an area where a lot of vendors will be tempted to simply put their BI tools into SaaS.    That won't do much in the market.  But there is opportunity here, I think, to use the SaaS platform for something very interesting... the integrations required for reporting databases are so standardized these days - and the performance of modern data warehouses is so good - that some of the technical hurdles that we talk about in the execution and monitoring sections, above, don't exist (although the political hurdles of data access still do).  I am watching this space for interesting developments, though... things like what businesses (like IBM) are doing in Second Life fall into this category, for me. In addition, I certainly would consider a future where a product like, say, Blueprint, might want to visualize the execution artifacts of a product like TeamWorks. Now wouldn't that be Enterprise 2.0'ish!

Well, those are my thoughts on when and where SaaS innovations may play a role in BPM in the next couple of years, and also on how Enterprise 2.0 (so-called) might transpire. Enterprise 2.0 is, to me, about the merging of the public and private delivery platforms accessible by a person in their worklife. By merging these platforms and leveraging each one to its fullest, we can do a better job of delivering the right stuff to the right person at the right time at the right cost. Enterprise 2.0 isn't Web 2.0 because the relative importance of "me" is reduced. As someone pointed out in Sandy's conference the other day, "this isn't communism, we have to think about corporate profit." And as I pointed out, it's also not about anarchy. It's about looking across the landscape of the enterprise and using every technical asset at our disposal, and leveraging it to the fullest. Where BPM comes into play is that it directs the order in which you create this leverage. It is the basis for understanding your business. If you marry these two ideas, BPM directing the Enterprise 2.0 leverage, then you'll be more quickly on your way to closing the gap between your PE multiple and Google's!

Technorati Tags: Enterprise 2.0, IBM, Sandy Kemsley, Nathaniel Palmer

I just got off an eBizQ panel discussion hosted by Sandy Kemsley. What a ball.. no slides, just good, topical conversation. Speaking of the conversation....

The panel also consisted of Phil Larson of Appian, Ismael Ghalimi of Intalio. The topic was "BPM and Enterprise 2.0" and we discussed, among other things, what the technologies of (so-called) Web 2.0 meant to the enterprise. A lot of people are looking for a fundamental shift in the BPM world, but I don't think they get it at all. Of course these technologies will make a difference in enterprise applications and mission critical processes, but I don't think that's their initial highest and best use.

Process execution (aka workflow) is not the interesting part of BPM and therefore, process execution from "Web 2.0-like" tools isn't the most interesting use of these new capabilities. Not to get all Cluetrain on you, but the main thing these new technologies give us is a new way to communicate, not a new way to integrate!

Behind-the-firewall BPM is about giving visibility into your core processes, and giving you a more flexible way to implement improvements to those processes. Visibility and improvement are non-trivial things. They require thoughtful implementations (not "zero-code" implementations) and they require top-down guidance. If you don't have leadership at the very top of the tree behind you, then you just aren't doing BPM. But how do you structure that top-down view? How do those leaders tie process to high level goals - the goals that if you hit them you'll still be in business and thriving in five years' time? How do you quickly decompose those processes that make strategic impact and determine which ones have the highest impact? And, finally, how do you know when to hand off those decomposed process "chunks" into a robust behind-the-firewall BPMS that offers a shared model with the higher level views as well as the hard core capabilities of an enterprise class platform?

What I've found over and over is that there's no good way to have the top-down conversation! And it turns out that this is exactly what the new SaaS technologies allow!

So my answer to the "what is Enterprise 2.0 and how does it tie to BPM" question? Here you go:

The key stumbling block to real BPM has been the inability to have a structured, high-bandwidth conversation from the top-down about what the goals of the company are and the related processes that impact those goals. Enterprise 2.0 enables that conversation with new tooling that combines the best of social software with a shared process model accessible to and from the behind-the-firewall implementation BPMS.

Enterprise 2.0 is here, but it's not a regurgitation of the old execution-centered (workflow-centered) BPMS's of the past. It's an extension of the process execution and control systems into new areas of the enterprise, enabling new conversations, that dramatically alter the process life-cycle within a company. And then it's the tight coupling of the internet-based capabilities with the behind-the-firewall capabilities so that a new, more flexible breed of enterprise systems evolve.

Agility comes from being able to respond to strategic changes quickly, not the ability to change a random workflow. Enterprise 2.0 enables this - but not by recycling concepts of execution and web services. We're entering a new era, we're not going back to the '80's... this isn't client-server, and it's not just another set of Excel or Access craziness. It's about empowering the individual but in directed ways that (a) contribute to the company's success and (b) utilize scarce resources to their fullest.

Technorati Tags: 21st Century Process, BPM 2.0, Enterprise 2.0, Web 2.0

Much is made about how BPM is “going to change the way businesses are run” by having “the business” become involved in the development, optimization and evolution of these process applications. This is a cause for consternation by experienced technologists who are [understandably] worried about having the business “run amok” with programming tools. There are enough shoddy applications that contribute to IT’s maintenance nightmare; we don’t need more of them, we need fewer. Maybe, then, “don’t let the business harm the business” should be included in the hypocratic oath of BPM.

On the other hand, the business is clamoring for tools. Tools to help them take control of their own business processes. Tools to help them emerge from under the “iron boot” of unresponsive IT departments. Tools to let them be productive in groups - like Microsoft Office has allowed them to be productive individually. Prospects tell me that “our customers are making demands on us - we have to move faster! We know technology can help us, but it takes so long to do anything, we question its value.”

So here's the dilemma: on one hand, IT needs to be more agile to respond to the marketplace at a faster pace than ever, and on the other hand, much of the clumsiness is a result of "just doing something" which resulted in all these silo'd systems (and people, too).

It's the irony of our times that the very systems that have allowed business to scale have become so complex they are the obstacle to scaling further, faster.

How do we get the power of people doing business in agile, de-centralized ways, baked into our technology? Or, stated differently, how do we embed technology so deeply into the business, that business programmers can take over without doing harm to themselves?

What can we agree on?

First, let’s find some common ground. To do this, I’d like to look, say, 30 years into the future and propose that:

• Business people will be smarter about technology than they are today.
• Tools will be easier-to-use than they are today.

I don’t think those are too controversial. That's certainly been true over the past 30 years. If you agree, then you'd probably also agree that at any point along that "30-year path", there are incremental improvements.

People getting smarter: It's difficult to plan for the increased savviness of the work force, but it happens. It's usually the result of fundamental shifts in technology. Whether it's the Walkman or the web, everyday people get smarter about using technology in their daily lives. And while we can't really affect the timing of this, technical literacy rises over time and it is what it is (or will be). So let's simply assume a line that depicts the rising technical capabilities of line-of-business people over time.

Tools getting easier: As to the second assertion – that tools will be easier-to-use – hopefully we can agree that the state of these tools is going to get a lot better. Bill Joy, in his famous speech to The Commonwealth Club a few years ago, pointed out that the difference in energy between a matchhead and an atomic bomb is about 10**12 and that with the advance of hardware and software technology, that’s about the power differential of personal computing between 2000 and 2030. The impact this will have on user experience and accessibility will be staggering. By then, we'll be negotiating contracts via Second (or Third or Fourth) Life, directly with our customer's avatar and the result of the negotiation will be represented in the process model, a contract will be generated, triggers based on the agreed SLAs will be established and a choreography will be instantiated. And you won't have to know a damn thing about "process"...

So tools get much easier to use, over time, as this chart shows:

This trend started with the first personal computers and VisiCalc, through to today's Microsoft Excel and Google Spreadsheets; from WordPerfect to Microsoft Word 2007. Today's business is "programmed" by end users in ways largely unimagined 30 years ago. This steady advance in usability will continue, unabated.

This trend is now moving from personal productivity applications to enterprise applications, and will continue until the very business is “programmed” by business people, so that the business’s processes – like today’s documents – are directly manipulated by them. It is simply a matter of time. Is it 30 years? 10 years? How much will the line move over, say, the next 36 months?

Business Programming will occur. Lombardi’s mission is to accelerate that capability for our customers. If you believe that pushing the levers of agility closer and closer to its users (the business), then every advance in tools accelerates the benefits that result from business programming, as the charts below show.

There is a role for IT

Of course, there is and will forever be a role for technologists – people inside the organization who focus on the hard bits of technology. In the same way that increasing computer power enables ease-of-use, so it will also enable complexity (and evil, according to Bill Joy, but that's for another post...).

The pace of change of networking technology will continue to increase and, for large organizations, there will be an inherent advantage to having technologists on the leading edge. Technology - in whatever form - will be a competitive differentiator for many companies, at those edges where innovation is occurring.

At the same time, more configurable technology will be used by a wider audience. Look, for example, at cell phones. They are easier to use than ever, and more people use them, but there’s a lot of technologists at phone companies keeping the dial tone on. What we’ve done with cell phones is push out the “business use” of the infrastructure to simple devices at the edge of the network – and hidden the complexity of the network from the user of those simple devices. Those simple devices aren't only doing simplistic things, they are just simple to operate, and operate with very evolved interfaces into the core network which, at, say, Sprint vs. Cingular is different, and people with special technical skills and experience are required by each of those companies.

I was at one customer recently who has an investment in their core systems which measures in the 10's, if not 100's, of billions of dollars. That infrastructure isn't going away in my lifetime! Yet, their need for agility and the ability to compete using those systems - indeed, leveraging those systems as assets and not liabilities - is the key to profiting in this century.

Hiding this complexity, enabling process control and visibility, and working in partnership to foster change is the issue. And in order to do this, it's going to take all the technical and business expertise available, focused on the important problems in your company. If there's competency in the business, let's grab it!

What does this mean?

So in order to facilitate the move to business programming, BPM technologies need to strongly evolve in the following areas:

• Business Strategy: Massively easier-to-access tooling, and easier-to-use UIs for business users, to get started quicker, without IT involvement, and specific easy-to-understand ways to collaborate on "final mile" issues that require IT.
• Collaboration: Embrace the highly collaborative post-internet world, beyond simplistic ECM and into wiki’s; beyond simple, structured ad hoc routing and into sharing; beyond over the web and on the desktop to an access anywhere, anytime, well beyond the connected-only world of Web 2.0, and into the mobile world we live in.
• Modeling: A more expansive view of modeling the business, not simply modeling a process. Mixing modeling with process execution to a degree not seen before, recognizing that “simulation” and “historical data” must be mixed in order to truly model an organization; and moving models well beyond process diagramming and into living entities that are on a par with running processes… because modeling the business is a real-time, production effort and the asset – visibility – is more important than the assets of, say, ERP.
• Governance & Behavior: Better tracking of governance (maturity) and behavioral (motivation) models so that the enterprise competency of BPM can be grown, made visible, and incented.
• Infrastructure: Hardening the vertical communication touch points, but not the paths. Ways to control the interfaces into the legacy network must be provided so that business people can easily discover previously-used data, and also facilitate the collaboration between business and IT when new data requirements exist.

"If you aren't first, you're last"

BPM is the technology for these times because it's the only enterprise technology that embraces the technological "perfect storm" you are competing in: the convergence of highly distributable technologies, a highly connected world, and a new majority of users in the business who are capable and eager proto-technologists. And because it does it in a connected, heterogeneous way instead of being "rip and replace," it's a technology you can actually use from large business to small!

So next time you think about BPM, think for a moment about these trends and about what you want to enable over the next few years at your company. Business programming is coming, and like Ricky Bobby said, "If you aren't first, you're last." Whatever that means.

Technorati Tags: 21st Century Process