Chip Gliedman, George Lawrie and John Rymer participated in a panel on packaged applications and Lean.
Rymer argued that packaged apps can never be Lean, since most are locked down, closed engines where the vendor controls the architecture, they’re expensive and difficult to upgrade, they use more functions than customers use, they provide a single general UI for all user personas, and each upgrade includes more crap that you don’t need. I tend to be on his side in this argument about some types of appls (as you might guess about someone who used to write code for a living), although I’m also a fan of buy over build because of that elusive promise of a lower TCO.
Gliedman argued the opposite side, pointing out that you just can’t build the level of functionality that a packaged application provides, and there can be data and integration issues once you abandon the wisdom of a single monolithic system that holds all your data and rules. I tend to agree with respect to functionality, such as process modeling: you really don’t want to build your own graphical process modeler, and the alternative is hacking your own process together using naked BPEL or some table-driven kludge. Custom coding also does not guarantee any sort of flexibility, since many changes may require significant development projects (if you write bad code, that is), rather than a package app that may be more configurable.
It’s never a 100% choice between packaged apps and custom development, however: you will always have some of each, and the key is finding the optimal mix. Lean packaged apps tend to be very fit-to-purpose, but that means that they become more like components or services than apps: I think that the key may be to look at composing apps from these Lean components rather than building Lean from scratch. Of course, that’s just service-oriented architecture, albeit with REST interfaces to SaaS services rather than SOAP interfaces to internal systems.
There are cases where Lean apps are completely sufficient for purpose, and we’re seeing a lot of that in the consumer Web 2.0 space. Consider Gmail as an alternative to an Exchange server (regardless of whether you use Outlook as a desktop client, which you can do with either): less functionality, but for most of us, it’s completely sufficient, and no footprint within an organization. SaaS, however, doesn’t not necessarily mean Lean. Also, there are a lot of Lean principles that can be applied to packaged application deployment, even if the app itself isn’t all that Lean: favoring modular applications; using open source; and using standards-based apps that fit into your architecture. Don’t build everything, just the things that provide your competitive differentiation where you can’t really do what you need in a packaged apps; for those things where you are doing the same all every other company, suck it up and consider a packaged app, even if it’s bulky.
Clearly, Gliedman is either insane or a secret plant from [insert large enterprise vendor name here], and Rymer is an incurable coder who probably has a ponytail tucked into his shirt collar. 🙂 Nonetheless, an entertaining discussion.
I think this debate completely misses the point. Who cares if a packaged app vs. custom development is Lean? What you care about is ROI, TCO, value to the business, time to market, does it solve your business problem…
And as you point out, let’s just say packaged apps aren’t lean. What, are you going to write your own spreadsheet? process modeler? email server? Give me a break 🙂
Now, of course, you can argue about specific apps – SAP or Oracle’s applications suites- and then the argument has more merit because the “non-lean-ness” of these apps actually hurts you in some respects. But arguing over whether they’re lean or not just misses the fundamental business drivers entirely. Lean is the principled approach to apply to your projects, it isn’t a good way to characterize end-product… or at least, characterizing it as such doesn’t help me make good business decisions…
I think this debate is interesting, but focuses on only one dimension of the Lean discussion, namely, Lean SW. I tend to agree with your first commenter who says that some of this totally misses the point. To me, what matters most in the Leanness debate is whether or not the application software embodies a lean process or a mass production process. If the packaged app automates a well thought through Lean process, then it matters less to me that the app isn’t SaaS, doesn’t use Open Source, etc. Similarly, if the packaged app automates an old industrial age mass production process, then I really don’t want to give it points for being in the cloud, because the process is what ultimately matters. The trump card in the leanness debate is the leanness or non-leanness of the process that is embodied in the app; that is what really saves money or costs money or delights customers in the long run.
@Connie – to take it a step further, even Lean itself isn’t the primary goal, but the means to the end of ROI, speed, reduced overhead, etc (your last point). ie, it isn’t an end state but a process of improvement method/mindset/culture.
Also, I know what you mean by the “mass production” process – something that is split into bite size chunks of work – but let’s not forget that toyota mass produces autos and they are essentially the holy grail for Lean advocates – so it isn’t the “mass” nature of what the process is that makes it not-lean. I’ve been to toyota factory floors, they have assembly lines, they’re just “leaner” than the traditional assembly line, and organized using different principles than the classic henry ford assembly line. They also employ related techniques that aren’t specifically “Lean” techniques, like 5s, kaizen (sp?) events, six sigma, etc.