BPM, George Washington & The Dignity Code

I'm on my third startup and I've discovered three differentiators between winners and losers: focus, sustained execution & culture. The same can be said about any new initiative, I guess. Lots of companies have gone "six sigma" yet few are really great at it. Saying "everyone is a green belt" does not a culture make.

The same is true for BPM.

So what is "culture"? How do you instantiate it? Can you do this in a repeatable, sustainable way, or is it simply the result of random evangelism by high priests. In a nutshell: how do you develop, scale and then maintain a culture?

I've been struggling with that question ever since it became apparent that culture is the single biggest impediment to moving from a "BPM project to program." There's little doubt that BPM is simply one milestone on the longer arc which is the movement of technology into the business, as business people regain control of their information. But it's a big milestone. There is as much cultural change required to do BPM at scale as there was to move to desktop computing at scale. This isn't an IT choice of, say, "BPMS vs. Ruby-on-rails."

It is BPM vs. business-as-usual.

I'm reminded of the time when the COO of a "top 10" law firm told me that "lawyers will never be typists." That was in 1990. Of course, by 2000, every lawyer was "a typist." Cultures changed, as did the economics of law firms. Firms either led or followed the move to desktop computing, but in the end everyone adapted. And the leaders thrived.

The same is now true for BPM.

Business economics are changing, and BPM can be either a catalyst or a response; an offensive weapon or a defensive one. You can lead or you can follow.

But in order to lead you must accelerate the culture required to adapt and adopt. Today's business culture, from top to bottom, is resistant to much of what BPM preaches. We pretend to champion:

• Incremental, continuous improvement   
• Structured change
• Re-use

Instead, despite our rhetoric, the actions of people in company after company show that:

• We prefer to "boil the ocean" and fix everything at once (often taking the subtle form of: "automating a bad process just means you still have a bad process")
• We really prefer doing things our own way and letting others do things their own way
• And we truly believe our way is better, as opposed to some common way

We are BPM hypocrites.

In yesterday's New York Times, David Brooks wrote an insightful column about dignity (and the loss thereof) in the public sphere. He wrote about how as a young man George Washington, who would become the US's first president, wrote down "110 Rules of Civility & Decent Behavior," and then applied those rules to his own daily life. Brooks calls these rules "the dignity code."

"[A]s the biographer Richard Brookhiser has noted, these rules, which Washington derived from a 16th-century guidebook, were not just etiquette tips. They were designed to improve inner morals by shaping the outward man. Washington took them very seriously. He worked hard to follow them. Throughout his life, he remained acutely conscious of his own rectitude.

In so doing, he turned himself into a new kind of hero. He wasn’t primarily a military hero or a political hero. As the historian Gordon Wood has written, 'Washington became a great man and was acclaimed as a classical hero because of the way he conducted himself during times of temptation.'"

I love that idea, that "inner morals" might be "shaped by the outward man." Of course, religious and other ritualistic frameworks have existed for this same reason for centuries.

Brooks touched on this same topic last week in The Conversation, a New York Times online weekly discussion he has with Gail Collins. They were chatting about whether hypocrisy in public figures is a relevant issue. He wrote:

"I suppose it all comes down to whether you believe good character is constructed through culture and artifice, as I do, or whether you think people are naturally good and that social conventions are warping and destructive."

Character as a result of "artifice." Does BPM have an artifice, a dignity code that we can look to in times of stress?

We will all, at times, be hypocrites... we won't always do the "BPM-appropriate" thing, but we need to try. We need those rules of BPM Etiquette and Decent Behavior, so that we can objectively assess our progress.  Without them, it is simply too easy to avoid "walking the talk." We will continue to give lip service to "agility" and "continuous improvement" and "change as fast as the business" but we won't. Not really.

We need a BPM dignity code.

July 8, 2009 at 05:59 PM | Permalink | Comments (0) | TrackBack (0)

When Process Is Your Product

Last week I met with the senior leadership of several of the top Indian systems integrators and outsourcers. The week not only confirmed my suspicion that these firms are becoming the strategic partners of the Global 2000, replacing the stack vendors and SAP in that role, but also shed new light on why this move might have even greater implications to the businesses they serve than even they realize.

