I don’t often devote a whole post here to just one link, but I think Simon Phipps’ The Adoption-Led Market deserves it. If you’re in the business of technology you probably need to read it. Especially the “Consequences” section.
Contributions
I don’t often devote a whole post here to just one link, but I think Simon Phipps’ The Adoption-Led Market deserves it. If you’re in the business of technology you probably need to read it. Especially the “Consequences” section.
Comment feed for ongoing:
From: len (Mar 13 2008, at 06:17)
Procurements don't work like that, Tim. Simon is glossing past important details to beg his argument. I've just spent ten years analyzing and responding to large procurements in RFPs through BAFO and implementation.
Payments are typically after FAT tests in staggered sums. This is a problem for the vendor because the revenue doesn't begin until then. That is typically an 18 month cycle or longer. He is also skipping over the implementation cycle or making it sound less expensive than it really is. That includes the customization for all of the close but not close enough requirements, the new features that are not strategic so costs are levied to the customer, the features that are strategic so costs are absorbed by the vendor, interfaces to legacy systems, and so on.
Careful with this one. You're on thin ice as a company that primarily makes its money in hardware and expects that upfront. Turn Simon's article around and make it all about getting free hardware, testing it, working in community, redesigning components to meet one-off requirements, and then only paying for the services of the community, not the hardware manufacturer.
The facts are, for the lower layer software some of what he says works but the higher you go in the stack to the application layers where local requirements dominate and standards have only a minimal effect, what Simon is suggesting falls apart as a business model.
[link]
From: Simon Phipps (Mar 13 2008, at 08:58)
Hey Len - I don't think I actually understand what your issue is here, beyond perhaps a dislike of simplified arguments. I'm pretty familiar with IT procurement cycles and I would probably agree with your description of how it works. I'd also agree that highly custom systems take greater investment. And I don't expect an overnight change here.
All I am observing is that we already see businesses like MySQL and Canonical moving to a "harvesting users" approach for components of software solutions and I see every probability that the trend will continue. Discussions with SIs suggest they expect the same. As I visit and talk to large customers I see more and more adoption-led thinking.
For what it's worth, Sun already enables an adoption-led approach to hardware. See http://www.sun.com/tryandbuy/index.jsp
[link]
From: len (Mar 13 2008, at 13:55)
Then we agree on what I am saying about the lower level components such as MySQL (which we use, BTW with PostGres). I admit we'd like to toss some of this out to simplify our software mix. The further one goes up in the stack, the less likely the adoption approach is to work. I'd love to be proven wrong.
The problem of having a local champion choosing components is they often don't have more than a local perspective of costs or global requirements.
But this is really a test of what you propose to see how it fits into the RFP models we all live with day to day.
Here is a Functional Requirements Questions list (real, on my desk as I type). How does the adoption approach help?
1. The current product DOES NOT offer this functionality.
2. The current product DOES provide the functionality for an additional cost.
3. The current product DOES provide the functionality from a third party.
4. A future product enhancement within he next year WILL provide the functionality.
5. A future product enhancement in the next six months WILL provide the functionality.
6. A future product enhancement in the next three months WILL provide the functionality.
7. The product DOES provide the functionality at NO additional cost.
This is followed by a matrix of features with those numbers as scores and a description has to be entered for each one. Remember, the people who evaluate the RFP are not the people who wrote the requirements nor are they the system users. They may be consultants or they may just be the front office drones who score the proposal and take the top five scorers in the downselect.
My problem with simplified approaches is costs. When a sales approach is tossed over the wall to a development staff that then has to look back at the implementation staff and say, "We're sorry, but that's what they sold" who then have to look back at a Customer Support Staff and say "This is what they agreed to" who has to look back at a customer and say, "Don't shoot me. I'm just the messenger." who gets shot?
Your response might be "the customer has been involved through prototyping at all phases of the procurement, therefore adoption is smooth and just in time" and where possible because they have the resources, that's great. Where they don't or in the common case where the procurement lasts longer than an administration, all of that community knowledge of the contracting requirements gets lost. In the next phase, the new administration beholden to the local unions for their support in the election begins to investigate the procurment practices for the system. What is your paper trail?
The next problem is 'where in the tiers of vendors does this work'? IOW, if one is a vendor with a EULA, one writes a contract that indemnifies the low level system by making the middle tier application development vendor or resaler responsible for all litigations. That's a problem for the customers of the Sun customers or the Microsoft customers. This is contract work, of course, but somewhere the adopters have to respond.
Try before you buy is great with appropriate papers signed. I'm all for it.
What I fear is that the adoption approach works when the conditions are right but otherwise, it is the usual paperwork grind after the adoption phase.
[link]