I think what you're describing may be in a different class than the products the OP is castigating. 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). And once that integration is done, then magic happens and the productivity boost is supposed to kick in.
What you're describing sounds more like an in-house framework that is used to boost your company's efficiency in delivering systems to customers. That's different. When you're doing a lot of similar projects, abstracting out the common parts can be a big win. I've seen this succeed, up to a point.
I say "up to a point" because I've noticed a pattern. 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.
The problem with this is that the value is not in the framework, it's in the team that's built up around the framework. The framework may make you more efficient ("you" meaning the programmers, managers, analysts who know it, identify with it, and belong to an organization based on it), but it doesn't follow that it will make others more efficient, because the framework abstracted away from you is not the same thing at all. The overhead for anybody else to use it is considerably greater and may (and usually does) exceed the benefit.
Vendors do this because they want to shift away from being a consulting company (where the product is you, and the framework is your secret weapon) to being a product company (where the product is the framework and the "you" part is vastly diminished, ideally to zero). Of course even in the success stories (SAP?) the consulting role is still huge. And I can't shake the impression that the successes are mainly in sales and marketing rather than technical substance.
Anyway, these are just things I've observed. I don't claim they apply to your situation.
> 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.
What you're describing sounds more like an in-house framework that is used to boost your company's efficiency in delivering systems to customers. That's different. When you're doing a lot of similar projects, abstracting out the common parts can be a big win. I've seen this succeed, up to a point.
I say "up to a point" because I've noticed a pattern. 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.
The problem with this is that the value is not in the framework, it's in the team that's built up around the framework. The framework may make you more efficient ("you" meaning the programmers, managers, analysts who know it, identify with it, and belong to an organization based on it), but it doesn't follow that it will make others more efficient, because the framework abstracted away from you is not the same thing at all. The overhead for anybody else to use it is considerably greater and may (and usually does) exceed the benefit.
Vendors do this because they want to shift away from being a consulting company (where the product is you, and the framework is your secret weapon) to being a product company (where the product is the framework and the "you" part is vastly diminished, ideally to zero). Of course even in the success stories (SAP?) the consulting role is still huge. And I can't shake the impression that the successes are mainly in sales and marketing rather than technical substance.
Anyway, these are just things I've observed. I don't claim they apply to your situation.