|
|
It's not hard to find someone who will rail against outsourcing, and often it's an IT person who is upset about the outsourcing of IT jobs to India or somewhere else. But the fact of the matter is that Western business outsourced itself long before the rise of India and other manufacturing and engineering centers. Ironically, the rise to power of that IT person is a result of this outsourcing.
It started about 45 years ago when business people began abrogating responsibility for their business information, and outsourced control of their processes and information to IT. It's led directly to the inability of business people today to think about their processes in a structured way and further, an inability to change those processes in controlled, scalable ways. Sure, business people do change... but almost all change today is via ad hoc changes carried via Excel, email and folk lore. And all the while, the business simply yells at IT to "fix my problem, faster, you idiots."
But the problem isn't solely IT's; the business has to acknowledge culpability. Mr./Ms. Business Exec: Who do you have specifically allocated to understand the totality of the processes, the data and the technologies that support your processes? Probably nobody. Or, more likely, someone in IT.
Six Sigma initiatives are not an answer. I'm not talking about measurers and abstractionists, I'm talking about people who are in there, shoulder-to-shoulder with every stakeholder, who have operational responsibility to understand, own and improve the processes.
This month's signature Harvard Business Review article discusses the manufacturing drain in America, and why it is so important to keep it. Not simply because the ability to produce is a Good Thing, but more importantly: product innovation requires the ability to understand the specifics of implementation. Similarly, business innovation requires the ability to understand the specifics of implementation!
That's because in most of these industries product and process innovation are intertwined. So the decline of manufacturing in a region sets off a chain reaction. Once manufacturing is outsourced, process-engineering expertise can't be maintained, since it depends on daily interactions with manufacturing. Without process-engineering capabilities, companies find it increasingly difficult to conduct advanced research on next-generation process technologies. Without the ability to develop such new processes, they find they can no longer develop new products. In the long term, then, an economy that lacks an infrastructure for advanced process engineering and manufacturing will lose its ability to innovate.
In reality, there are relatively few high-tech industries where the manufacturing process is not a factor in developing new - especially, radically new - products.
Gary P. Pisano and Willy C. Shih; Restoring American Competitiveness; Harvard Business Review (July - August 2009)
Read that first bit again: "Product and process innovation are intertwined..." The business is in large part defined by the processes of the business, so business people have to regain control of every aspect of the process, including the technology. I am not saying business people have to learn how to deploy applications... I am saying that you can no longer abrogate your responsibility for the details of what gets deployed. You can no longer hide behind the apron strings of Microsoft Word or some Visio drawing.
The only way to really get this detailed operational knowledge is to participate concretely in the development and operations of the process applications.
This single notion is what gives BPM its power. Everything else, from Business Process Analysis to Six Sigma to Microsoft Word requirements documents are simply delaying tactics, abstractions that don't really convey the specifics in meaningful ways, because they are not directly tied to the implemented process in a structured, traceable manner.
Today one of our customers said they were told by IBM: "why spend your money with Lombardi, we'll give you our BPMS for free." I finally agree 100% with IBM on something: their BPMS is worth nothing. Getting a cheap BPMS is like buying a dancing elephant for a dollar: cool, but who can afford to feed it?
But this notion of getting "free" or highly-discounted software from strategic vendors has currency. How many times has your company picked up some crap from some vendor because it's on a discount schedule and you have to buy x amount of software each year to "maintain your discount." So let's discuss the cost of software, and the value of software.
Software has no intrinsic value. Nobody buys software for its own sake; it's not like a Howard Finster painting. Software's value is derived solely from the productivity it provides. It has extrinsic value.
Take the iPhone and the Blackberry. I switched from the BB a year or so ago, and found that while my email productivity has gone down on the iPhone, productivity in all other areas (web browsing, attachment reading, etc.) has gone up. So which is "better" depends on the outcomes I'm optimizing for. For me, my overall productivity on the iPhone is better than my overall productivity on the BB. I don't go back to the BB just because it costs less (which it does), because the cell phone is a tool, its value isn't intrinsic, it's extrinsic: the "cost" of the device is a combination of my own time and performance using it together with the money I pay directly for it.
Stated simply: even a "free" Blackberry would cost me a lot more than an iPhone.
The same is true for your BPMS decision: the extrinsic value gained or lost will be much greater than the "savings" on the software. So be sure you understand what extrinsic value a good BPMS can provide, and then factor that against the "savings" of a cheap BPMS that won't provide those values.
The value props of a BPMS are pretty simple:
- Lower development costs vs. traditional tools
- Increased business performance vs. traditional tools
Reduced Development Costs
You will expend less effort to get a similar process application with a good BPMS vs. a cheap one. Requirements-gathering is easier because business people can participate directly with IT using the same tools. Therefore, the requirements can be explicitly stated and understood, instead of the usual ambiguity of Word documents and white boards; and because business and IT use the same tooling, the business can understand "the art of the possible" more quickly, leading to more productive discussions around scope and trade-offs.
You can't get this collaboration with a bunch of tarted-up Websphere tools available on the cheap.
Building a Better Process
The importance of having business SMEs working shoulder-to-shoulder with IT people on the process application isn't simply about changing the economics of application development, it also leads to better business outcomes. With direct engagement from model to implementation, business people are for the first time able to quickly discover linkages that would be buried or just not thought of. A hospital group in England recovers an additional £300,000 per month because a business person developing a patient process application realized how some patients were simply never being billed because of the way the underlying process worked. This would not have happened if the business person wasn't able to be in the details during the design and development of the process automation project.
The business involvement is not to make programmers of business people. It is to have them more intimately involved in the ownership of their processes and their information that is flowing through those processes. This level of detail is only understandable via the technology tooling. Therefore, the tooling has to be more broadly accessible or the whole value prop is blown.
Because Lombardi uses a shared model, instead of UML and BPEL and Java and God-knows-what-else, the business can understand at a detailed level exactly what it is able to get.
But don't just take my word for it. Talk to our customers, and then get references for those cheap tools (if you can find them). Be sure to ask them whether the applications they built were built using only the tools you were shown... or did they also have to deal with, say, an event handler, a message bus, maybe an analytics package for reports? What else wasn't "free" and, more important, what else was inaccessible to business users?
Ask about all those IBM BPMS references who started an application in January 2009, deployed it in April, and then changed it twice, in May and June. That's the kind of experience one of our insurance customers had, using Teamworks in an underwriting process. This, from an internal review just completed:
"So useful that [we] have already made the following list of changes during May and June as a result of using this scoreboard:
- Modified 7 rules
- Added 2 questions
- Modified 3 questions
- Added help text to 2 questions
- Created additional reference materials
[T]he product manager has already requested more data and more reports. This validates the benefits of having visibility to this data. This is precisely what any company needs right now, especially in this economy, visibility into their operations in order to ensure their viability."
Lower costs, faster turn-around, better visibility... a better business outcome because of Teamworks. All in one package, straightforwardly and fairly priced.
Or you can go for the "free" one and pay out the wazzoo.
"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:
- 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.
- The notation spec has the more widely known and adopted "brand" (BPMN).
- The BPMN and BPDM teams both agreed that we could and should live with BPMN.
- 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:
- 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.
- 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.
- 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.
- 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
|
Lijit Search
|
Subscribe