On Sun, 2010-02-07 at 14:58 -0600, David E Jones wrote: > We're covering all sorts of ground in this thread! On the other hand, > if we look closely at the ground there are hints that all of this has > been covered before... ;)
No doubt. :) I have renamed my index to "New User Guide"-- better describes it, more consistent with suggestions from this list, and less overlap with what is already there. It is a different approach from "Getting Started with OFBiz", and "OFBiz Documentation Index" but mine references both of those. It just organizes some of the stuff that PHBs will want to see right away, and lays out a clear plan for getting from here to there. Still a lot to flesh out, though, mostly finding and organizing the stuff already there. > Matt, I think what Chris Snow is referring to is the difficulty of > learning to effectively use the OFBiz framework versus learning to > effectively reuse the applications (both the base and specialpurpose > application). Based on what Chris has written in other messages he is > still struggling with how OFBiz is organized (ie the base applications > are intentionally NOT organized around business processes in order to > be as reusable as possible in different business processes, and > instead are organized around the data structures). So we're saying that "hello world" in the OFBiz framework requires knowing the framework, but repurposing an existing app to fill a new need requires 1) knowing which apps are in the toolbox, 2) knowing which one is the closest fit, and 3) making, testing, and deploying the changes. Is that about it? If so, thanks, that makes more sense to me. > In any case, there are a few reasons why the business side of OFBiz > (the applications) are a lot more complicated and difficult to learn > than the technical side of OFBiz. The basic problem is the size of > each, but that's over-simplifying things. > > Read Before You Write: It's not really human nature to do this, and it > takes a lot of patience. This is made worse because if individuals > have a hard time with patience, organizations are simply incapable of > it. The PHBs want results... and reading sure doesn't look like it's > producing any. What's worse is if the individual manages to produce a > result with a couple of dozen lines of configuration and bits of code > instead of a couple of thousand lines of raw, meaty, manly Java then a > semi-technical PHB may find it really unsatisfying to have paid for so > much time to get so little, not realizing that the individual just > save him 10-100 times what the alternative would have cost initially > and over its useful lifetime. This is an Organizational Behavior problem that certainly exists, but is by no means universal, or even in the majority. Most managers worth their salary know that the right tool makes all the difference. But they also know that there is a tradeoff between how many times you do a thing, and how right it needs to be. We use nail guns in construction, but hammers also have a purpose, even in construction. "Close enough" is OK in horseshoes and hand grenades, and in business processes that are not repeated often enough to make the effort of fine-tuning worthwhile. My wife calls the other end of the spectrum "analysis paralysis" and business managers can't much tolerate that, either. As I pointed out before, its the 80/20 rule. I don't WANT to build a custom tool for 80% of my business, and if I have to do that, the value of the whole is greatly diminished. But you are correct that PHBs do NEED to be able to customize the 20% that generates the profits and is repeated with high frequency. That 20% will differ in every business. It's like code optimization-- do you really want to unroll every loop by hand, and write all the code in optimized assembly for maximum speed? No, you get a working prototype first, then you profile it, and you optimize only where you must to achieve your performance goals. Much (most) of the time, code clarity is more important than optimization. > Scratching the Surface: A business application is not like an operating > system, or even a framework for building business applications (which > is like an operating, except the interfaces are tuned to a different > type of input, a less technical and more business-oriented type of > input). The difference is by nature there is no way to design an > interface adequate to represent a business application, and that is > what both operating systems and application frameworks are all about. > Unfortunately business people don't like being told that an interface > with a few little parameters is supposed to represent the entirety of > options for ANY process in their business, even "standard" ones like > billing or shipping. Business people don't like not be able to change > and tune any part of their business that they want, and if the systems > can't keep up then they don't get used. SAP and most ERPs out there > are great examples of this. They are proprietary software works and > you don't get the source code, and can only change what they've > decided it's okay to change (unless you want to rewrite something, > usually more than you think). Those sorts of systems don't let you get > below the surface, which is unfortunate because then you don't even > have an option to Read Before You Write. So you are saying that these systems only scratch the surface of the problem, because they only allow certain modifications? I wasn't fully clear on whether scratching the surface is a good thing, or not, from what you wrote here. Granted, a Business App (BA) is not an OS, and a BA is not a BA framework (a meta-BA, if you will). I assume OFBiz is your meta-BA, and you seem to be saying that there is no way to create a truly universal BA, because it needs to be able to be customized, and I agree. But it doesn't ALL need to be customized, and the part that needs customizing will be different in each case. Besides, if its open source, I CAN customize anything and everything-- but that doesn't mean I want to rewrite the whole app-- only those few parts that are worthwhile. That is the value of HAVING an app to rewrite, rather than building from scratch. The beauty of OSS is that it offers a third option in the classic "Buy vs. Build" decision. > In other words, the way you go about adding value (via easy of reuse) > in a business application is very different from how you go about > adding value in an operating system or a business application > framework. With the OFBiz framework you can learn the "interface" to > it, but with the applications you pretty much have to deal with it > all. On the other hand, there are more concise "interfaces" to it, > like the data model and browsing things related to data model > elements, which is made easier with the Artifact Info and other > related tools in the OFBiz WebTools application. > > And how do you apply that in your business? The basic answer is you > don't. OFBiz is meant to adapted to businesses, not businesses to > OFBiz. You can certainly run it OOTB, but that's not how it's meant to > be used and you'll find that a painful experience. It's not going to > hold your hand because it was never designed to run your business. > Frankly, how could it be? Some systems claim they are in their > marketing, but that marketing isn't honest because how do they know > how you want to run your business? When you start trying to use those > systems in your business you find out pretty quick that they really > don't know. I think you overestimate the pain of a "good" OOTB solution. Maybe OFBiz isn't that, at this point. And granted, every business will differ. But if my 80% problem is largely solved OOTB, I have a LOT more time and money to throw at the 20% that NEEDS to be customized, and a lot more incentive to do it. Every body is different, too-- but that doesn't mean that every article of clothing needs to be hand-tailored to fit decently (not perfectly). But most any article CAN be tailored, if the need arises, and if such tailoring is worthwhile. > So, your best bet is to define your business and then do a gap/overlap > analysis with OFBiz to see what you can use, what needs to be adapted, > and what needs to be built to fill gaps. This is precisely where the huge learning curve is the impediment. I know my business, but I don't know OFBiz, so even the most basic gap/overlap analysis requires hiring an OFBiz expert (if I can find one) and then I have to educate them on my business. If I could use OFBiz effectively OOTB, then the gaps/overlaps would be apparent by trial and error, probably ranging from mild annoyances to (rarely) deal-breakers. But I can always continue to use existing systems and processes, until the deal-breaker gaps in OFBiz can be filled. In the meantime, it is still useful. > If you really want a tuned > system, like for a larger company or for a derivative work (like a > commercial application targeted at a certain type of company) then you > can define the business, design the application, and build it, and > save resources building it by reusing as much as possible from > something like OFBiz (which gets back to why OFBiz is organized like > it is). To do these things effectively takes some experience, and to > shorten the path certain tools are helpful like the HEMP approach > (http://www.dejc.com/home/HEMP.html). Not what I need, but others will. But the absolute number of people needing either of these scenarios will be much smaller, IMO, than the number of SMB owners. The Fortune 1000 will have big budgets for ERP, and will be hard to land (long buying cycle). You really need a sales army of "elephant hunters" to play in that space. If you envision VARs being your principal sales channel, then this design choice makes perfect sense. I don't see that happening myself. The differences from one type of company to another are probably not so overwhelming as you think. Why was John Sculley pulled from PepsiCo to run Apple? Because businesses are not that different. Apple and Pepsi have more in common from the marketing side than most people think-- its all about the brand. Sure, one item has a lifetime is seconds, the other in years. But the processes are largely similar, though the terminology may change. Is there a role for VARs? Absolutely. Is it the primary sales channel? I doubt it, but YMMV. VARs are always a step removed from customers and users, which makes it that much harder to be customer-focused. I should know-- we sell to distributors, which sell to retailers, which sell to users. If I didn't go out of my way to talk to end users, I'd NEVER know what they think of our products. I could tell you some war stories... > Stepping back a little... there is a bigger trick... and that is how > many people believe what I wrote above Read Before You Write and > Scratching the Surface? Well, not many. For those that do understand > and agree OFBiz is great (could be better, lots better, because even > many people involved with OFBiz don't believe or don't understand > those two ideas and as the number of contributors increases that > painful fact becomes more apparent). For those who don't understand or > don't agree, they are destined to a life of making things painful for > them and others they work with, whether they attempt to use OFBiz > (probably won't last long) or whether they choose a likely painful > commercial route filled with reasons to spend more and more money on > more and more different software. > > -David This really boils down to a basic marketing issue: who is your customer, and what do they really need? If you really meet that need effectively, delivering solid value, you will be successful beyond your ability to expand and serve. How do you segment the market? By revenues? By industry? By employees? What are your sales channels? Direct? Through VARs or consultants? What are your customers' real needs and how well do you meet them? In the venture capital community, we sometimes talk about "a solution in search of a problem." Companies (or non-profits) that don't know what their customers really need will always struggle. If this is indeed a "missionary sale", in that you have to sell people on a value proposition that they can't really see, or won't see for months or years, then you do have an uphill battle, no question. Thinking that they are stupid won't help. Suffice it to say that I don't think it absolutely HAS to be that way. In my management experience, if I'm not getting the sales results I want, I try to re-examine what I'm doing, and I usually find that the reasons are both apparent and solvable. A better mousetrap is often in the eye of the beholder-- a completely customizable mousetrap might not be the overwhelming marketing advantage, if you want to be catching mice like, yesterday. (And who doesn't?) But if you give me a better mousetrap today, and it *immediately* solves 80% (or even 60% or 40%) of my mouse problem, who do you think I'll call for the more intractable part of the problem? When I get entrenched in a particular view, my wife sometimes asks me: "do you want to be right, or do you want to be happy?" Or as Dr. Phil would say, "How's that working for you?" Often the only difference between a martyr and a hero is-- well, the hero actually WON the battle in question. If you find yourself in an uphill fight to sell a solution to someone else's problem, maybe it isn't (yet) quite the solution it needs to be. Not that it isn't great-- it just may need a bit of work yet to really break loose. You've brought OFBiz this far (and that is a LONG bloody way), so I figure that you are a pragmatist and a problem-solver at heart. And I think you have the groundwork laid to blow this market wide open, building a much larger, more committed, and more wealthy community, if you can make the value proposition more palatable to average SMB leaders, who I think are often smarter than you sometimes give them credit for. Not all PHBs got there under the Peter Principle. Especially in the SMB sector, which is where I see the biggest potential for OFBiz. ;) http://en.wikipedia.org/wiki/Peter_Principle And BTW, I'd still like to take you to lunch next time you are in town. Do you know when yet? :) > > > On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote: > > > On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote: > >> Matt, what was the 300 - 400 hours for? > > > > It was Milind Parikh's estimate of the learning curve, except I > > misquoted. He said people should be "expected" to spend 200-400 hours > > to "understand OFBiz". > > > >> I think that time would give > >> you the capability to develop a standalone solution. If you want to use > >> existing functionality (order mgt, invoicing, shipping, mfg, workeffort, > >> etc) you need a lot more time depending on which functionality you use. > > > > I'm not sure I understand this. After 300-400 hours you can develop > > standalone apps, but using existing functionality takes longer? I would > > think it was the other way around? > > > >> I've been using ofbiz pretty heavily for nearly a year now, and have a > >> 'good' understanding of developing solutions. In terms of the > >> components, I am only really starting to get a deep understanding of how > >> workefforts work. If fact some discussions I've had on the ML suggest > >> that it may not be possible to know all of ofbiz at all. Instead you > >> have to know how to find the answers to the areas you are trying to > >> implement. However to know how to get the answers, you need to know the > >> questions to ask. For this you need a good understanding of the overall > >> system, for which there is no documentation except the universal data > >> models. > > > > I can take any Linux (or BSD) distribution off the shelf, spend a > > half-hour installing it, and immediately get SOME useful work done. It > > may not do everything I want, but OOTB, it does the basics. And OOTB, I > > can use it well enough to at least evaluate how well it meets my general > > needs. > > > > I can then work on tuning the system to my specific needs, or use it as > > a platform to develop custom apps. I don't need to understand all of > > the kernel (say the schedule or VM code) to get my job done, let alone > > the whole system. If I need to write a new driver, filesystem, text > > filter, or whatever, I take an existing one as a template or example, > > and I write another that can be plugged in. And you're right, I doubt > > anyone knows it all, and that's OK. > > > > By the same token, IMO, you should not have to understand all of OFBiz > > to either 1) use it productively, or 2) write apps (or other plugin > > code) for it. If that is not the case, then the system design and > > modularization needs improvement. > > > > And that is exactly why (I think) your work on framework independence > > and attention to dependencies is really important. > > > > -- > > Matt Warnock <mwarn...@ridgecrestherbals.com> > > RidgeCrest Herbals, Inc. > > -- Matt Warnock <mwarn...@ridgecrestherbals.com> RidgeCrest Herbals, Inc.