To put it bluntly, a great outsourcer may be better at quickly improving your business than you are. Why is this? Because, these companies are quickly achieving the cultural maturity required for BPM that eludes even the most progressive companies in the world.

Companies have realized that moving from a few successful BPM projects to a scalable BPM program is difficult. Where the 80/20 of BPM projects is 80% go smoothly, the 80% of programs face difficulty. McKinsey has recent research on why this is and it argues persuasively that cultural factors are the single biggest contributor. It is hard to change a corporate culture, and business improvement programs require change to occur at every level, on every desktop.

If change is so hard, then why is it moving faster at outsourcers than at beleaguered companies? I think it is because process is their product.

Previously I've written about how outsourcing has, in the past, led to even worse process, giving the illusion of business improvement due to labor arbitrage-induced savings. But two strategic trends are forcing process improvement today... even on India. First, labor costs are normalizing with the West. They're still lower than the US and Western Europe, but not by as much as they were. And second, even lower cost countries are now competing for the BPO wallet. So the top integrators and outsourcers must achieve qualtiative process outcomes that the lowest cost providers can't achieve.

That is: the Indian outsourcing firms must drive real performance improvement into the processes they run in order to compete, achieving both efficiency and effectiveness; and they are committing to those outcomes contractually in order to win business.

In my meetings in India, I was told that the typical outsourcing deal now requires significant cost reduction every year, for increased volumes of work. Further, these deals typically are moving more and more to process outcomes (SLA's, KPI's) being measured every year, and substantial improvements in those metrics over the life of the contract. And finally, they tell me that in years one and two, much of the savings is in labor arbitrage, but that in the out years (most deals are in the 5 year range), substantive, non-linear changes are required, which force qualitative process improvements be found by the outsourcer in order to make a profit.

In a nutshell, they have to do BPM in order to do BPO. And because the process is their product they have to instill a culture of BPM in order to stay in business! Very few end user organizations have this compelling of an event. Most companies still view their product as Widget X; for the outsourcers, Widget X is the process!

This acquisition of culture is key to the strategic influence the outsourcers can gain. This isn't just about labor arbitrage, but about the willingness of the outsourcers to deliver better outcomes across the board. Instilling this culture, through acquisition or organic growth is key to scaling business improvement in general, and process improvement specifically. Could outsourcing be the fastest way to go? It may or may not be, for you. But it is true that this is the x factor that is driving business (and IT) strategy today, making the culture-carriers, the BPO's and integrators, the strategic partners for the Global 2000.

So this leads me to the final questions: today, you may think of your SI as a means to bring cost reduction and consistency to your IT processes, and your BPO partner as bringing the same to your business processes. But what if you could simply augment your business people in order to graft the culture of change? Is this a new value prop for the Indian companies? Does it accelerate your business outcomes while preserving other aspects of your company's culture in better ways than simply outsourcing everyone?

More and more companies are beginning to understand that business is change and when that's the case, process becomes your product. The Indian outsourcers could be the Toyota of white collar process understanding, and they could hold the key for business improvement ideas, like Toyota's lean production methods.

June 28, 2009 at 01:12 PM | Permalink | Comments (0) | TrackBack (0)

Tata Consultancy Services - Lombardi Insurance Solutions Lab

Earlier in June, I went to India to meet with our partner, Tata Consultancy Services, to dedicate our new TCS-Lombardi Insurance Solutions Lab in Bangalore. Not only does this reflect the strategic nature of our partnership with TCS, it also gave me the opportunity to meet with the leaders of many of the top Indian SI/BPO companies. I'll be blogging a bit about those meetings.

The Lab is staffed full time with TCS people and is the place where insurance solutions and frameworks are being built. TCS also announced the certification of hundreds of their people via the Lombardi University certification program, and was a launch partner for the University.

We're proud to be a key partner inside the TCS ecosystem.

June 27, 2009 at 02:31 PM | Permalink | Comments (0) | TrackBack (0)

BPM: Bigger than SOA

I think most people would agree that BPM is bigger than SOA, in fact, SOA is simply the technology architecture that defines how any technology is designed and deployed. BPM, on the other hand, represents how you link business strategy to business implementation... with [SOA-based] technology being a part of that implementation.

