82,853
edits
Software-as-a-service: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 10: | Line 10: | ||
If your software were any good you would design a [[user interface|user-interface]] easy enough for the [[meatware]] to deal with ''so you didn’t need a service contract''. Right? | If your software were any good you would design a [[user interface|user-interface]] easy enough for the [[meatware]] to deal with ''so you didn’t need a service contract''. Right? | ||
===The [[reg tech]] business model conundrum=== | ===The [[reg tech]] business model conundrum=== | ||
It is a familiar experience amongst buyers of [[reg tech]] and [[legal tech]] that | It is a familiar experience amongst buyers of [[reg tech]] and [[legal tech]] that products look ''fabulous'' at the pitch when the [[general counsel]] is watching, but underwhelm in production when set upon by the [[morlock]]s who actually need to use them. It is one thing to performing [[magic]] on a pre-prepared [[non-disclosure agreement]]— “here’s one I made earlier”, Blue Peter style; it’s quite another to dispatch the knotty [[real-life legal problems]] that your staff have to solve at the coalface. How easily [[GC]]s forget it was like. | ||
This is partly because the yen to be [[thought leader|thought-leading]]s [[agent]]s for [[step-change]] in their industry, plays to a [[general counsel]]’s innate credulity and weakness for flattery, but has a profounder operating cause: [[reg tech]] struggles mightily with a business model that ''scales''. [[Reg tech|reg tech]] strives to automate [[tedious]], repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. The idea is to [[disintermediate]], taking out expensive, unreliable, high-maintenance machinery and replacing it with does the same job for nothing. | This is partly because the yen to be [[thought leader|thought-leading]]s [[agent]]s for [[step-change]] in their industry, plays to a [[general counsel]]’s innate credulity and weakness for flattery, but has a profounder operating cause: [[reg tech]] struggles mightily with a business model that ''scales''. [[Reg tech|reg tech]] strives to automate [[tedious]], repetitive and manual tasks, thereby removing a significant cost item from the departmental budget, and accelerating and improving the output quality at the same time. The idea is to [[disintermediate]], taking out expensive, unreliable, high-maintenance machinery and replacing it with does the same job for nothing. | ||
If you are buying that product “off the shelf” — assuming it can already do what its vendors claim; by no means a given — observe where the vendor’s energy is going: exclusively, ''sales''. They are costlessly reprinting something they made earlier, and proposing to charge you a licence for it, per seat, | If you are buying that product “off the shelf” — assuming it can already do what its vendors claim; by no means a given — observe where the vendor’s energy is going: exclusively, ''sales''. They are costlessly reprinting something they made earlier, and proposing to charge you a licence for it, per seat, use, or time period. When your target audience is narrow — for all the trillions of dollars at stake in the industry, the number of software buyers is limited — there is only one way to make decent amount of money: by ''extracting [[rent]]''. Now this would be fine, of course, if the product ''did'' work as billed, and intelligently anticipated your particular applications, and handled them quickly, quietly and immaculately right out of the box. | ||
But, of course, they don’t. It is a common experience, when you finally get to play with it, that a [[reg tech]] application ''doesn’t quite do what you want it to''. Either ''your'' intended use isn’t ''quite'' the one the vendor had in mind, and the product can’t ''quite'' do it and isn’t flexible enough for you to reconfigure it — call this a “'''misalignment'''” problem — or it ''can'', but to get the application to be of any use, it will need a good deal of energy, expertise and effort from ''your'' people to configure or train it; energy [[change adoption|they will be disinclined to provide]] — call this a “'''configuration'''” problem. | But, of course, they don’t. It is a common experience, when you finally get to play with it, that a [[reg tech]] application ''doesn’t quite do what you want it to''. Either ''your'' intended use isn’t ''quite'' the one the vendor had in mind, and the product can’t ''quite'' do it and isn’t flexible enough for you to reconfigure it — call this a “'''misalignment'''” problem — or it ''can'', but to get the application to be of any use, it will need a good deal of energy, expertise and effort from ''your'' people to configure or train it; energy [[change adoption|they will be disinclined to provide]] — call this a “'''configuration'''” problem. | ||
| Line 30: | Line 30: | ||
Second, this [[subject matter expert]] training is ''exactly'' the sort of thing that — if a client permits it — the [[vendor]] can harness to improve the product for its other clients. To be sure, there is a ''[[quid-pro-quo]]'' here: the client, too, will benefit from the training the product receives from the hands of the vendor’s other clients, but this only sharpens the irony: the value the [[vendor]] itself provides is minimal: merely an application interface on top of open-source [[neural network]] technology. What turns a public utility with a glossy front-end into gold-dust is the distributed training the application receives, ''from the clients''. Yet, the [[vendor]] gets to bill the clients, and not the other way around. That is ''truly'' “indistinguishable from [[magic]]”. | Second, this [[subject matter expert]] training is ''exactly'' the sort of thing that — if a client permits it — the [[vendor]] can harness to improve the product for its other clients. To be sure, there is a ''[[quid-pro-quo]]'' here: the client, too, will benefit from the training the product receives from the hands of the vendor’s other clients, but this only sharpens the irony: the value the [[vendor]] itself provides is minimal: merely an application interface on top of open-source [[neural network]] technology. What turns a public utility with a glossy front-end into gold-dust is the distributed training the application receives, ''from the clients''. Yet, the [[vendor]] gets to bill the clients, and not the other way around. That is ''truly'' “indistinguishable from [[magic]]”. | ||
===Then there’s [[blockchain]], of course=== | ===Then there’s [[blockchain]], of course=== | ||
{{bs}}The latest iteration — talked about in tones of reverent optimism [https://www.forbes.com/sites/ilkerkoksal/2019/10/23/the-benefits-of-applying-blockchain-technology-in-any-industry/#7253848c49a5 here] — is “[[blockchain as a service]]”. But a service to whom? And did I hear a siren going off? | {{bs}}The latest iteration — talked about in tones of reverent optimism [https://www.forbes.com/sites/ilkerkoksal/2019/10/23/the-benefits-of-applying-blockchain-technology-in-any-industry/#7253848c49a5 here] — is “[[blockchain as a service]]”. But a service to whom? And did I hear a siren going off? | ||
{{sa}} | {{sa}} | ||