Those Configuration Workgroup members who've been participating for more than a year might remember that, before this last European CWG Conference in May, there were always pre-meetings devoted to the work of one or more of what were then called "Focus Groups."
One of the most active of these Focus Groups was the "Advanced Mode Focus Group," chaired by Daniel Naus from HP, and currently Vice President of the CWG Board of Directors (soon to be President).
Another of these Focus Groups was the "Integration Focus Group," chaired by Steve Yip, also of HP, and before last year's reorganization of the CWG one of its three Chairmen.
It was a ritual, of sorts.
These two groups would meet with representatives from both the SAP IPC and Variant Configurator Product Management groups, as well as representatives from the SAP Development organization, to talk about achieving the mission with which representatives of SAP and its customers started the Configuration Workgroup back in 1993.
Namely, the continual extension of the SAP Product Configurator with "Best-of-Breed," "Solutions-Configuration" capabilities, as well as the integration of those capabilities into the SAP backbone.
Along with these two Focus Groups there was another, called the "VC/ECM Focus Group."
It had been started rather later than the other two, and it somehow never got brought into the ritual pre-meetings, but it was most capably chaired by Robert Eramo from Lam Research, currently Secretary of the CWG Board of Directors, with rather desultory assistance from his Co-Chair, a certain party who, in deference to his continued, more or less "unsullied" reputation, will remain unnamed.
These three Focus Groups seemed to be sitting on the opposite ends of a long, wooden plank, balanced on the fulcrum of SAP.
On the one hand there were the two Focus Groups from the Configuration Workgroup's very earliest days, joining with the developers in the pre-meetings, and talking collegially about requirements, the likelihood of whose implementation seemed to be drifting ever more distantly over the horizon.
And then on the other hand there was the later Focus Group, an upstart of sorts, which seemed at least to have success. It had one very precise requirement, the need for an "Undo" mechanism for ECM transactions (also called the "Oops" transaction), and functionality to meet this requirement was actually implemented.
And while the two older Focus Groups were sinking lower and lower on their side of the SAP fulcrum, the VC/ECM Focus Group seemed to be rising higher and higher. It had more members, it was far more active, it had an enormous list of requirements, and those requirements actually seemed to have commitments from SAP.
It was a curious situation, but not really so hard to understand.
Even though the two "older" Focus Groups were much, much older, the companies who actually used the functionality they were focused on numbered no more than five, while the number of companies using the already integrated, not quite so "Best-of-Breed," "VC" functionality was somewhere in excess of 1500.
If you are an executive of a company with in excess of 1500 customers who are "more or less" satisfied and happy, and you've got only five customers who want something a whole lot better and more effective ... but far more costly for you ... then in which group of customers are you going to invest your own limited development dollars?
The situation seemed to have reached a point of culmination even before the beginning of the last May meeting. Not only were there no pre-meetings for either the Advanced Mode Focus Group or the Integration Focus Group, there were no pre-meetings at all.
And not only that, but there seemed to be a sort of reluctant agreement that the subjects of "Advanced Mode" (aka SAP's own attempt at a Best-of-Breed configurator) and its "Integration into R/3" were going to be left not only entirely off the agenda, but not even mentioned.
Obviously the companies that had already invested so much into their own implementations of this "Advanced Mode" software weren't very happy.
But this wasn't a whole lot different than what had already come to be accepted as "normal" ...
Two disconsolate Focus Groups, representing five customers, and one very active, upbeat Focus Group, representing more than 1500.
A situation that had already come to be accepted as "normal," that is, until about halfway through the second day, when things started subtly changing, and then, more definitely on the last day, when it took a sudden, definitive turn for the worse.
First, it was announced that the IPC was apparently going to be "buried" within the ABAP stack.
The reason for this was given as "Total Cost of Ownership." On the face of it this wouldn't be a bad reason at all, except for one slight little problem.
The "Total Cost of Ownership" that was given as justification was not the customer's "total cost of ownership," it was SAP's.
It was announced, and it was stressed, that maintaining an IPC that ran outside the ABAP stack was far too costly ... for SAP ... and therefore it had to be eliminated.
And along with its elimination, of course, was the complete elimination of the IPC's "Ready-to-Integrate" scenario, a prospect hitting most of the companies who'd already implemented the IPC for product configuration in the worst place possible ... their pocketbook.
Following this, it was announced, during what had previously been the upbeat, highly active VC/ECM Focus Group meeting, that all the functionalities on the VC/ECM Requirements List, which had already been committed to, were going to be dropped.
There was no point in talking about them anymore. There was simply no budget for them, there wasn't going to be any budget for them, and that was that.
And then the very last blow came during one of the Workshop meetings toward the end of the last day, when one of the representatives of those "normally" disconsolate "Advanced Mode" customers received, from one of the representatives of SAP Solution Management in attendance, the seemingly intransigent assertion that "Advanced Mode" would never be integrated into the standard.
It should not be too hard to imagine how, after that last meeting, the mood was grim, if not bordering on downright "mutinous" (recognizing, of course, that "bordering on 'mutinous'" as a characterization of the relationship between customers and their supplier is somewhat strange ... grist, perhaps, for a further column).
A Glimmer of Light
That night the Chairmen of the Focus Groups ... all three of the active Focus Groups, on both sides of the fulcrum ... met for dinner. As stated above, the mood was grim. With the passing of time, and the consumption of alchohol, the mood shifted to a kind of desperate, vengeful mocking hilarity.
Memories are dim, but what does stand out, somehow, is the figure of a rampant, rampaging "Trunk Monkey," as a kind of avenging angel.
Of course there remained at least one, against this background, who retained a modicum of sanguinity. The others accused him of being overly, drastically optimistic, if not downright naive (see the introduction to my column, above).
But now, and in retrospect, we can see the promise in the announcements of those three fateful days.
They all have to do with the now infamous incorporation of the IPC into the ABAP stack:
- First, the IPC is not "buried" at all. It is simply available ... and just as available ... through another mechanism. Like any other functionality within SAP, it can be called either from ABAP, or from Java, or from .NET. There is no limitation.
- Secondly, the IPC is far more reliable. No longer, if there is one Run-time Exception, does the company running it have to worry that its whole order-taking capability goes to pot ... even if only temporarily. Individual IPC Sessions will be managed within individual Virtual Machine Containers. Given this, the IPC's "Total Cost of Ownership" will be that much higher ... from the customer's point-of-view.
- Thirdly, the IPC no longer requires an "enormous" supporting infrastructure of its own, alongside, and in contrast to, the famed reliability of the infrastructure provided by SAP's BASIS system. This has a correspondingly "enormous" impact on "Total Cost of Ownership" too ... and again from the customer's point-of-view.
Those are the most obvious benefits, and we probably shouldn't be surprised that SAP is now touting them, seeming to have learned from the mistakes inherent in its positioning of the IPC Integration during the May 2005 CWG Conference.
But there are more:
- First, one of the most aggravating issues surrounding the use of the Variant Configurator is that, while it possesses a highly developed, very powerful Constraint-processing capability ... and as we know from the analysts, any "true" Sales Configurator has to be a Constraint-based configurator ... the fact remains that it can hardly handle Constraints with any kind of proper performance at all.
I personally ran into a most embarassing example of this while teaching Constraints for a customer that uses the Variant Configurator to process Pneumatic Valves and Valve Islands.
They had built an enormously complicated procedure to handle the relationships between adjacent Valves in the entire Valve Island. We were able to simplify this procedure, and just as enormously, by replacing it with a single, rather intuitively obvious Constraint.
But we found, as soon as we had added the Constraint to the Valve Island's configuration profile, that, after typing in the Valve Island's Material Number into the CU50 Configuration Simulation, and hitting the <ENTER> key, we had to wait a good 25 seconds for the very first Characteristic Entry screen to return.
And then, after setting just one of the Valve's positions ... and thereby triggering the actual processing of the Constraint in the Variant Configurator's Pattern-Matching System ... we had to wait another 20 seconds, for every Valve to be checked against every other Valve.
Constraints are extraordinarily powerful.
They can simplify and reduce the job of product model maintenance significantly. But if you use them, you can count on 90% of your configurator's run-time processing being devoted to them, and when you're running that in an interpreted language ... ABAP ... and jockeying for prcesssing time against all the other processes that are running on the Application Server, the costs are prohibitive.
Faced with that debacle, and in order to save my reputation, we did an experiment. We created an IPC Knowledgebase for the Valve Island, and then we opened up two SAPGUI sessions, one right next to the other.
In the one we entered the Valve Island into CU50, and in the other we entered the very same Valve Island into CU35, the IPC Knowledgebase Runtime Version Generation transaction. We started CU50 first, just to give it an advantage.
The long and the short of it is that, while waiting for CU50 to come back (and just with the very first Characteristic Assignment screen), we were able:
- Generate the Knowledgebase Runtime Version for the Valve Island;
- Download it via transaction CU36 as text files to my own local machine;
- Upload the text files into my own local SQL Server database;
- Start the SCEGUI of the IPC;
- Select the Valve Island Knowledgebase (from the huge list of Knowledgebases I have on my local machine);
- Select the Valve Island Knowledgebases Profile, and ...
- Get the SCEGUI's Characteristic Assignment screen back.
All that, culminating, finally, just immediately before CU50 returned with its own Characteristic Assignment screen.
And of course the processing of the Constraints in the IPC was just as dramatically different: a fraction of a single second, in contrast to 20 (seconds).
Netting this all out, one of the most important benefits of the IPC's integration into the ABAP stack, from a product modeling point-of-view, is that, by eliminating the Variant Configurator and its horrible Constraint-processing performance from the flow of Orders completely, the product modeler will finally be liberated to take advantage of what's always been there.
- Secondly, hidden in the fact that the IPC is now integrated into the ABAP stack, lies the fact that "Advanced Mode" does not ever have to be integrated into the R/3 world ... it's already there.
That doesn't mean that "it's already there" for those companies wanting to use it for its "System" or "Solution" configuration capability. That still requires an additional "integration" effort.
But let's say you're a company manufacturing Valve Islands, and you'd like to use the combination of Restrictable Characteristics and Variant Tables and Constraints, but you've been avoiding it, not only for reasons of performance, but also for other, seemingly trivial, but nevertheless insoluble reasons ... like the fact that, if, in the Variant Configurator ... or rather, in what we call "Classical Mode" ... you restrict a Value Domain to just one Value, it is automatically set.
With Advanced Mode you don't get that. You have a much more precise handling of Restrictable Characteristics. You can control when ... or under what curcumstances ... your "singleton" Domains get assigned as Values.
And the of course there's the performance issue. If the IPC is much faster in processing Constraints than the Variant Configurator, the IPC in "Advanced Mode" can be that much faster.
That's not because it processes Constraints faster. It's because it gives you things, like Abstract Data Types, with which you can drastically limit the "space" the Constraint Engine has to keep track of, in order to recognize when it has things to do.
All you have to do, in order, as a product modeler, to be able to take advantage of these powerful capabilities, is to turn a certain User Parameter "on."
So let's get back to that "glimmer" of light ...
In all the history of product configuration at SAP, we can probably identify three really significant milestones.
- The first was the decision, taken already back in 1993, with ... what we are told was ... the decisive support of the Configurator Workgroup, to build a really powerful Inference Engine into the backbone of R/3. This was the Variant Configurator.
- The second was the decision, taken already back in 1995, and again with the decisive support of the Configurator Workgroup, to build a "standalone configurator," a decision which resulted, first, in the actual development of "Advanced Mode," and secondly, in the IPC itself.
- The third was the decision, taken apparently sometime last year or the year before, in secrecy and without the decisive support of anybody (at least anybody external), to integrate the IPC into the ABAP stack, and thereby into both CRM and ECC (what used to be called R/3).
Please send comments to Henk Meeter, at firstname.lastname@example.org.