Archive for July, 2006
After I posted re the piling-on Assaf Arkin was taking on IT|Redux over insisting that BPMN belonged to BPEL, the man himself posted a thoughtful response on BPMS Watch. I was waist-deep in real work at the time and didn’t have time to think through an appropriate continuation of the thread, so I dashed off a quick response by email. That began an interesting out-of-band conversation that, if nothing else, narrowed the gap between the BPEL-si and BPEL-no positions, and shifted the debate from lofty analogies and name-calling to things reasonable people can at least discuss.
Even though I come off as the simpleton in the dialogue, I learned something about BPEL, so with his permission I reproduce it here. I haven’t caved, but I think I understand the question better now. I’m hoping as the issues become more concrete, others can move the conversation forward more constructively.
Assaf:
I want to correct a misconception. I don’t want to visually model BPEL, I happen to like BPMN much better for all the same reasons: higher level, simpler, more business like. I just want to make sure BPMN has an execution path. And I learned that hard way we can only do that by picking an execution language. I happen to prefer BPEL over XPDL.
I don’t believe in the “either BPMN or BPEL” dichotomy (i.e. you can’t do high level and get something to execute), but others apparently do — or for product reasons need to — and tried to turn my statement into a polar view point.
There’s two things BPMN without BPEL can’t do right. One is execution. If I can’t say “order-total > 500″ in the process, then having a quick approval path and one that requires extra checks doesn’t matter. Because without that rule, the process can’t decide which path to choose. It’s stuck. And BPMN has no way for expressing these rules. What you can’t express, you can’t port…
Portability is a good goal. Now, imagine an execution engine that does compensations very well. You design a process to get quick orders in, and allow customers to cancel. But if your execution engine doesn’t do compensation at all (or badly), you have two options. Write a lot of complex code to get around that. Or more likely, write a process that asks for second confirmation to make sure the cancellation rate is low…
How well your business works, and what it does, depends a lot on how it does those things. Implementation details do matter, and do make the difference between Amazon and Borders, Wal Mart and K-Mart. (Guess which has a better IT system?)
Assaf again:
There’s one view in the software world that says all dependencies are bad and we should abstract them away. There’s another one that’s willing to take some risks in order to get better results. I belong to the second one.
If you can build a great notation that’s independent on the execution language, then you might as well pick one existing language as serialization format. Because it wouldn’t matter. Let’s say we pick BPEL + visual notation extensions as serialization language. We solved one problem. Since the notation is independent, you use that to serialize (store, retrieve, exchange) your process models, but you can easily deploy XPDL or any other language, because the executables are all equivalent.
Dependency only happens when those execution languages are not equivalent, and so you end up designing your process based on the capabilities of the execution. All of a sudden, what you designed for BPEL doesn’t work the same way for XPDL. That’s a dependency problem.
And I don’t want to solve it…
CircuitCity has three different sales process. You can order on the Web items you’ll never find in the store (the Web shelf space is inifinite). You can order on the Web, and they have great Web discounts, and pick up at the store. Or you can buy at the store without discount. The Web discount reflects the cost of the “implementation detail”.
The abstraction camp would like to believe that every company can have a single order process that’s properly abstracted from implementation details. The dependency camp would like to make it easier to define several processes that are somewhat married to implementation details, but also tuned to those details to get better results.
Bruce:
I may be talking out of my hat, but from the work I’ve done with BPEL I would not recommend it as the serialization format. My biggest beef is how it handles data. Defining all variables as wsdl message types, all that bpws:getVariableData() etc. Yuk. Plus the whole idea that BPEL doesn’t update process variables, it just keeps copies of messages and endlessly maps them to each other… That’s fine for BPEL but many non-BPEL languages don’t work that way. So that’s the part I want abstracted away.
Assaf:
You’re right. BPEL 1.1 was designed to be an orchestration language, that’s why it acts as a poor man’s process language… Also, why Intalio could not ship a BPEL 1.1 engine to its customers, it just didn’t solve problems they had to deal with.
BPEL 2.0 is a different beast. Variables are now real variables, you can use elements, complex types, simple types. You can use variables to calculate, count ( e.g. the foreach activity), maintain lists and collections. getVariableData() is gone, in favor of the XPath syntax (one of the first issues I opened), XSLT support is built in the spec, XQuery is possible although not normalized in the spec due to release deadlines.
You can declare variables with initial values, configure those values at deployment (see latest SCA release). You can scope variables, validate their values against the schema. You can even send an element variable directly, instead of having to create a WSDL message to contain it.
It took a long time to get from 1.1 to 2.0, and there’s a reason for that, and it shows in the spec.
Now, I’m the last to say BPEL 2.0 is perfect. It’s not. But I can’t imagine any vendor or standard group trying to recreate the same specification from scratch and able to deliver something in a reasonable amount of time. Just dealing with data variables so they can meet real use cases without jumping through hoops, is a huge undertaking.
BPEL 1.1 was the lowest common denominator, BPEL 2.0 is not, so abstracting means losing all sort of interesting capabilities.
Bruce:
OK… but doesn’t it still replicate the variable under a new name every time it’s used? In BPMN, a variable (let’s call it that even though I think they call it something else) like “Customer” should be used throughout the model, not mapped to a different Customer variable name and namespace with every activity that uses it. Does BPEL 2.0 do that? All that Assign mapping should be under the covers, not in the BPMN, unless it’s “complex” in which BPMN should support a way to define it. I think XPath 2.0 is OK (but is that really a “standard”?)
Assaf:
Variables are mutable in BPEL 2.0, so you can keep using the same variable and just change its value.
Most XPath 1.0 libraries have been upgraded to do XPath 2.0, it’s not that hard, and products are being released with XPath 2.0 support, so it’s just a matter of getting through the normal release/upgrade/install cycle before everyone has it. XQuery is the more interesting alternative, but much further down the road.
Once you get down to details but don’t have assignments, how can you move a process definition from one tool to another?
It really makes a difference whether you’re basing a decision on quantity or price, whether you’re sending billing or shipping information to accounting. In fact, in some cases what you send is more interesting than who you send it to (you decide on the service to use based on the request you want fulfilled).
Bruce:
Of course BPMN needs a way to define gateway conditions, but better to do it “abstractly” than with namespaces and other trappings of BPEL. This inevitably leads back to the question of how much data modeling can/should be done by the “analyst” as opposed to “developer” (analyst being Ismael’s definition of someone who doesn’t know a while loop from a hula hoop)…
Assaf:
…If we have one modeling language with clear path to execution, you can start with the high level definition during project planning, then incrementally extend it until eventually you get something that software can manage. And deploy that. And from that level of details you can always extract a high level view of what’s currently happening in the business. If you get data from your servers, you can understand how it relates to your processes.
If you decide to use two modeling languages, you need to break the flow and switch at some point, so you end up with two different models. And they get out of sync, they don’t always have the same understanding, change is more complex, so change happens less often. We like to solve that problem with more agility. It’s not about teaching people how to program but making sure there’s good flow from your organizational decisions down to the flow of bits and bytes. As best as could be.
Bruce:
One more thing… You keep saying BPMN has no way to specify data expressions in things like gateway logic. I’m thinking that can’t be true, so I’m now looking at the BPMN 1.1 spec dated 7/31/2005.
On p 83 re data-based exclusive gateways: “The set of Gates for Data-Based Exclusive Decisions is based on the boolean expression contained in the ConditionExpression attribute of the outgoing Sequence Flow of the Gateway…. The conditions for the alternative Gates should be evaluated in a specific order. The first one that evaluates as TRUE will determine the Sequence Flow that will be taken.”
But then: “Note: BPMN does not specify the format of the expressions used in Gateways or any other BPMN element that uses expressions.” So it would be fairer to say BPMN should specify some standard expression language such as javascript or perhaps XPath. I think insisting on BPEL expressions is unnecessary.
Assaf:
[BPMN conditions are] nice for people, we understand what “all orders over 50 dollars” mean, but software doesn’t. So those expressions don’t buy you anything when you’re asking software to manage them.
Notice order of evaluation, that’s important for software, something you’ll need in BPEL. So by doing that, BPMN is going forward some of the way, but not all of the way.
BPEL specified XPath. That was the easy part.
Then went through months of work to fix a lot of issues that came up because people use different data formats, so there’s a lot of issues around context nodes, variable mapping, etc. Not to mention, in a process that can execute different activities in parallel, when can you access the data? What happens if the data is not there? What if you’re recovering from or compensating for failure?
Then through more months of work to make sure it also applies to XPath 2.0 and XQuery 1.0, so we can use those when the time comes.
So doing “BPEL” is actually doing XPath/XQuery and getting to benefit from all that work on resolving issues that arise when you use XPath in a process that may perform activities in parallel, could have repeating activities, synchronization barriers, failure conditions, etc.
Doing just XPath means having to spend additional research to figure out how XPath can be used in a process that may perform activities in parallel, could have repeating activities, ….
If BPMN can do that quickly and easily, I’m impressed, I’ll admit to being wrong and take back my arguments.
But meanwhile, I wonder where’s the value to justify re-inventing the wheel just so we can call it “rolling circle”, and are customers really asking to wait a few more years so the spec they receive does not leverage one that already exists today?
July 28th, 2006
Despite the inclusion of content management functionality in Gartner’s checklist of BPMS must-include components, most BPMS vendors cannot even spell ECM. The few that can — EMC Documentum, FileNet, Global 360, Pega, IBM — generally had an ECM business long before they got into BPM. I’ve been thinking about it more lately as I finish up my report on EMC’s Documentum Process Suite for the 2006 BPMS Report. And I see bits of it popping up lately in a variety of contexts:
- The Gilbane Group, normally the smartest guys in the room when it comes to ECM analysis, dipped their toe into the topic this week – not much more than admonishment to BPMS vendors to make their tools easy to use or some such profundity… but at least they’re beginning to talk about the intersection.
- Pega’s BPM VP Setrag Khoshafian, who wrote about the intersection in edoc, a magazine for ECM users, is promising some snazzy new ECM functionality in PegaRules Process Commander for October’s PegaWorld.
- Blogger Phil Ayres has latched on big-time to BPM’s need for ad hoc team collaboration, but was until recently unaware that it’s the ECM vendors with a BPMS — EMC, FileNet, G360 — that actually provide it today. Now he’s all over it.
I’ve written about this topic a lot in reports and white papers, generally in the context of the how these products put ECM and BPM together and the business value, but I haven’t blogged about it yet. I think that’s because my view of it is starting to change.
If you recall my discussion a week or so back with ILOG’s Alain Gendre re business rules — another of Gartner’s BPMS checklist items — he explained why rules belonged at the SOA layer, not in the BPMS or any one application system. A similar logic obviously applies to ECM. It should be a business service in the SOA layer. But in rules, just as in ECM, what you have in reality are partnership agreements between BPMS vendor A and rules/ECM vendor B, involving some bit of proprietary integration to glue the pieces together. In a perfect SOA world you wouldn’t need such agreements, but so far, in the real world, you still do.
The main reason is that ECM products that claim to be SOA mostly expose their services and events only to other pieces of that vendor’s own ECM/BPM suite. Better than what they had before, but obviously not enough. If those ECM offerings were packaged better as true enterprise services, the BPM-ECM intersection would be a lot easier. Besides exposing content operations as services, it’s important to publish content events in a standard way. A content event is a signal generated automatically in the ECM system whenever a document is added or updated in the repository, or its metadata is updated, or its lifecycle state promoted, etc. ECM vendors publish these events to their own BPMS, but not externally. But then again, if they provide their own BPMS, why would they want to?
July 28th, 2006
When you’re deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, BPEL 2.0. But he doesn’t really defend the assertion with arguments that the undecided can understand.
Today Ismael tries to bail him out, making the valid point that the only process definitions that are close to portable today are those based on BPEL. I would agree with that, and it’s why I’ve never been a “BPEL-hater”. But my own migration to the BPEL-doesn’t-matter camp has been based on the vision of a new higher-level design portability standard: BPMN. Now that may or may not be OMG’s view of what BPMN should be — Fred Cummins’ comments on Assaf’s original post lead me to think not — and I’ve already committed the heresy of saying if that is not included in OMG’s vision for BPMN, the BPMS vendors should just get together and create “BPMN-P” (portable) themselves.
So let’s get to the real point: What does design portability mean? Assaf’s version, which I interpret to mean that two “implementations” of the same diagram should result in the same BPEL 2.0, is too narrow. Let’s face it, each BPMS is going to have its own bells and whistles that “add value” on top of any standard. So the challenge is to draw a line — the portability threshold — separating semantics that must be standardized to conform with a reasonable process owner’s understanding of portability from value-add features that do not. Those value-add features may figure decisively in the process owner’s choice to go with BPMS A instead of X, Y, or Z. But portability also guarantees that if BPMS A turns out not to perform as advertised, another BPMS can be swapped in with relatively little redesign.
The BPMN 1.0 spec is silent on this issue, and it’s not clear that BPDM addresses it, either. To most vendors today, showing activities as rounded rectangles, splits and branches as diamond shapes, and swimlanes is enough to claim BPMN conformance. Yes, I agree that is ridiculous. I also agree that an intermediate event attached to an activity or subprocess boundary is a valuable design concept that should be preserved in BPMN-P… even though leading non-BPEL “BPMN-compliant” tools (e.g., Savvion, BEA) don’t support it today. But some do: Lombardi, Cordys… Compensation seems to be an important thing to Assaf, but the business requirement is very different for human-centric and straight-through processes, and fault and compensation handling is all over the map. Is compensation above or below the portability threshold? It’s worth having the discussion.
Right now the real debate is on hold while we wait to see what BPDM looks like. Unlike the BPEL TC, where issues and interim drafts are open for view, the BPDM process is completely opaque. I hear rumblings about September, so maybe we’ll know soon.
July 26th, 2006
If you’re new to BPM and want to better understand the technology, I’m doing an all-day tutorial session in DC (Reston VA, actually) on September 20, in parallel with the Brainstorm BPM/SOA Conference. The training is sponsored by BPM Institute and counts toward their BPM certification credential. Click here for more information.
July 21st, 2006
Assaf Arkin guest-posts an impassioned love-hate note to BPMN on IT|Redux. I admit I only understood about half of it, and I think you’d need to have stayed awake through many a BPEL TC conference call to get most of the references. His first core assumption - that BPMN’s deeper purpose is to provide process design portability, not just a drawing - is one I agree with (e.g. here and here and also here)… but it’s hard for me to accept his second one, which is that a BPMN independent of BPEL makes portability impossible, and we should just accept that BPMN’s purpose is to be the notation for BPEL.
Since he knows OMG won’t go this way anytime soon, he sort of hints/threatens to just build the reference implementation himself and provide it to Eclipse. I suppose if open source BPEL 2.0 wins in the marketplace (or even makes a strong showing), this would make Assaf’s BPMN metamodel the de facto real one, while OMG keeps fiddling with BPDM.
I lack the smarts to debate this with the likes of Assaf, but I question whether the ultimate test for BPMN should be the level of portability he demands, and in particular binding it to one particular interpretation of the BPEL 2.0 specification. He seems to be worried about subtleties in the interpretation of scopes and compensation, while much bigger problems revolve around things like human tasks and subprocesses, neither of which BPEL 2.0 even supports, and those crazy freeform BPMN looping and merge patterns, which BPEL doesn’t allow, either. I’m happy to junk the latter two, but a BPMN without human tasks or subprocesses isn’t really about business processes.
Obviously, perfect portability on a free commodity platform is not going to motivate leading middleware vendors to play ball, and I don’t even think it’s the right goal. A much bigger win for both Intalio and BPMN would be a 99%-portable notation that would provide the same basic execution semantics on both BPEL engines (IBM, Oracle, Intalio) and non-BPEL engines like Lombardi, BEA AquaLogic, Cordys, ones that at least support basic BPMN concepts like intermediate events. I agree BPMN needs to be tightened up to do it, and it probably needs to be done outside of the OMG process.
In my view, an engine-independent portable design notation that allows BPMS vendors to compete on runtime functionality would stimulate the market, not kill it. And users would benefit more from that in the end.
July 20th, 2006
Paul Harmon of BPTrends weighs in on a worthy topic, how many perspectives do we need to describe a business process? He acknowledges that while “alternative approaches” like Role Activity Diagrams or the Flores-Winograd interaction model used by Action Technologies are useful in special cases, most of the time it would be better to standardize on a more conventional workflow perspective such as BPMN or UML Activity Diagrams. Sandy Kemsley expresses her agreement, while Derek Miers (in comments on BPMS Watch) has expressed the opposite view.
I come down strongly on the side of Paul and Sandy, and in fact go farther to say it should be BPMN not UML Activity Diagrams, and in fact it should be an improved BPMN that resolves the inherent conflicts between an anything-goes drawing notation and a “modeling language” with precise execution (and analytical) semantics.
I hope Paul doesn’t mind that I’m using a diagram from his article to illustrate the problem.
Here is an example of what he calls a “high-level BPMN diagram of a supply chain.” Well, it’s certainly a diagram with rectangles and arrows, I’ll grant that, but is it really BPMN? In BPMN, arrows like that are called Sequence Flows and they mean that the activity (which could be a subprocess) at the arrow head starts when the activity at the arrow tail ends. You don’t have to be a supply chain expert (and I’m not) to know that’s not how it works. Source, Make, Deliver, and Return are all in fact running concurrently, although there is communication between them. And BPMN can describe that concurrency (get rid of the sequence flows), and even describe the communication (”choreography”) between them (put each subprocess in a “pool” and interconnect them with message flows).
If BPMN is going to win in the standards game, it has to become more of a design language and less of a cocktail napkin.
July 18th, 2006
InfoWorld just came out with a head-to-head eval of the two leading BRMS offerings, ILOG JRules and FairIsaac Blaze Advisor. To sum it up, Blaze slightly outpointed ILOG overall, with better benchmark performance and documentation, while ILOG rated higher in rule management and developer tools. The new version of Blaze is speedier than the old largely through the implementation of a new RETE algorithm resulting from FairIsaac’s acquisition of RulesPower last year.
Motivated by Gartner’s insistence that a BPMS must “include” business rule management as a ticket to entry to the magic quadrant, BPMS vendors over the past couple years have either partnered with ILOG, FairIsaac, or lesser known vendor, or scrambled to build their own business rule engine and design tool. What I learned yesterday, however, when I met with Alain Gendre, ILOG’s marketing manager for BPM and SOA, is that while these formal vendor partnerships help a bit in integrating the BPMS and BRMS design environments (and of course from a selling angle), SOA is making them much less important. When a ruleset is deployed as a rule service, it can be invoked by any BPMS or indeed by any non-BPM application as well. In other words, just because your BPMS vendor has a partner agreement with BRMS vendor X, there is no reason why you couldn’t use BRMS vendor Y instead… as long as it supports rule deployment as a web service.
In Gendre’s view, rule services belong at the SOA layer, along with other business services, not - as some analysts have described it - at some higher level application or process logic layer. Business rules represent enterprise policies, shared across applications and across business processes, exactly like other business services in SOA. This makes a lot of sense to me.
Gendre believes that ILOG has a leg up on Blaze in this regard, since (he says) it integrates better with common web service infrastructure on both J2EE and .Net. I can’t judge that, but it certainly wasn’t one of InfoWorld’s evaluation criteria. Maybe it should have been.
July 18th, 2006
[Here is my latest BPMS Watch column going up today on BPM Institute]
One of the core promises of BPMS is that it lets process owners on the business side model, monitor, and maintain their own process implementations. While chronically backlogged IT is hypersensitive to the charge that they take too long to respond to the changing demands of business, it still resists ceding to the business the power to maintain business process solutions themselves, much less build them from scratch. In fact, for many architects and developers the mere suggestion of business-driven implementation taints the whole BPMS concept. Yet business rule management systems (BRMS), facing similar issues, seem to have achieved a win-win for business-IT collaboration. How they’ve done it provides three valuable lessons for BPMS vendors.
Lesson 1: Make executable design more “business-oriented.”
In BPM, we make a basic distinction between modeling and design. Modeling is done by business, and design – the executable implementation – is the province of IT. Modeling begins with process capture and documentation. More methodology than tools, it starts with getting process participants in a room. How does the current process work? What are exceptions handled? How do you measure success? How could it be improved? Who owns it, i.e. determines when it needs to change?
Then comes analytical modeling, putting all that captured knowledge in a standard notation like BPMN, and adding parameters that allow performance metrics to be projected through simulation analysis. That’s also done by “the business,” but usually only by an analyst trained in the notation and tool.
In BPMS, modeling and executable design have traditionally used separate tools, languages, and graphical notations, oriented respectively to business and IT. A modeling language and its graphical notation, it is widely believed, cannot possibly hold the technical detail required to allow the implementation to be robust, secure, and scalable. Much better to let the model just define “requirements,” and let IT build the implementation in a completely different language and tool. It doesn’t matter that process owners and business analysts can’t understand it. In many ways, that’s even better.
With business rules there is a similar methodology-based knowledge capture and documentation phase up front, but the analytical rule modeling and executable rule design are combined into a single toolset shared by business and IT. In fact, BRMS vendors like ILOG, Fair Isaac, Corticon, and Pegasystems go to great lengths to make executable rule design tools “business-friendly.” They may offer a separate developer-oriented tool or notation as well, but underneath both the friendly and geeky versions create the same thing, an executable ruleset.
Even rule simulation and testing, at a base level at least, is moving over to the business side. IT generally applies a second level of testing, and always manages deployment to production servers, but rule maintenance is offloaded as much as possible to the business. For some reason, with rulesets maintained by non-developers you never hear the hand-wringing complaints from IT that the resulting implementation is bound to be slow, brittle, and generally unsafe. It is simply assumed that in most cases, the BRMS architecture takes care of those worries.
Lesson 2: Actively manage the entire lifecycle.
BRMS vendors understand their tools need to actively manage the entire rule lifecycle, from capture and documentation to analysis, review and approval, executable rule design, test, deployment, and maintenance. Thus they provide an enterprise rule repository with versioning, role-based access, enterprise search, and extensive lifecycle state management. They treat rules like enterprise information assets.
BPMS doesn’t do this. Some BPMS vendors provide an enterprise repository for analytical models. Most also allow connection to an enterprise business services repository managed by some external SOA infrastructure, but executable processes are typically managed at the project, not enterprise, level. In BPMS, an enterprise repository combining process models, executable business services, and entire processes – with lifecycle management and cross-referencing between them all – would do wonders for business-IT alignment.
Lesson 3: Let process owners tweak the logic on the fly!
Perhaps the most obvious way BRMS products differ from BPMS is their ability to parameterize rule logic using templates that can be tweaked by authorized business users at runtime, enabling maintenance on the fly without redeployment. Rule templates specify business rules in terms of template variables that can be changed through a web interface:
If Order.amount is greater than %threshold_amount% then …
When a process owner changes the value of threshold_amount on the fly, you don’t hear IT worrying that it’s inherently unsafe. It might be a bad business decision, but that’s not IT’s worry anyway.
In BPM, Lombardi TeamWorks offers similar functionality, parameterizing selected process logic using special variables that can be tweaked by process owners at runtime, usually to keep performance metrics on track. But that’s the only BPMS I’m aware of that does this. In contrast, all BRMS products support rule templates and web-based rule management applications that allow template parameter values to be adjusted on the fly.
BRMS enjoys a certain benefit of the doubt that BPMS still does not. It is that the design tool and underlying runtime engine are engineered so that business analysts and process owners can specify executable logic, with a reasonable degree of flexibility, without the risk that they will “break” backend business systems. There will always be cases where getting critical performance scalability or exception-handling capability requires skilled developers. No one is denying that. But those cases should be the exceptions, not the rule. BRMS vendors have focused with success on enlarging the scope of logic that business people can safely maintain themselves. BPMS vendors would be wise to do the same.
July 18th, 2006
If, like me, you’re still trying to work out how ESB fits in BPMS (or not), or even what the heck it is, you can look at the new Forrester Wave, courtesy of Cape Clear, the nominal winner.
Here is the chart posted on their site, and you can download the whole report by registering with Cape Clear.
July 12th, 2006
A frenzy of recent blogger activity around the question of whether the business people who do “modeling” can really build executable processes, by analogy with the spreadsheet. Keith Swenson says absolutely, David Ogren and Jesper Joergensen of BEA echo right on, and Phil Ayres is a lonely voice of dissent. I come down squarely on the Keith/David/Jesper side. A key point — that with the right tool, business folks can do things we used to consign to programmers — is accepted at some level by everyone. But taking the spreadsheet analogy too far — as Phil does – gets us off the track.
In the BPMS world, the debate is really between the clean-handoff vision and the collaborative tool vision. The clean handoff says business does modeling, IT does design, and anything that blurs that separation is inherently dangerous. (In fact, even directly creating skeleton design from the model is somewhat distasteful, but don’t worry, IT can change it later…) The collaborative vision says the line between modeling and design is a fine one and blurring rapidly. They’re really the same thing, and share a common tool, with users layering on different levels of specification. This is essentially the old Third Wave idea, the new BPM 2.0 idea put forth by myself and Ismael, and in my view the ultimate winner of the dispute. Ogren sums it up in one line: “The process model is the implementation.”
Are we there yet? Maybe, maybe not. That’s what the famous dinner bet was all about. Stay tuned.
July 11th, 2006
Previous Posts