Well, now there's independent confirmation that BPM is, indeed, bigger than SOA - or at least twice as much BPM information is being searched. Google's Keyword Tool shows that in May, the phrase "business process management" was used almost twice as many times as "service oriented architecture", with a higher Adword value. (Too bad we don't compete in the "consolidate student loan" space...)

I doubt if IBM or any of the other SOA stackers are in jeopardy of being bought by Lombardi any time soon, but at least with Lombardi you know you're getting more bang for the buck. Twice as much value, in fact...

June 26, 2009 at 11:50 AM | Permalink | Comments (0)

The Platform For BPM's Second Decade

"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...

May 12, 2009 at 09:01 PM | Permalink | Comments (1) | TrackBack (0)

Bridging the Gap

March 10, 2009 at 05:35 PM | Permalink | Comments (1)

Flashlights, Not Bailouts

This appeared originally as an Op-Ed on CIO.com.

Blue collar workers aren't killing Detroit, white collar workers are. And since the entire service economy is built on white collar work, what happened in Detroit over the past thirty years and happened to banks in the last 10, will happen to everything else in the next three.

In fact, everything in the American economy is driven by service economy workers (“white collar workers”). But the model upon which this economy is built is broken. It is based on the unscalable heroics of artisan workers, who largely work outside the limelight. In the worst cases, they work outside any light at all. To prevent another industry meltdown, business leaders need a set of white-collar principles based on the bedrock of visibility.

As Congress deliberates over a historic bailout of the Big 3 car manufacturers everyone has become an expert on what needs to change. According to one opinion in the Wall Street Journal the problems start with the big, bad unions and stop only if you can "gut" them. According to the Beltway folks, we’re in this mess because the car manufacturers didn't produce enough hybrids or, in the vernacular, they "didn't build the cars America wanted."

Neither of these gets it right.

One of the three (Ford) is in demonstrably better shape than the other two, and it's no mystery why. Two years ago, when he took the reins of Ford, Alan Mulally identified two things that needed to change: parts costs have to go down, and engineering productivity must go up.

Get it? The white collar workers who design the cars have to move from artisan to engineer, and they need to work together across all the company's platforms to use common parts.

While cutting healthcare benefits and union concessions might help conserve another month or two of cash, neither would address the causal differences between old school manufacturers and those from a new school focused on white collar efficiency and cross-process visibility.

But this type of change doesn't come on the cheap. It requires imagination and determination. Imagination to re-think the details of what we do and how it’s measured. Determination to take on the entrenched interests inside our companies and drive change right down to the desktop of every white collar worker. So far, these failures haven't only resulted in the Big 3 crisis, and all the related manufacturing meltdowns over the last 30 years, they’ve also caused the mess on Wall Street.

In Michael Lewis' terrific article on portfolio.com, “The End Of Wall Street's Boom,” he highlights the two key drivers of the banking meltdown. First was the huge, unseen risk of leverage in the new financial products that were being developed. Second, in the article's money quote, John Gutfreund , the former Solomon CEO, reflected on the role of CEOs across all of today's megabanks. He said "I didn't understand all the product lines, and they don't either." Lewis writes "the Wall Street C.E.O. [has] no real ability to keep track of the frantic innovation occurring inside his firm."

CEOs and everyone below them must have a common understanding and visibility into the processes needed to establish new efficiencies. As an example, it’s rumored that Toyota’s engineers spend more than half their time “doing engineering.” In Detroit, it’s half that. And as Lewis points out, few people anywhere knew that a single mortgage was leveraged up to 10x through the various CDOs and credit swaps.

In both of these seemingly diverse industries, decisions about parts, risks and returns are made in the vacuum of virtually unchecked darkness. In companies today there's no direct linkage between the tasks your people are doing and the goals of the organization.

This isn’t a lack of automation, it’s a lack of visibility. Regardless of industry, the world’s largest companies are houses of cards, built on darkness and risk.

This should scare the hell out of us.

Ironically, the off-shoring, which was the first response to the symptoms of the artisan-economy-on-steroids, served to increase risk and darkness even as it hid behind the allure of cost savings.

Because the growth in the service workforce was not easily scalable (costs went up in a linear fashion as heads were added), CEOs found it easier to fire local workers and hire distant ones who were paid a fraction of their U.S. counterparts. These executives took the easy way out, often-times they actually added headcount to an already-unwieldy process and boasted about their “savings.”

So now our U.S. companies are in increased peril: white collar tasks are more opaque than ever, while customer and product risks are on the rise.

Today, leading edge companies across the manufacturing and services spectrum are working on new ways to reduce risk, and increase visibility. The technical bits are fairly easy, but the cultural change needed inside the white collar parts of the organization are massive.

There needs to be a revolution in implementation of processes that bring greater visibility and less risk to all aspects of our businesses. It is no longer acceptable that senior management remain ignorant of the goings-on at even the deepest depths of the organization.

Technology can play a key role in providing this linkage and visibility. But before this can help, we need leadership at the top that doesn't fail to imagine and is determined to make their people work differently. This isn’t about taking on the popular bogeymen of the past. It’s about fundamentally changing our culture and our capabilities.

The old manufacturing and service economies can be saved, but they both need to be rebuilt upon the bedrock of visibility.

We need a new service-enabled economy that lowers business risks, lowers business costs and increases the number of local jobs.

But it requires imagination and determination from the very top of the tree. It requires driving change throughout the upper, middle and bottom of the white collar parts of your organization.

January 29, 2009 at 01:01 PM | Permalink | Comments (1) | TrackBack (0)

Waiting Until Yesterday Is Here

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

July 15, 2008 at 12:38 PM | Permalink | Comments (0) | TrackBack (0)

Take the Challenge: Support BPMN 2.0

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.

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

July 14, 2008 at 04:30 PM | Permalink | Comments (1) | TrackBack (0)

The Five Charters of BPM Governance

BPM is just different. In the past, projects with IT software dependencies were funded as a single line item and had a single, defined set of requirements in the form of "speeds and feeds," the functions required by the application. When you deployed the application, and trained the users over some period of time on a static, unchanging application, you were pretty much done.

• A "network" of bottom-up process application implementations
• Directed, top-down strategy driving the implementation roadmap
  
• A primary mental model of time-boxed deliverables vs. feature-based deliverables
• Many iterations (versions) of each process application
• Ability to adopt these iterations in the business (changing application plus an increasing user community)
• High re-use of process application components
• Constant business-user involvement in the development process
• Constant business-user involvement in the deployment process

The Elements of New Governance

1. Establish how this new type of platform is shared; who can play in the BPM sandbox
2. Provide visibility into the metrics the BPM projects are supposed to attain, and their success; provide structured guidance on the alignment of a given project to the program's chartered goals; alignment of bottom-up process projects
   
3. Provide a scalable mechanism to generate and gain approval on business cases for BPM projects; define financial and other requirements for entry of a project into the program
   
4. Provide a defined way that BPM projects get on the interface roadmap for access to core systems; define interface maturity requirements that align with BPM project requirements
   
5. Define the way shared BPM infrastructure will be maintained and how that cost will be allocated to the various processes under management
   

• What projects are included in the BPM initiative
• Who is going to run these projects
• How projects are to be approved
• How labors will be shared
  
• How projects will be measured
• How projects fit into the overarching BPM goals
• How your competency will be achieved company-wide

1. Charter for BPM Platform Sharing
2. Charter for BPM Democracy
3. Charter for BPM Project Budgeting & Transparency
4. Charter for BPM "Conflict Situations"
5. Charter for BPM Platform Investment

Over the course of the next five blog posts, I'll discuss each of these. Subsequently, I'll be making these Charters available under a Creative Commons license. I'll also be establishing a web site where the community can alter and improve upon the skeleton documents I'll set up. I don't have any pre-conceived notions of how all this should be implemented. I only know that we need to implement this framework, and the more quickly we do it the better. Companies around the world are struggling in moving from BPM projects toward scalable BPM programs. But there's few signposts along the way, and even fewer companies who have actually achieved the vision, at scale.

A Brief Description of the Five Charters

Charter for BPM Platform Sharing

Too often today the people or small team who did the first BPM project are now the "keepers of the flame" so to speak. These people become gatekeepers; whether they wish to be or not isn't the point, they are gated by their own organizational influence and limited resources. Further, in companies of any size, these teams generally aren't the teams that have the most visibility into the business. By the very nature that these teams bit off on a fairly leading edge technology, or at a minimum they were first-users of a new technology, they probably are not in the best situation to capitalize on their successes to build a scalable organization.

How the BPM platform is shared among projects, and how the roadmap of projects is determined, needs to be bigger than the individual(s) who has had a success or two. It needs to be institutionalized.

Further, because the roadmap of BPM is fundamentally top-down, but the implementation very bottom-up, new steering committees of cross-functional business leaders need to be created, independent of the bottom-up skills that might be located in, say, a Center of Excellence. In fact, a CoE should be one of the tactical results of having a Charter for BPM Platform Sharing, and only one. A CoE is a tactical implementation mechanism, not a strategic body. This Charter lays out the principles for sharing the platform, and the bodies responsible for ensuring strategic alignment of the BPM projects, and the roadmap for BPM.

Charter for BPM Democracy

Everyone's a part of BPM if you do it at scale. And guess what, BPM is not BPMS. Like any enterprise technology, the "orchestration engine" has only a relatively minor part to play in the life of all the business users. To do BPM at scale, you need to bring your company's culture along. This requires a commitment to improving communication about process improvement, process inefficiency, change management and many other non-tool things. To create this culture, you need a commitment to open dialog- free speech and non-government-owned TV! - throughout your organization.

BPM is a programmatic approach to making every white collar worker in your company twice as productive. It is much bigger than orchestration of tasks. Communication, cross-process understanding and a culture of process-centric innovation are the tactics of BPM, along with the automation of process. Defining that mission is the work of the Charter for BPM Democracy.

Charter for BPM Project Budgeting & Transparency

Budgeting for BPM projects is quite different than normal software projects. It needs to cover a time period of multiple releases, for example. Budgeting also requires non-cash items, like the contribution of key people from the business on to the process projects.

Project chartering also requires new transparency into the in-process measures that give you the forward visibility that you want. This forward visibility - understanding every process like a sales pipeline - that gives you the most agility, even more than the real-time changes that can be made to the tooling.

This Charter makes clear those requirements and provides for a forum for understanding metrics across business silo's.

Charter for BPM "Conflict Situations"

BPM doesn't live in a greenfield silo divorced from the 40 years of propagated systems that is your company. How do these co-exist? How does BPM "drive" your SOA initiatives (or does it at all)? How do you align BPM roadmaps that deal in weeks with system renewal and consolidation efforts that legitimately deal in quarters and years? We need to establish a mental model of how these efforts align with one another. This Charter documents the requirements for aligning roadmaps and providing specific mechanisms for the timely and cost-effective achievement of all technology roadmaps: BPM, renewal and consolidation.

Charter for BPM Platform Investment

Is BPM a shared service? Do you allocate the costs based on the number of process applications you think you will build over three years? Or just this year? And how do you allocate the maintenance of the platform across multiple process applications. By number of users? A fixed fee for each? What about license costs?

And how do we maintain our infrastructure? What about upgrades? And what happens if an upgrade to the infrastructure affects one of the existing BPM process applications? Who pays?

This Charter provides a framework for maintaining the infrastructure, knowing that up-to-date infrastructure is the best thing you can do to keep technology evergreen, but also provides a framework for how the cost will be fairly shared.

Next - A detailed discussion of the Charter for BPM Platform Sharing

A Note on My Inspiration for the Five Charters
In his book, The Bottom Billion: Why The Poorest Countries Are Failing And What Can Be Done About It , Paul Collier, a Professor of Economics at Oxford, lays out the five governing documents he believes are required to set up an effective government. They are:

1. Charter for natural resource revenues
2. Charter for democracy: free speech, TV, radio
3. Charter for budget transparency: top down, bottom up, peer review - ex ante, ex post
4. Charter for post-conflict situations; standards for after rollout?
5. Charter for investment

I read these after I saw Dr. Collier speak at TED in the Spring. I had been thinking about BPM governance for some time, and most specifically since last December, but the specifics of what were needed hadn't crystallized until I saw Collier speak, and then read the book.

For those of you interested in the state of our world and the potential for the emergence from poverty of many of the world's people, read this book. It's the most insightful new book I've read about the world we live in since The Pentagon's New Map.

June 22, 2008 at 09:41 PM | Permalink | Comments (1) | TrackBack (0)