> The latter are not vertical systems. They're middleware that the client expects to integrate with existing systems (paying huge consulting bills in the process, though they may not know it yet).
Agreed. Tools to abstract workflow can be useful. My impression is that whether middleware tools to abstract workflow can be useful depends largely on how well they integrate with the overall toolset being used. Ours works because it's fully embedded in the tools. Standalone solutions may or may not work. I'm hearing good early returns from a friend using Microsoft WF in an all-Microsoft shop, but (1) it's still too soon to tell whether it's really a success, and (2) solving the all-MS solution is a much smaller problem than a universal workflow engine or even a general-purpose Java workflow engine.
> Sooner or later the vendor decides that their in-house framework is so great that they've really solved the problem of enterprise software development in general. Now they "just" need to package it up as a platform.
Actually, we're exactly at the point of trying to figure out whether our tools useful to VARs and client-level users, or whether it's really only useful to us. And, yes, figuring out whether we can increase product revenues as a percentage of our overall revenue mix.
> Of course even in the success stories (SAP?) the consulting role is still huge.
Unequivocally. However, if we succeed in working with VARs and technically savvy clients, we would be offloading most of the consulting work to them by building expertise outside our organization.
I won't pretend that I think it's a lock to succeed at a problem a lot of people have failed at, but since we're not really risking our core business model to try, it seems like a reasonable gamble as a way to grow the business faster.
Agreed. Tools to abstract workflow can be useful. My impression is that whether middleware tools to abstract workflow can be useful depends largely on how well they integrate with the overall toolset being used. Ours works because it's fully embedded in the tools. Standalone solutions may or may not work. I'm hearing good early returns from a friend using Microsoft WF in an all-Microsoft shop, but (1) it's still too soon to tell whether it's really a success, and (2) solving the all-MS solution is a much smaller problem than a universal workflow engine or even a general-purpose Java workflow engine.
> Sooner or later the vendor decides that their in-house framework is so great that they've really solved the problem of enterprise software development in general. Now they "just" need to package it up as a platform.
Actually, we're exactly at the point of trying to figure out whether our tools useful to VARs and client-level users, or whether it's really only useful to us. And, yes, figuring out whether we can increase product revenues as a percentage of our overall revenue mix.
> Of course even in the success stories (SAP?) the consulting role is still huge.
Unequivocally. However, if we succeed in working with VARs and technically savvy clients, we would be offloading most of the consulting work to them by building expertise outside our organization.
I won't pretend that I think it's a lock to succeed at a problem a lot of people have failed at, but since we're not really risking our core business model to try, it seems like a reasonable gamble as a way to grow the business faster.