N-Custom Business Model
From Zanecorpwiki
Contents |
Business Software Development Market Breakdown
SMLE - small, medium, large, enterprise
If we roughly break the business customer's into small, medium, large, and enterprise then we might say that custom is for enterprise, customized is for large, commodity is for small, and medium is screwed.
With custom, the buyer gets exactly what they want, and they pay dearly for it. The seller makes a lot of money, but has no really growth because they own nothing at the end of the day.
With customized products, the buyer gets 80-100% of what they want at 20-40% the cost of custom. In many ways, this is the best sector for the seller because they get to charge a huge premium for the custom work and also get a big return on their IP investment in the code. They can sell the same piece of code 100 times for 30% it's production cost each time. Due to their expertise, they can also charge above market rates for the custom work.
With a commodity product, the customer gets less of what they want, but pay relatively little for it. The seller gets potentially huge returns on their IP, but has only one high risk revenue stream.
Of course, in reality the picture is more complicated, there is cheap custom work and expensive commodities. This is an idealized monologue.
From the Developer's Perspective
A well designed code base could in theory operate in with either the customized or commodity model. Customized software requires 'hooks' where custom actions can be inserted into the standard or base flow of control. However, non-trivial, well designed software will often already be structured in such a way inserting these hooks would for the most part not require drastic structural changes.
From the Deployment Perspective
The biggest difference between commodity and customized is in deployment perspective. I use the term here to encompass both actual deployment and the post-deployment responsibilities. We can discount the custom development because that's usually paid for by the customer and so represents little or no risk when viewed from the perspective of the entire life of the product. It is the deployment and ongoing management of the customized code which represents the risk.
The problem is the ongoing management of all that custom code. Each customization creates a slightly different look on the code base. These customizations have to be kept in synch as the main code base evolves. Updates have to be compatible with each customization. Perhaps even more important is the mental overhead involved in remembering oh, that's how *they* do it every time a developer/support person works with the customer or their customizations.
Considering the mental overhead, plus the overhead of the basic deployment and record keeping for each version, even if there's a low ratio of custom to standard code the overall ongoing cost of each custom version is going to be some significant fraction of the ongoing maintenance cost of the standard code base.
Bridging the Gap
The small business does fine because even though they might not find anything that's very close to what they really want, it doesn't matter. A small business can easily compensate with manual processes, or just let it drop. The cost of the potential difference between the perfect solution and the commodity solution they find (or even no solution) is not very big simply because the business is not very big.
The large business has the size to justify the cost of implementing a software solution that more closely mirrors their actual (or desired) operations and processes. The savings in going customized vs. custom (especially long term costs when factoring in the assumed continued development of the base code) creates the context for a successful transaction.
The medium business is screwed. The base entry cost of customization is simply too high. At the same time, the model embodied in available commodity solutions will not always match closely to the actual operational processes of the company and the company is large enough that this difference has significant costs. In other words, there's value to be captured but no one is set up to capture it.
The solution seems to lie (at least partially) in leveraging previous customizations. I.e., we have base product P and create custom variations for larger companies (or as a loss leader for medium companies). Now a new company comes along whose operations are very similar to a previous client. This new company is deployed with a the same customized version of the product as a previous customer.
N-Scaling a Single Code Base
Creating a code base that can scale across all sectors is a big part of the trick to get the most out of the business model. Offer a single 'base application' which anyone can sign up to for a low recurring fee. This services the small/commodity sector.
Have well designed code and develop appropriate hooks and flow to allow for customization. True customization business requires things like a project management, technical consultants, and an engagement process as well. These things are all a sunk cost once one decides to do a customization business, but with the code shared between the commodity and customization market, there's a big chance to spread risk and realize significant savings.
In order to bridge the gap to the middle, the trick is to manage the deployment process appropriately so that the cost of additional customers reduces at least part of the per-customer cost of managing multiple versions. The key is conceiving of each version of the product as a sub-product of sorts rather than as customer X's version.
Organization of code and other artifacts is straightforward enough. Each version packages and deploys as it's own application. The base application becomes a component of the install. Custom artifacts are organized in a parallel or otherwise rational manner. Developers work on the base code, take lead on some looks, and secondary role for other looks. (The numbers depends on the complexity of the looks involved.)
When possible, features should be switchable/configurable by the company (via a institution admin) itself. In this way, if a new feature is added to a look for company A, company B considers the new feature to be bloat, and company C wants the new feature. With adminable features, everyone gets exactly what they want and we the code maintainers do not have variations. The features themselves are slightly more complex, but in a regular way such that the cost of making the second adminable feature approaches the cost of creating the feature in a non-adminable fashion. In other words, marginal cost of the adinable nature of features is diminishing. The application admin has to bear the burden of deciding which features to turn on and off, but they alone bear the burden. The upshot, however, is that everyone gets exactly what they what.
Company A, that wanted the feature in the first place gets it with no push back. The code owners don't need to worry too much about increasing the complexity for everyone because the adminable feature strategy takes care of that. Company B simply doesn't turn the feature on, so they get no bloat. Company C, which finds the feature useful, activates the feature and gets it for free.
The Wrench
The wrench is the system is this: what happens to the medium when a customization customer begins to change their basic structure? All in all, this is probably not a big problem.
First, this won't happen very often. A long lived company is bound to grow away, but we can expect the cycles of fundamental change to be in the 5-10 year range. For the most part, changes will be new adminable features and have little or no effect on unwanted complexity overhead for the average user. This is the big point. Even when the lead, customization customer disappears from a look's client set, it might not matter if there are a sufficient number of tailing clients.
